跳到主要内容
返回文章列表

GKE รองรับ Node ตระกูล Z4M สำหรับงาน Storage หนัก พร้อมเงื่อนไขเวอร์ชันต่างกัน

สร้าง node ด้วยมือได้จาก GKE 1.36.3 ส่วน autoscaling และ Autopilot ต้อง 1.37.0 ตามรุ่นที่ระบุ

GKE รองรับ Node ตระกูล Z4M สำหรับงาน Storage หนัก พร้อมเงื่อนไขเวอร์ชันต่างกัน

Google Cloud ประกาศใน release notes วันที่ 19 ตุลาคม 2026 ว่า GKE สามารถ provision node จาก Z4M machine series ที่เน้น storage ได้แล้ว จุดมุ่งหมายคือ workload ที่ใช้ I/O สูง เช่นฐานข้อมูล และ large parallel file system สำหรับ AI/ML แต่เงื่อนไขเวอร์ชันต่างกันระหว่างการสร้าง node ด้วยมือกับการให้ระบบเลือกผ่าน compute classes หรือ autoscaler ผู้ดูแลคลัสเตอร์จึงต้องตรวจเวอร์ชันก่อนทำ capacity plan

เวอร์ชันที่รองรับตามประกาศ

การ provision แบบ manual รองรับตั้งแต่ GKE 1.36.3-gke.1767000 ขึ้นไป ส่วน compute classes, cluster autoscaler, node pool auto-creation และ Autopilot รองรับตั้งแต่ 1.37.0-gke.4713000 ขึ้นไป Google ระบุว่า GKE ยังไม่รองรับ Z4M bare metal instances ในเวลาประกาศ ความต่างนี้สำคัญ: คลัสเตอร์ที่สร้าง node pool เองได้อาจยังใช้ automation เลือก Z4M ไม่ได้จนกว่าจะอัปเกรดถึงเวอร์ชันอีกระดับ

เหมาะกับงานใด

Z4M ถูกวางไว้สำหรับงานที่มี I/O หนัก ไม่ใช่คำตอบอัตโนมัติสำหรับทุก Pod ทีมควรตรวจว่าคอขวดปัจจุบันอยู่ที่ storage throughput, latency, CPU, memory หรือ network ก่อนเปลี่ยน node หากฐานข้อมูลช้าเพราะ query หรือ lock, การย้ายไปเครื่องที่เน้น storage อาจไม่แก้สาเหตุ แยก benchmark งานอ่าน/เขียนจริงกับค่าใช้จ่ายต่อหน่วยงาน เพื่อรู้ว่าความเร็วที่เพิ่มคุ้มราคาหรือไม่

สำหรับ AI/ML ที่ใช้ parallel file system ให้ตรวจรูปแบบการ mount, จำนวน worker ที่อ่านพร้อมกัน และตัวชี้วัด read throughput/queue depth อย่าดูเพียงขนาดเครื่อง เพราะ bottleneck อาจอยู่ที่เส้นทางจาก storage ถึง Pod หรือที่ตัว filesystem เอง หากงานมี stateful set ต้องคิดถึงการย้ายข้อมูล ความพร้อมของ persistent volume และความเสี่ยงเมื่อ node pool เก่าถูก drain

ขั้นตอนทดลองใน GKE

ตรวจเวอร์ชัน cluster และ release channel ก่อน เลือก node pool ทดสอบขนาดเล็กและ workload ที่ย้ายออกได้ ตั้ง node selector/affinity หรือ compute class ตามวิธีที่เวอร์ชันรองรับ เพื่อไม่ให้ Pod สำคัญย้ายผิดกลุ่ม เก็บ baseline ของ latency, throughput, CPU, memory และค่าใช้จ่ายจาก node เดิม รันโหลดเทียบในช่วงเวลาที่ใกล้กัน แล้วดูว่าคำขอระดับแอปเร็วขึ้นจริงหรือแค่ benchmark ดิสก์ดีขึ้น

หากจะใช้ autoscaling ตรวจว่า node pool auto-creation รองรับเวอร์ชันที่ประกาศและมี quota/stock ใน Region ที่ต้องการ เพราะการรองรับใน GKE release notes ไม่เท่ากับรับประกันว่าเครื่องพร้อมทุก zone เตรียม fallback node pool สำหรับงานที่เลื่อนเวลาไม่ได้ และกำหนด eviction policy ของ Pod อย่างเหมาะสม

ข่าวนี้เพิ่มทางเลือกให้ทีมที่มี workload storage-heavy แต่ประโยชน์จะเกิดเมื่อเลือก workload ที่คอขวดตรงกับจุดแข็งของ Z4M และยืนยันผลด้วยตัวเลขของแอปจริงก่อนขยายการใช้งาน

ประกาศต้นทาง: https://docs.cloud.google.com/kubernetes-engine/docs/release-notes-new-features