Kubernetes เตรียมตัดทางเลือก cgroup v1 ในรุ่น 1.38 โหนด Linux ต้องย้ายไป cgroup v2
บล็อก Kubernetes 6 ต.ค. 2026 ย้ำว่าทางเลือก cgroup v1 มีกำหนดถูกถอดในรุ่น 1.38 ที่จะออก 16 ธ.ค. 2026 โหนด Linux ทุกเครื่องจึงต้องย้ายไป cgroup v2 ก่อนอัปเกรด
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- บล็อกของโครงการ Kubernetes เมื่อ 6 ตุลาคม 2026 ระบุว่าทางเลือกให้ kubelet ทำงานบน cgroup v1 มีกำหนดถูกถอดออกใน Kubernetes v1.38 ซึ่งตารางของทีม release กำหนดออก 16 ธันวาคม 2026
- ตั้งแต่ Kubernetes v1.35 ค่า
failCgroupV1เป็น true ตามค่าเริ่มต้น kubelet จึงไม่เริ่มทำงานบนโหนด cgroup v1 และ kubeadm แจ้ง error ตอน init, join และ upgrade - เงื่อนไขของ cgroup v2 คือ Linux kernel 5.8 ขึ้นไป containerd 1.4 หรือ CRI-O 1.20 ขึ้นไป และใช้ cgroup driver แบบ systemd ทั้งฝั่ง kubelet และ container runtime
- เอกสาร Kubernetes ระบุว่า Ubuntu ใช้ cgroup v2 ตามค่าเริ่มต้นตั้งแต่ 21.10 และ RHEL กับดิสโทรตระกูลเดียวกันตั้งแต่ รุ่น 9 เวอร์ชันที่เก่ากว่านี้ต้องตรวจก่อนอัปเกรด
- Kubernetes 1.34 หมดอายุซัพพอร์ต 27 ตุลาคม 2026 คลัสเตอร์ที่ยังอยู่รุ่นนี้ต้องผ่านด่าน cgroup v1 ทันทีที่อัปเกรดขึ้น 1.35 ขึ้นไป
บล็อกของโครงการ Kubernetes ที่เผยแพร่เมื่อวันที่ 6 ตุลาคม 2026 ย้ำว่าทางเลือกให้ kubelet ทำงานบนโหนด cgroup v1 มีกำหนดถูกถอดออกใน Kubernetes v1.38 ซึ่งตารางของทีม release กำหนดออกวันที่ 16 ธันวาคม 2026 โหนด Linux ทุกเครื่องในคลัสเตอร์จึงต้องย้ายไป cgroup v2 ก่อนอัปเกรดถึงรุ่นนั้น
ผู้ที่ยังอยู่บน Kubernetes 1.34 ซึ่งหมดซัพพอร์ต 27 ตุลาคม 2026 จะเจอเรื่องนี้เร็วกว่านั้น เพราะตั้งแต่ 1.35 kubelet ปฏิเสธโหนด cgroup v1 ตามค่าเริ่มต้นแล้ว
เส้นทางที่ Kubernetes ทยอยเลิก cgroup v1
บทความเขียนโดย Paco Xu จาก DaoCloud สรุปลำดับเหตุการณ์ไว้ดังนี้ (วันออกรุ่นจากตารางของทีม release)
| รุ่น | สถานะของ cgroup |
|---|---|
| v1.25 | การจัดการทรัพยากรด้วย cgroup v2 เข้าสู่สถานะ stable |
| v1.31 | การรองรับ cgroup v1 เข้าสู่ maintenance mode |
| v1.35 (ออก 17 ธ.ค. 2025) | เลิกใช้ cgroup v1 อย่างเป็นทางการ failCgroupV1 เป็น true ตามค่าเริ่มต้น และ kubeadm แจ้ง error ตอน preflight |
| v1.36 และ v1.37 | ยังตั้ง failCgroupV1: false เป็นทางเลือกชั่วคราวได้ |
| v1.38 (กำหนด 16 ธ.ค. 2026) | มีกำหนดถอดทางเลือก cgroup v1 ออก |
บล็อกระบุว่าใน Kubernetes 1.36 ทางเลือก cgroup v1 ยังรองรับในฐานะ fallback และเอกสาร About cgroup v2 ฉบับปัจจุบันซึ่งตรงกับรุ่น 1.37 ที่ออกเมื่อ 26 สิงหาคม 2026 ยังอธิบายวิธีตั้ง failCgroupV1: false อยู่ งานถอดออกติดตามอยู่ใน KEP-5573
สำหรับคลัสเตอร์ที่สร้างด้วย kubeadm ด่านจะมาเร็วกว่านั้นอีก ตั้งแต่ kubelet v1.35 การตรวจ SystemVerification ใน preflight จะคืนค่า error ระหว่าง kubeadm init, kubeadm join และ kubeadm upgrade เมื่อพบ cgroup v1 ส่วน kubelet รุ่นเก่ากว่ายังเป็นเพียงคำเตือน
เงื่อนไขของ cgroup v2 และดิสโทรที่ใช้เป็นค่าเริ่มต้น
เอกสารของ Kubernetes กำหนดเงื่อนไขการใช้ cgroup v2 ไว้ดังนี้
- ระบบปฏิบัติการเปิดใช้ cgroup v2 และ Linux kernel ตั้งแต่ 5.8 ขึ้นไป (แนะนำ 5.9 ขึ้นไปถ้าจะใช้ Memory QoS)
- container runtime รองรับ cgroup v2 เช่น containerd 1.4 ขึ้นไป หรือ CRI-O 1.20 ขึ้นไป ถ้าต้องการให้ kubelet ตรวจหา cgroup driver เองต้องใช้ containerd 2.0 หรือ CRI-O 1.28 ขึ้นไป
- kubelet และ container runtime ใช้ cgroup driver ตรงกัน โดยคลัสเตอร์ที่จัดการด้วย kubeadm ควรใช้ driver แบบ systemd
วิธีที่โครงการแนะนำคือใช้ดิสโทรที่เปิด cgroup v2 เป็นค่าเริ่มต้นอยู่แล้ว ไม่ใช่ไปแก้ค่าบูตเอง
ดิสโทรที่เอกสารระบุ ได้แก่ Container Optimized OS ตั้งแต่ M97, Ubuntu ตั้งแต่ 21.10 (แนะนำ 22.04 ขึ้นไป), Debian ตั้งแต่ 11, Fedora ตั้งแต่ 31, Arch Linux ตั้งแต่เมษายน 2021 และ RHEL กับดิสโทรตระกูลเดียวกันตั้งแต่รุ่น 9 วิธีตรวจคือรัน stat -fc %T /sys/fs/cgroup/ บนโหนด ถ้าได้ cgroup2fs คือ cgroup v2 ถ้าได้ tmpfs คือยังเป็น cgroup v1
ซอฟต์แวร์ที่อ่าน cgroup โดยตรงต้องอัปเดตก่อนย้าย
kubelet ตรวจพบ cgroup v2 และปรับตัวเองโดยไม่ต้องตั้งค่าเพิ่ม ผู้ใช้ส่วนใหญ่ไม่ควรเห็นความต่าง ยกเว้นซอฟต์แวร์ที่เข้าถึงไฟล์ระบบ cgroup โดยตรง ทั้งบนโหนดและจากในคอนเทนเนอร์
- Java ควรใช้ OpenJDK/HotSpot 8u372, 11.0.16 หรือ 15 ขึ้นไป หรือ IBM Semeru 8.0.382.0, 11.0.20.0, 17.0.8.0 ขึ้นไป
- Node.js อ่านขีดจำกัดหน่วยความจำของ cgroup v2 ได้ตั้งแต่ 20.3.0 ส่วนสาย 18 อ่านได้ไม่แน่นอน อาจไปอ่านหน่วยความจำทั้งเครื่องแทนค่าที่จำกัดให้ pod จน heap ใหญ่เกินและถูก OOM kill
- Go ที่ใช้แพ็กเกจ automaxprocs ต้องเป็น 1.5.1 ขึ้นไป และ cAdvisor ที่รันแยกเป็น DaemonSet ต้องเป็น 0.43.0 ขึ้นไป
- เอเจนต์มอนิเตอร์และความปลอดภัยของผู้ผลิตรายอื่นที่อ่าน cgroup ต้องอัปเดตเป็นรุ่นที่รองรับ
อีกจุดคือการแปลงค่า CPU ระหว่าง cpu.shares ของ v1 กับ cpu.weight ของ v2 crun 1.23 และ runc 1.3.2 ใช้สูตรแปลงแบบใหม่ เครื่องมือที่คำนวณค่า cpu.weight ล่วงหน้าอาจต้องปรับตาม
ทำไมเรื่องนี้สำคัญ: ฟีเจอร์ใหม่ผูกกับ cgroup v2
การย้ายไม่ได้มีแค่ต้นทุน บล็อกชี้ว่าความสามารถรุ่นใหม่ของ Kubernetes หลายอย่างใช้ได้เฉพาะบน cgroup v2
- Memory QoS ซึ่งยังเป็น alpha ใน 1.36 ใช้
memory.highหน่วง (throttle) คอนเทนเนอร์กลุ่ม Burstable ที่ใช้หน่วยความจำเกินเกณฑ์ และเพิ่มการกันหน่วยความจำแบบแบ่งชั้นด้วยmemory.minและmemory.low - การจัดการ OOM ระดับคอนเทนเนอร์ บนโหนด cgroup v2 ค่าเริ่มต้นคือ kill ทุกโพรเซสในคอนเทนเนอร์พร้อมกัน แทนที่จะเหลือคอนเทนเนอร์ที่ทำงานครึ่ง ๆ กลาง ๆ
- Pressure Stall Information (PSI) รายงานการแย่ง CPU หน่วยความจำ และ I/O ระดับโหนด pod และคอนเทนเนอร์ ต้องใช้ cgroup v2 และ Linux 4.20 ขึ้นไป
- การปรับทรัพยากรระดับ pod โดยไม่รีสตาร์ต ที่เปิดเป็นค่าเริ่มต้นแบบ beta ใน 1.36 ต้องใช้ cgroup v2 จึงบังคับขีดจำกัดรวมได้แม่นยำ
ทั้งนี้บล็อกเตือนว่า Memory QoS ยังเป็นฟีเจอร์ alpha ซึ่งโครงการไม่แนะนำให้เปิดใน production ถ้ายังไม่ได้ทดสอบ หากต้องการทบทวนพื้นฐานของคลัสเตอร์ อ่านได้ที่ Kubernetes คืออะไร
ผลต่อองค์กรไทย
- สำรวจทุกโหนด Linux ภายในสัปดาห์นี้ รัน
stat -fc %T /sys/fs/cgroup/ผ่านเครื่องมือจัดการเครื่องที่ใช้อยู่ โดยเฉพาะคลัสเตอร์ on-premise ที่ติดตั้งบนดิสโทรรุ่นเก่ากว่ารายการของเอกสาร เช่น Ubuntu ก่อน 21.10 หรือ RHEL และดิสโทรตระกูลเดียวกันก่อนรุ่น 9 - วางแผนอัปเกรดคลัสเตอร์ 1.34 ก่อน 27 ตุลาคม 2026 และย้ายโหนดไป cgroup v2 ก่อนขึ้น 1.35 อย่าใช้
failCgroupV1: falseเป็นทางออกถาวร เพราะมีกำหนดถูกถอดใน 1.38 - ตรวจ runtime ของแอปในอิมเมจ หา Java และ Node.js รุ่นเก่า โดยเฉพาะ Node.js 18 ซึ่งเสี่ยงคำนวณ heap ผิดบน cgroup v2 ถ้ายังอัปเกรดไม่ได้ให้กำหนด
--max-old-space-sizeเอง - ทดสอบเอเจนต์มอนิเตอร์ ความปลอดภัย และ log บนโหนด cgroup v2 ในสภาพแวดล้อมทดสอบก่อน เพราะเป็นกลุ่มที่อ่านไฟล์ cgroup โดยตรงและมักถูกลืม
- ผู้ใช้ Kubernetes แบบ managed บนคลาวด์ ควรตรวจกับผู้ให้บริการว่าอิมเมจของ node pool ที่ใช้อยู่เป็น cgroup v2 แล้วหรือไม่ และกำหนดรอบเปลี่ยน node pool ให้ทันก่อนอัปเกรด ติดตามข่าวซอฟต์แวร์และ DevOps เพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
cgroup v2 คืออะไร และ Kubernetes ใช้ทำอะไร?
cgroup (control groups) เป็นความสามารถของ Linux kernel สำหรับจำกัดและแบ่งทรัพยากร Kubernetes ใช้ cgroup กำหนด CPU และหน่วยความจำให้คอนเทนเนอร์ตามค่า requests และ limits ส่วน cgroup v2 เป็นรุ่นใหม่ที่มีลำดับชั้นเดียวแบบรวมศูนย์ ส่วนต่อประสานที่สม่ำเสมอกว่า และรองรับฟีเจอร์อย่าง Memory QoS และ Pressure Stall Information
Kubernetes รุ่นไหนจะใช้ cgroup v1 ไม่ได้แล้ว?
ตั้งแต่ Kubernetes v1.35 kubelet ไม่เริ่มทำงานบนโหนด cgroup v1 ตามค่าเริ่มต้น แต่ผู้ดูแลยังตั้ง failCgroupV1: false เป็นทางเลือกชั่วคราวได้ บล็อกของโครงการเมื่อ 6 ตุลาคม 2026 ระบุว่าทางเลือกนี้มีกำหนดถูกถอดออกใน Kubernetes v1.38 ซึ่งมีกำหนดออก 16 ธันวาคม 2026 หลังจากนั้นทุกโหนดต้องใช้ cgroup v2
ตรวจอย่างไรว่าโหนดใช้ cgroup v2 แล้ว?
รันคำสั่ง stat -fc %T /sys/fs/cgroup/ บนโหนด Linux แต่ละเครื่อง ถ้าผลลัพธ์เป็น cgroup2fs แปลว่าใช้ cgroup v2 แล้ว ถ้าเป็น tmpfs แปลว่ายังเป็น cgroup v1 ต้องย้ายระบบปฏิบัติการหรือแก้ค่าบูตก่อนอัปเกรด Kubernetes
ย้ายไป cgroup v2 แล้วแอปพลิเคชันต้องแก้อะไรบ้าง?
แอปที่ไม่ได้อ่านไฟล์ cgroup โดยตรงไม่ควรเห็นความต่าง แต่ runtime ที่อ่านขีดจำกัดหน่วยความจำต้องเป็นรุ่นที่รองรับ cgroup v2 เช่น OpenJDK 8u372, 11.0.16, 15 ขึ้นไป และ Node.js 20.3.0 ขึ้นไป ส่วน cAdvisor ต้องเป็น 0.43.0 ขึ้นไป และเอเจนต์มอนิเตอร์หรือความปลอดภัยที่อ่าน cgroup ต้องอัปเดตด้วย
แหล่งอ้างอิง
- The Shift to cgroup v2 in Kubernetes: What You Need to Know — Kubernetes Blog
- About cgroup v2 — Kubernetes Documentation
- Releases — Kubernetes
- Kubernetes 1.38 Release Information — Kubernetes SIG Release (GitHub)
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ