Kubernetes 1.34 หมดซัพพอร์ต 27 ต.ค. 2026: วันสิ้นสุดบน EKS, AKS, GKE และเส้นทางอัปเกรด

Kubernetes 1.34 หมดซัพพอร์ตบน Azure AKS เมื่อไร

ตารางของ Microsoft ระบุว่า 1.34 เป็น GA บน AKS ในเดือนพฤศจิกายน 2025 และ Kubernetes 1.34 หมดซัพพอร์ตบน AKS ในเดือนพฤศจิกายน 2026 ซึ่ง AKS ให้นับเป็นวันสุดท้ายของเดือน หลังจากนั้นยังมี platform support จนกว่า 1.38 จะเป็น GA และแผนอัปเกรดโดยแพลตฟอร์มรอบแรกของรุ่นนี้อยู่ที่เดือนมิถุนายน 2027 หลังช่วงผ่อนผัน 60 วัน

เงื่อนไขที่ต้องระวังคือการอัปเกรดโดยแพลตฟอร์มไม่ทำตาม maintenance window และไม่รันการตรวจ API ที่เลิกใช้ ส่วน LTS ซึ่งยืด 1.34 ไปถึงพฤศจิกายน 2027 ต้องสมัครเองเท่านั้น AKS ไม่สมัครให้อัตโนมัติ

Kubernetes 1.34 หมดซัพพอร์ตบน Google GKE เมื่อไร

ตาราง GKE ระบุว่า Kubernetes 1.34 หมดซัพพอร์ตปกติวันที่ 25 มกราคม 2027 และคลัสเตอร์ใน Extended channel อยู่ต่อได้ถึง 25 พฤศจิกายน 2027 แต่คลัสเตอร์ในช่อง Regular และ Stable มีวันเริ่มอัปเกรดอัตโนมัติไป 1.35 แล้ว คือ 28 เมษายน 2026 และ 15 กันยายน 2026 ตามลำดับ GKE จะยกคลัสเตอร์ขึ้นเองในหรือหลังวันดังกล่าว เว้นแต่ทีมตั้ง maintenance exclusion ไว้

เมื่อ Kubernetes 1.34 หมดซัพพอร์ต ทำไมไม่ควรรอให้คลาวด์อัปเกรดให้

เมื่อ Kubernetes 1.34 หมดซัพพอร์ตบนคลาวด์ การปล่อยให้แพลตฟอร์มอัปเกรดเองดูสะดวก แต่เอกสารของ AWS และ Microsoft บอกข้อจำกัดไว้ชัด

• ค่าใช้จ่ายสูงขึ้น บน EKS ค่าคลัสเตอร์ช่วง extended แพงกว่าช่วงปกติ 6 เท่า องค์กรที่มีหลายคลัสเตอร์ควรดูราคา Managed Kubernetes ของแต่ละค่ายประกอบ
• ควบคุมเวลาไม่ได้ EKS ระบุว่าการอัปเกรดหลังหมด extended support เกิดได้ทุกเมื่อโดยไม่มีการแจ้งก่อน ส่วน AKS ไม่รอ maintenance window
• ไม่ครบทั้งคลัสเตอร์ EKS อัปเกรดเฉพาะ control plane ทีมยังต้องอัปเกรด add-on และโหนดเอง และคลัสเตอร์ที่ถูกอัปเกรดอัตโนมัติจะย้อนกลับไม่ได้ ต่างจากการอัปเกรดเองที่ย้อนกลับได้ภายใน 7 วัน
• ไม่มีการตรวจ API ให้ AKS ระบุว่าการอัปเกรดโดยแพลตฟอร์มไม่ตรวจ API ที่เลิกใช้ แอปที่ยังใช้ API เก่าอาจพังหลังอัปเกรด

Kubernetes 1.34 หมดซัพพอร์ตแล้ว อัปเกรดไปรุ่นไหน อย่างไร

นโยบาย Version Skew Policy ของ Kubernetes กำหนดว่า kube-apiserver ห้ามข้ามรุ่นย่อยแม้คลัสเตอร์มี apiserver ตัวเดียว เส้นทางจาก 1.34 ไป 1.37 จึงต้องผ่าน 1.35 และ 1.36 ทีละขั้น AKS ก็ระบุกติกาเดียวกันสำหรับรุ่นที่ไม่ใช่ LTS

ลำดับที่โครงการแนะนำในแต่ละขั้นมีดังนี้

1. อัปเกรดเป็นแพตช์ล่าสุดของรุ่นปัจจุบันก่อน (โครงการระบุว่าเป็นขั้นที่เลือกทำได้)
2. อัปเกรด kube-apiserver ก่อน และตรวจว่า admission webhook รองรับ API และฟิลด์ใหม่
3. อัปเกรด kube-controller-manager, kube-scheduler และ cloud-controller-manager ตาม ทำพร้อมกันได้
4. อัปเกรด kubelet และ kube-proxy บนโหนด โดย drain พ็อดออกก่อนทุกครั้ง เพราะโครงการไม่รองรับการเปลี่ยนรุ่นย่อยของ kubelet แบบ in-place

ข่าวดีคือ kubelet ตามหลัง kube-apiserver ได้ถึง 3 รุ่นย่อย เมื่อ apiserver เป็น 1.37 โหนดที่ยังเป็น 1.34 ยังอยู่ในขอบเขตที่รองรับ ทีมจึงยก control plane ขึ้นก่อนแล้วค่อยทยอยเปลี่ยนโหนดได้ แต่ต้องอัปเกรดโหนดเหล่านี้ก่อนจะขึ้น 1.38 ส่วน kubectl ต้องต่างจาก apiserver ไม่เกิน 1 รุ่นย่อย

สิ่งที่ต้องตรวจเมื่อ Kubernetes 1.34 หมดซัพพอร์ต

cgroup v1 คือด่านแรก

บล็อกของโครงการ Kubernetes เมื่อ 6 ตุลาคม 2026 ระบุว่าตั้งแต่ 1.35 ค่า failCgroupV1 เป็น true ตามค่าเริ่มต้น kubelet จะไม่เริ่มทำงานบนโหนดที่ยังใช้ cgroup v1 และ kubeadm จะแจ้ง error ตอน init, join และ upgrade ผู้ดูแลตั้ง failCgroupV1: false เป็นทางเลือกชั่วคราวได้ แต่ทางเลือกนี้มีกำหนดถูกถอดใน 1.38 รายละเอียดและเงื่อนไขของ kernel อ่านได้ในบทความcgroup v2 ใน Kubernetes

API ที่เลิกใช้

หน้า Deprecated API Migration Guide ของโครงการ ณ วันที่ 23 ตุลาคม 2026 มีรายการ API ที่ถูกถอดล่าสุดถึงรุ่น v1.32 และไม่มีหัวข้อของ 1.35 ถึง 1.37 แต่ทีมยังควรอ่าน release notes และหน้า breaking changes ของผู้ให้บริการแต่ละรุ่น เช่น AKS ระบุว่าตั้งแต่ 1.37 ตัวเก็บเมตริก Prometheus ที่จัดการโดย Azure เปลี่ยนสิทธิ์อ่าน secret เป็นรายเนมสเปซ

Add-on และเครื่องมือรอบคลัสเตอร์

ตรวจรุ่นของ CNI, ingress controller, CSI driver, service mesh และ operator ที่ติดตั้งเอง ว่ารองรับรุ่นปลายทาง และอัปเดต kubectl กับ pipeline ของ CI/CD ที่ฝังรุ่นไว้

ผลต่อองค์กรไทยและทีมพัฒนา

ตารางนี้ใช้ได้กับทุกทีมที่ต้องรับมือเมื่อ Kubernetes 1.34 หมดซัพพอร์ต นอกจากนี้ องค์กรที่ใช้ Kubernetes เชิงพาณิชย์ในศูนย์ข้อมูลของตัวเองควรดูหน้า lifecycle ของผู้ขายดิสทริบิวชันนั้นโดยตรง เพราะแต่ละรายมีรอบซัพพอร์ตของตัวเองที่อาจต่างจากโครงการต้นทาง และควรตั้งรอบอัปเกรดอย่างน้อยปีละครั้งเป็นงานประจำ ไม่ใช่งานเร่งเมื่อใกล้หมดอายุ ผู้ที่ยังใหม่กับระบบนี้อ่านพื้นฐานได้ที่ Kubernetes คืออะไร และติดตามข่าวรุ่นใหม่ได้ที่หมวดการพัฒนาซอฟต์แวร์