เค้าบอกว่าเลิกใช้ Kubernetes แล้วชีวิตดี๊ดี จริงปะ?
บทนำ
ผมเคยเป็นคนออกแบบ, ติดตั้ง และดูแล Docker host ใน on-premise มาก่อน จากนั้นขยับเป็น Kubernetes (ใช้ kubeadm) แล้วไปอยู่บน cloud กับ AWS ECS, AWS EKS ก่อนจะกลับมาวิ่งเล่นบน on-premise อีกครั้งด้วย OpenShift และ Kubernetes (ใช้ Rancher)
ต้องยอมรับเลยว่า Kubernetes เป็นหนึ่งในสิ่งที่ผม “ว้าวที่สุด” ในโลก IT infrastructure และโดยส่วนตัวผมลงทุนกับมันไปไม่น้อยครับ แต่ตลอดเวลาที่ผ่านมาผมก็ตั้งคำถามมาตลอดว่า “ทุกคนจำเป็นต้องใช้มันจริงๆ เหรอ?”
ในที่สุดก็มีคนเขียนเรื่องนี้เสียที “I Stopped Using Kubernetes. Our DevOps Team Is Happier Than Ever” มันช่างเหมือนกับสหายที่รู้ใจเสียจริงๆ
แน่นอน ผมไม่ได้เห็นด้วยกับเค้าทั้งหมดหรอก เพราะผมมองว่าการใช้ Kubernetes อาจไม่ได้แย่เท่าประสบการณ์ในบทความนี้ ส่วนหนึ่งเป็นเพราะ bad design ของเค้าเองด้วย แต่ทั้งหมดทั้งมวลก็มีส่วนจริงอยู่มากกว่าไม่จริง (เห็นตั้งนานแล้วแหละแต่พึ่งว่างมาเขียน 😂)
เค้าว่ายังไงหนะหรอ? มาลองดูกัน
จุดเริ่มต้นของปัญหา
เมื่อ 3 ปีก่อน ทีมนี้เริ่มใช้ Kubernetes โดยหวังว่าจะได้ความสามารถในการจัดการ container ระดับ enterprise, การทำงานแบบ cloud-native และการใช้ infrastructure as code (IaC) แต่สิ่งที่เค้าไม่ได้คิดถึงคือความซับซ้อน
การต้องดูแล Kubernetes ตั้ง 47 clusters บน 3 cloud providers กลายเป็นภาระที่หนักหน่วง ทำให้ทีมต้องทำงานในวันหยุด และการเข้าเวร on-call กลายเป็นสิ่งที่หลอกหลอนทุกคน (ก็แล้วทำไมไม่ใช้ namespace!!!)
แม้จะมีทีม DevOps ถึง 8 คน, SRE อีก 3 ทีม และระบบ monitoring หลายตัวที่ค่อนข้างดี แต่เค้าก็ยังเจอกับปัญหาใหญ่ เช่น
- เกิด outage ใหญ่ 4 ครั้ง
- False positive alert 147 ครั้ง
- Emergency deploy ไป 23 ครั้ง
- นอกจากนี้ยังมีพนักงาน 2 คนลาออกเพราะ burnout
ต้นทุนที่แท้จริง
พอวิเคราะห์ต้นทุนที่แท้จริงก็พบว่า
- 40% ของ nodes ถูกใช้ไปกับการรัน Kubernetes components (ส่วนประกอบต่างๆ บน cluster ที่ไม่ใช่ app)
- ค่าใช้จ่ายสำหรับ control planes อยู่ที่ 875,000 บาทต่อเดือน
- ต้องมีระบบ 3 ชุดเพื่อรองรับ high availability
- ต้องใช้เวลา 3 เดือนในการเทรนพนักงานใหม่
- 60% ของเวลาทีม DevOps หมดไปกับการ maintenance ระบบ
การเปลี่ยนแปลงสู่ความเรียบง่าย
อ่านต่อได้ที่นี่ครับ…
