Docker พิสูจน์ว่าแอปทำงานได้ แต่ Kubernetes พิสูจน์ว่ามันใช้งานได้จริง
เจาะลึกปัญหาคลาสสิกที่ทำไมแอปวิ่งฉลุยบน Docker แต่พังไม่เป็นท่าบน Kubernetes พร้อมคำอธิบายแบบเห็นภาพ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เวลาตี 2:47 พอดใน Kubernetes ขึ้นสถานะ Running แต่คอลลิงก์แล้วเจอ Timeout
- โค้ดตัวเดียวกันรันผ่านฉลุยด้วยคำสั่ง docker run บนเครื่องแล็ปท็อป
- Docker ทำงานง่ายๆ แค่สตาร์ทกระบวนการและแมปพอร์ต โดยไม่มีการตรวจสอบระดับสเกล
- Kubernetes บังคับให้แอปพลิเคชันต้องจัดการตัวเองในระบบเครือข่ายและวงจรชีวิต
เวลาตี 2:47 น. หน้าจอแสดงผลบอกว่าพอดกำลังรันอยู่ (Running) บันทึกการทำงานก็สะอาดสะอ้านไม่มีข้อความสีแดงหรือร่องรอยความผิดปกติ คำสั่งอย่าง kubectl get pods แสดงผลลัพธ์เป็น 1/1 ทุกอย่างในมุมมองทางเทคนิคควรจะสมบูรณ์แบบไร้ที่ติ
คุณลองพิมพ์คำสั่ง curl จากแล็ปท็อปส่วนตัวกลับได้ค่า Timeout ทันที และพอทดลองยิงคำสั่งจากภายในคลัสเตอร์เองก็ได้รับคำตอบว่า connection refused เมื่อเข้าไปดูข้างในพอดด้วยคำสั่ง exec กระบวนการทำงานก็ยังนั่งรันอยู่ ฟังพอร์ตอยู่ และดูสุขภาพดีไม่มีปัญหา คุณเพิ่งสร้างอิมเมจตัวนี้และรันบนเครื่องเมื่อสามชั่วโมงก่อนด้วย docker run ซึ่งมันทำงานได้ตั้งแต่ครั้งแรกที่ลอง โดยไม่มีบรรทัดไหนในโค้ดถูกเปลี่ยนไปเลย สิ่งเดียวที่เปลี่ยนไปคือสิ่งแวดล้อมรอบตัวมันต่างหาก
ก่อนจะลงลึก ผู้เขียนใช้เวลาสามเดือนที่ผ่านมาผ่านหน้าจอเทอร์มินัลและมือถือผ่าน Termux ทดสอบเวิร์กโฟลว์ DevOps และ Linux บนโทรศัพท์ พร้อมทั้งเริ่มศึกษาการร่วมมือจัดทำเอกสาร Kubernetes อย่างจริงจัง ประเด็นเหล่านี้จึงไม่ใช่เรื่องที่หยิบยกมาพูดเล่นๆ เพื่อเรียกยอดไลก์ แต่เป็นสิ่งวนเวียนอยู่ในหน้าต่างเทอร์มินัลมาหลายสัปดาห์แล้ว
หากคุณเคยส่งงานขึ้นระบบ Kubernetes คุณย่อมคุ้นเคยกับเหตุการณ์ตอนตี 2:47 น. ที่กล่าวมาข้างต้น และหากคุณเคยค้นหาวิธีแก้ปัญหาผ่านกูเกิล คุณย่อมเคยอ่านบทความแนวเดียวกันมาแล้วนับครั้งไม่ถ้วน เช่น เปลี่ยนไปผูกกับ 0.0.0.0 แทนที่จะเป็น 127.0.0.1, เพิ่ม readiness probe, เลิกใช้ localhost เสียที หรือตรวจดู ConfigMap ของคุณ คำแนะนำทั้งหมดนั้นถูกต้อง แต่ไม่มีอันไหนที่ช่วยให้เข้าใจแก่นแท้จริงๆ เพราะมันเป็นเพียงรายการอาการป่วยที่ถูกนำมาแต่งตัวเป็นคำอธิบาย
ในฐานะวิศวกร การทำความเข้าใจความแตกต่างเชิงสถาปัตยกรรมระหว่าง Docker และ Kubernetes เป็นกุญแจสำคัญในการย้ายระบบจากเครื่อง Local สู่ Cloud-native เหตุผลที่เครื่องมือทั้งสองให้ผลลัพธ์ต่างกันไม่ใช่เพราะความผิดพลาดของโค้ด แต่เป็นเพราะขอบเขตความรับผิดชอบที่ระบบจัดการเบื้องหลังมีไม่เท่ากัน
คำอธิบายที่แท้จริงสามารถสรุปได้ในประโยคเดียว:
Docker พิสูจน์ว่าแอปของคุณรันได้ ส่วน Kubernetes พิสูจน์ว่าแอปของคุณใช้งานได้จริง (operable)
เนื้อหาส่วนที่เหลือในบทความนี้จะอธิบายประโยคดังกล่าวในสี่มุมมองที่แตกต่างกัน จนกว่ามันจะเลิกเป็นแค่สโลแกนเท่ๆ และกลายเป็นกรอบความคิดที่คุณใช้ในการดีบั๊กงานจริงๆ
- Docker รันกระบวนการ เปิดพอร์ต แล้วจบ ไม่สนใจว่าคนอื่นจะเรียกชื่อแทน IP ได้ไหม
- Kubernetes ไม่ใช่เวอร์ชันที่เข้มงวดกว่าของ Docker แต่เป็นสิ่งแวดล้อมแรกที่บังคับให้แอปตอบคำถามพื้นฐานเหล่านี้ด้วยตัวเอง
- เมื่อ localhost:5000 บนเครื่องของคุณหมายถึงคอนเทนต์เดียวกัน แต่ใน Kubernetes มันคือตัวพอดเอง
- กระบวนการทำงานในคอนเทนต์จะกลายเป็น PID 1 ซึ่งเคอร์เนล Linux จะไม่ส่งสัญญาณ SIGTERM หากไม่มีการลงทะเบียนตัวจัดการไว้ล่วงหน้า
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น