🖇️ "Kubernetes 1 ล้านโหนด: ภารกิจสุดโหดที่กลายเป็นจริง" ลองจินตนาการถึง Kubernetes cluster ที่มีถึง 1 ล้านโหนด—ไม่ใช่แค่แนวคิด แต่เป็นการทดลองจริงที่ผลักดันขีดจำกัดของระบบ cloud-native ที่ทรงพลังที่สุดในโลกใบนี้! โครงการ “k8s-1m” โดยผู้เชี่ยวชาญจาก OpenAI และอดีตผู้ร่วมเขียนบทความชื่อดังเรื่องการขยาย Kubernetes สู่ 7,500 โหนด ได้กลับมาอีกครั้ง พร้อมเป้าหมายใหม่ที่ทะเยอทะยานกว่าเดิม: สร้าง cluster ที่มี 1 ล้านโหนดและสามารถจัดการ workload ได้จริง เบื้องหลังความสำเร็จนี้คือการแก้ปัญหาทางเทคนิคระดับมหากาพย์ ตั้งแต่การจัดการ IP ด้วย IPv6, การออกแบบระบบ etcd ใหม่ให้รองรับการเขียนระดับแสนครั้งต่อวินาที, ไปจนถึงการสร้าง distributed scheduler ที่สามารถจัดสรร 1 ล้าน pods ได้ภายใน 1 นาที แม้จะไม่ใช่ระบบที่พร้อมใช้งานใน production แต่โครงการนี้ได้เปิดเผยขีดจำกัดที่แท้จริงของ Kubernetes และเสนอแนวทางใหม่ในการออกแบบระบบ cloud-native ที่สามารถรองรับ workload ขนาดมหาศาลได้ในอนาคต สรุปเนื้อหาจากโครงการ k8s-1m: ✅ เป้าหมายของโครงการ ➡️ สร้าง Kubernetes cluster ที่มี 1 ล้านโหนด ➡️ ทดสอบขีดจำกัดของระบบ cloud-native ➡️ ไม่เน้นการใช้งานเชิงพาณิชย์ แต่เพื่อการวิจัยและแรงบันดาลใจ ✅ ปัญหาหลักที่ต้องแก้ ➡️ ประสิทธิภาพของ etcd ที่เป็นคอขวด ➡️ ความสามารถของ kube-apiserver ในการจัดการ watch cache ➡️ การจัดการ IP address ด้วย IPv6 ➡️ การออกแบบ scheduler ให้กระจายโหลดได้ ✅ เทคนิคที่ใช้ในระบบเครือข่าย ➡️ ใช้ IPv6 แทน IPv4 เพื่อรองรับ IP จำนวนมหาศาล ➡️ สร้าง bridge สำหรับ pod interfaces เพื่อจัดการ MAC address ➡️ ใช้ WireGuard เป็น NAT64 gateway สำหรับบริการที่รองรับเฉพาะ IPv4 ‼️ ข้อจำกัดด้านความปลอดภัย ⛔ ไม่ใช้ network policies ระหว่าง workloads เพราะมี prefix มากเกินไป ⛔ ไม่ใช้ firewall ครอบคลุมทุก prefix แต่ใช้ TLS และการจำกัดพอร์ตแทน ✅ การจัดการ state ด้วย mem_etcd ➡️ สร้าง etcd ใหม่ที่เขียนด้วย Rust ชื่อ mem_etcd ➡️ ลดการใช้ fsync เพื่อเพิ่ม throughput ➡️ ใช้ hash map และ B-tree แยกตาม resource kind ➡️ รองรับการเขียนระดับล้านครั้งต่อวินาที ‼️ คำเตือนเกี่ยวกับ durability ⛔ ลดระดับความทนทานของข้อมูลเพื่อเพิ่มประสิทธิภาพ ⛔ ไม่ใช้ etcd replicas ในบางกรณีเพื่อหลีกเลี่ยงการลด throughput ✅ การออกแบบ scheduler แบบกระจาย ➡️ ใช้แนวคิด scatter-gather เพื่อกระจายการคำนวณ ➡️ ใช้ relays หลายระดับเพื่อกระจาย pod ไปยัง schedulers ➡️ ใช้ ValidatingWebhook แทน watch stream เพื่อรับ pod ใหม่เร็วขึ้น ‼️ ปัญหา long-tail latency ⛔ บาง scheduler ช้ากว่าค่าเฉลี่ย ทำให้ระบบรอ ⛔ ใช้เทคนิค pinned CPUs และปรับ GC เพื่อลดความล่าช้า ⛔ ตัดสินใจไม่รอ scheduler ที่ช้าเกินไป ✅ ผลการทดลอง ➡️ สามารถจัดสรร 1 ล้าน pods ได้ในเวลาประมาณ 1 นาที ➡️ mem_etcd รองรับ 100K–125K requests/sec ➡️ kube-apiserver รองรับ 100K lease updates/sec ➡️ ระบบใช้ RAM และ CPU อย่างมีประสิทธิภาพ ‼️ ข้อจำกัดของภาษา Go ⛔ GC ของ Go เป็นคอขวดหลักในการจัดการ object จำนวนมาก ⛔ การเพิ่ม kube-apiserver replicas ไม่ช่วยลด GC load ✅ ข้อสรุปจากโครงการ ➡️ ขนาด cluster ไม่สำคัญเท่ากับอัตราการเขียนของ resource kind ➡️ Lease updates เป็นภาระหลักของระบบ ➡️ การแยก etcd ตาม resource kind ช่วยเพิ่ม scalability ➡️ การเปลี่ยน backend ของ etcd และปรับ watch cache ช่วยรองรับ 1 ล้านโหนด https://bchess.github.io/k8s-1m/