Kubernetes สำหรับคนที่ต้องรันมัน

คู่มือปฏิบัติสำหรับการรัน Kubernetes ในสภาพแวดล้อม production จากการกำหนด resource requests ไปจนถึง etcd backups และหน้าที่สำคัญจริง ๆ ตอนบ่ายสามโมง

บทช่วยสอน Kubernetes สอนให้คุณ deploy pod ไม่มีใครสอนว่าต้องทำอะไรเมื่อ node หายไปจากสถานะ Ready แบบเงียบ ๆ ตอนบ่ายสามโมง และโทรศัพท์ on-call ของคุณไม่หยุดส่ายเตือน ส่วนนี้คือเรื่องส่วนที่สอง

Resource requests และ limits ไม่ใช่เลือกได้

ถ้าคุณข้าม resources.requests และ resources.limits บน containers ของคุณ scheduler ก็แค่ประมาณ และ kubelet ไม่มีความคิดว่าต้อง evict อะไรก่อนเมื่อ node หมด memory ตั้ง requests ให้เท่ากับสิ่งที่ container ใช้จริง ๆ ภายใต้โหลดปกติ ไม่ใช่สิ่งที่คุณหวังว่ามันจะใช้ ตั้ง memory limits ให้ใกล้กับ requests เพราะว่า OOM-killed pods restart อย่างสะอาด แต่ CPU limits ควรจะหลวม ๆ หรือไม่มีเว้นแต่คุณต่อสู้กับ noisy neighbors เพราะว่า CPU throttling ภายใต้ hard limit ก่อให้เกิด latency spikes ที่น่าปวดหัวมากในการ debug รัน kubectl top pods -n your-namespace เป็นประจำและเปรียบเทียบกับสิ่งที่คุณประกาศไว้ ความไม่ตรงกันสะสมตัวอย่างรวดเร็วในคลัสเตอร์ที่มีมากกว่าไม่กี่บริการ

etcd คือคลัสเตอร์ทั้งหมด ถือว่าเป็นอย่างนั้น

ทุกสิ่งที่ Kubernetes รู้อยู่ใน etcd สูญเสียมันและคุณสูญเสียสถานะคลัสเตอร์ของคุณ ไม่ใช่แค่ metadata บางส่วน รัน etcdctl snapshot save /backup/etcd-snapshot.db ตามตารางเวลา และทดสอบการ restore มันบน scratch cluster อย่างน้อยครั้งหนึ่ง ฉันเคยเห็นทีมที่มี backups ทุกคืนที่กลายเป็น corrupt มาสามเดือนเพราะไม่มีใครตรวจสอบมัน ถ้าคุณใช้ managed control plane (EKS, GKE, AKS) คุณไม่ได้จัดการ etcd โดยตรง แต่คุณควรยังคงรู้เรื่อง backup และ restore story ของผู้ให้บริการของคุณก่อนที่คุณจะต้องใช้มัน ไม่ใช่ในช่วงเกิดเหตุการณ์ที่ฉุกเฉิน

Liveness และ readiness probes ต้องไม่เห็นด้วยบ้าง

ข้อผิดพลาดทั่วไปคือการใช้ endpoint เดียวกันสำหรับทั้ง liveness และ readiness probes Liveness ควรตอบ

เขียนด้วยความช่วยเหลือของ AI ตรวจสอบและเผยแพร่โดย Michal Pilch (CISSP), Korra Studio