เค้าบอกว่าเลิกใช้ Kubernetes แล้วชีวิตดี๊ดี จริงปะ?

Published:| Updated:

Table of Contents

บทนำ (Introduction)

ผมเคยเป็นคนออกแบบ, ติดตั้ง และดูแล 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 หลายตัวที่ค่อนข้างดี แต่เค้าก็ยังเจอกับปัญหาใหญ่ เช่น

ต้นทุนที่แท้จริง

พอวิเคราะห์ต้นทุนที่แท้จริงก็พบว่า

การเปลี่ยนแปลงสู่ความเรียบง่าย

ทีมเลยลองย้าย service ที่มีความสำคัญน้อยไปยังระบบที่เรียบง่ายกว่า เค้าเลือกใช้

ผลลัพธ์ที่ได้

สิ่งที่เกิดขึ้นทันทีคือ (อันนี้เฉพาะ service ที่ลองย้ายมา):

และหลังจากทดลองไป 6 เดือน ผลลัพธ์ออกมาดีมาก ดังนี้:

แนวทางการเลือกใช้ Kubernetes

ประสบการณ์จากทีมนี้พอจะบอกเราได้ไม่มากก็น้อยว่า Kubernetes ไม่ใช่เทคโนโลยีที่ไม่ดี แต่เราอาจต้องตั้งคำถามก่อนว่ามันเกินความจำเป็นสำหรับบริษัทเราหรือไม่? ซึ่งเราควรพิจารณาให้เหมาะสมกับความต้องการมากกว่าการ hype ไปกับความสดใหม่, การที่มีคนใช้เยอะ หรือเพราะมันดูเจ๋งซะจริงๆ (แต่มันก็เจ๋งจริงแหละ)

ในบทความนี้เค้าแนะนำว่าควรพิจารณาใช้ Kubernetes เมื่อ:

ในทางตรงกันข้าม เราอาจไม่จำเป็นต้องใช้ Kubernetes ถ้า:

ที่ผมเคยเห็นนะครับ บางที่เป็น in-house app เล็กๆ ไม่กี่ตัวอยู่บน cloud เจ้าเดียวที่มี user นิ่งๆ หลักร้อยหรือพัน แถมไม่ต้อง scale ใดๆ แต่ก็ขึ้น Kubernetes cluster (HA) มารัน app ซึ่งผมก็สงสัยมาตลอดว่า benefits ของ app มัน cover ค่า control plane nodes แล้วหรือยังก็ไม่รู้ 😂

บทสรุป (Conclusion)

ใช่ครับ ต้นฉบับของบทความนี้รวมถึงผมที่เอามาขยายต่อไม่ได้บอกว่าอย่าใช้ Kubernetes เพราะความต้องการของแต่ละองค์กรไม่เหมือนกัน แต่ผมคาดหวังว่ามันจะไปสะกิดใจผู้อ่านให้ลองคิดพิจารณาและเปรียบเทียบดูก่อนจะเลือกให้ดีครับ ซึ่งถ้าดูแล้วและคำตอบมันต้องเป็น Kubernetes มันก็ควรเป็น Kubernetes ครับ

การกล้าที่จะเปลี่ยนแปลงและยอมรับว่าบางครั้ง “การถอยหลัง” ไปใช้วิธีที่เรียบง่ายกว่าอาจเป็น “ความก้าวหน้า” ที่แท้จริง เพราะเป้าหมายสุดท้ายไม่ใช่การมีระบบที่ซับซ้อนที่สุดเพื่อความหล่อ แต่เป็นการมีระบบ IT ที่ช่วยเสริม business outcome ให้ดีขึ้นอย่างยั่งยืนมากกว่า

และก่อนจาก ผมขอแปะบทความ “ทำไม “ความเจ๋ง” ของภาษาโปรแกรม ถึงไม่ใช่สาระ (อีกต่อไป)” ของ อ.ใหม่ ในฝั่ง software (ภาษา programming) ไว้ให้ด้วย เพราะมันสอดรับกับเรื่องที่ผมเขียนได้ดีเหลือเกิน

สุดท้ายแล้ว ฝากวลี “No One Size Fits All” ซึ่งเป็นวลีที่ผมพูดเสมอไม่ว่าแนะนำอะไรใครไป เจอกันในบทความหน้าครับ

Does it help?

Don’t miss out on future updates - Follow or Subscribe me!

Facebook YouTube LinkedIn

And don’t forget to share it with your friends. Your share means a lot.