Requests และ Limits — จองและจำกัดทรัพยากร
บอก K8s ว่า Pod ต้องการเท่าไร และห้ามใช้เกินเท่าไร
พื้นฐานที่ควรรู้: ในคอมพิวเตอร์ทั่วไป เมื่อเราเปิดหลายโปรแกรมพร้อมกัน โปรแกรมอาจแย่งการใช้ CPU และ RAM กันจนเครื่องค้าง ใน K8s เรามีกลไกเพื่อบอกว่าแอปพลิเคชันนี้ต้องการทรัพยากรขั้นต่ำเท่าไหร่ และอนุญาตให้ใช้ได้สูงสุดเท่าไหร่ เพื่อไม่ให้แย่งกัน
จองโต๊ะร้านอาหาร: request = "จองไว้ 4 ที่นั่งแน่ ๆ" (K8s การันตีให้และใช้เลือก node) · limit = "นั่งได้มากสุด 6 ที่ ห้ามเกิน" (เพดานที่ใช้ได้จริง) — เกินแล้วโดนเบรก
ทุก container ควรระบุ requests (ทรัพยากรที่การันตี ใช้ตอน scheduler เลือก node) และ limits (เพดานสูงสุด) สำหรับ CPU และ memory
request = จองไว้ (จัด node) · limit = เพดานห้ามเกิน
เกิน limit: CPU → throttle (ช้า) · Memory → OOMKilled (ตาย+restart)
resources:
requests: # การันตีขั้นต่ำ (scheduler ใช้เลือก node)
cpu: "250m" # 250 millicores = 0.25 CPU
memory: "256Mi"
limits: # เพดานสูงสุด
cpu: "500m"
memory: "512Mi"สรุป Key Takeaways
- requests = การันตี (ใช้เลือก node) · limits = เพดานสูงสุด
- เกิน CPU limit = throttle (ช้า) · เกิน memory limit = OOMKilled (ตาย+restart)
- ควรตั้งทุก container — ไม่ตั้งเลยเสี่ยงล้ม node
คำถามที่พบบ่อย
requests กับ limits ต่างกันยังไง ตั้งเท่ากันดีไหม
requests = ที่ scheduler ใช้ "จอง" ตอนเลือกเครื่อง (การันตีขั้นต่ำ) ส่วน limits = เพดานใช้จริง — memory ถึง limit = OOMKilled, CPU ถึง limit = โดนเบรก (throttle) — แนวที่นิยม: memory ตั้ง requests=limits (กัน OOM ปริศนา) ส่วน CPU ตั้ง requests ตามจริงและปล่อย limit หลวมหรือไม่ตั้ง
Pod โดน OOMKilled ทั้งที่เครื่องยังมี RAM ว่าง เพราะอะไร
เพราะ OOMKilled ตัดสินที่ "limit ของ container" ไม่ใช่ RAM ทั้งเครื่อง — container ใช้เกิน memory limit ของตัวเองเมื่อไหร่ก็โดนฆ่าทันที — ทางแก้: วัดการใช้จริงแล้วตั้ง limit ให้พอ หรือแก้ memory leak ของแอป
QoS class คืออะไร มีผลตอนไหน
K8s จัด pod เป็น 3 ชั้นจาก requests/limits: Guaranteed (r=l ทุก container), Burstable, BestEffort (ไม่ตั้งเลย) — มีผลตอนเครื่องขาดแคลน: BestEffort ถูกไล่ (evict) ก่อน, Guaranteed อยู่ท้ายสุด — งานสำคัญจึงควรตั้ง requests=limits ให้ได้ Guaranteed