Broadcom ประกาศ 9 พ.ย. 2026 ว่า VM API ได้รับเข้า CNCF Sandbox เป็น API กลางสำหรับสร้างและดูแล VM ผ่าน Kubernetes โดยแยกสัญญากลางออกจาก provider แต่ละแพลตฟอร์ม
โดย กองบรรณาธิการ THAI DATA อ่าน 6 นาที
สรุปประเด็นสำคัญ
- Broadcom ประกาศเมื่อ 9 พฤศจิกายน 2026 ที่งาน KubeCon North America 2026 ว่าโครงการ VM API ได้รับเข้า CNCF Sandbox เป็น API กลางสำหรับสร้างและดูแล VM ผ่าน Kubernetes บนโครงสร้างพื้นฐานหลายแบบ
- VM API ต่อยอดจาก VM Operator ที่ VMware พัฒนาใช้ใน vSphere มา มากกว่า 6 ปี ใช้แนวคิดเดียวกับ Cluster API คือแยกนิยาม VM กลางออกจาก provider ของแต่ละแพลตฟอร์ม
- โค้ดบน GitHub ยังเป็น API รุ่น vm-api.io/v1alpha1 ใช้สัญญาอนุญาต Apache 2.0 และ README ระบุว่าการติดตั้ง CRD อย่างเดียวยังสร้าง VM ไม่ได้ ต้องมี provider ของแพลตฟอร์มนั้น
- บล็อกของ VMware ยกตัวอย่าง provider ที่เป็นไปได้ เช่น KubeVM Service (vSphere), Proxmox, KubeVirt, AWS และ Google Cloud แต่ระบุว่าแผนภาพไม่ใช่รายการ provider ที่มีอยู่จริง
- รายงานของ Linux Foundation ที่อ้างในประกาศสำรวจผู้ปฏิบัติงาน 492 คน พบว่า VM รองรับแอปที่ใช้งานจริง 53% และ 34% ขององค์กรที่ขยาย VM อ้างงาน AI และ agent เป็นเหตุผล
Broadcom ประกาศเมื่อวันที่ 9 พฤศจิกายน 2026 ที่งาน KubeCon North America 2026 ว่าโครงการ VM API ได้รับเข้า CNCF Sandbox แล้ว VM API คือ API กลางบน Kubernetes สำหรับสร้างและดูแล VM บนโครงสร้างพื้นฐานหลายแบบ ต่อยอดจาก VM Operator ที่ VMware ใช้ใน vSphere มากว่า 6 ปี และยังเป็นรุ่น v1alpha1
ประกาศของ Broadcom ระบุว่า VM API ทำให้ VM ถูกสร้างและดูแลผ่าน Kubernetes API บน provider หลายรายที่ต่างกัน และการย้ายโครงการไปอยู่ใต้การดูแลของ CNCF เปิดทางให้ชุมชนร่วมกำหนด API และวิธีดูแล VM ที่หลายแพลตฟอร์มนำไปทำได้ ในวันเดียวกัน Broadcom ประกาศว่าจะเป็นประธานร่วมของ Workload Conformance Working Group กลุ่มใหม่ในชุมชน Kubernetes และมีโซลูชันของพาร์ตเนอร์มากกว่า 20 รายการผ่านการรับรองบน VMware vSphere Kubernetes Service (VKS)
VM API ทำงานอย่างไร
บล็อกของ Daniel Koeck บน VMware Cloud Foundation Blog วันที่ 10 พฤศจิกายน 2026 อธิบายว่า VM API ยืมแนวคิดของ Cluster API ซึ่งเป็นมาตรฐานสร้างคลัสเตอร์ Kubernetes บนหลายแพลตฟอร์ม มาใช้กับ VM โดยแบ่งเป็นสองชั้น
- สัญญากลาง (portable intent): นักพัฒนาเขียนความต้องการของ VM เป็นไฟล์ YAML ของ Kubernetes ตามที่คุ้นเคย
- provider ที่เสียบเพิ่มได้: ปลั๊กอินของแต่ละแพลตฟอร์มรับคำขอนั้นไปสร้าง VM จริง บล็อกเตือนว่าแต่ละ provider มีข้อดีข้อเสียต่างกัน และฟีเจอร์ ประสิทธิภาพ และผลลัพธ์จะขึ้นกับ provider ที่ทำงานจริง
README บน GitHub ระบุว่า resource หลักชื่อ VirtualMachine บอกสเปก CPU หน่วยความจำ สตอเรจ เครือข่าย การตั้งค่าเครื่องตอนบูต และสถานะเปิดปิดที่ต้องการ ช่อง spec.infrastructureRef ชี้ไปยัง resource ของ provider และตัวควบคุมกลาง (generic controller) อ่านสถานะจาก provider ผ่านสัญญาสถานะร่วมกัน โดยไม่ต้องรู้จักโค้ดของ provider รายใด
VM API ยังอยู่ขั้นไหน
ข้อมูลบน GitHub ชี้ว่าโครงการเพิ่งเริ่ม repository vm-api/vm-api ใช้สัญญาอนุญาต Apache 2.0 และยังไม่มี release ที่เผยแพร่ ณ วันที่ 11 พฤศจิกายน 2026
| ประเด็น | สิ่งที่โครงการระบุ |
|---|---|
| รุ่นของ API | vm-api.io/v1alpha1 เป็นทั้งรุ่นที่ให้บริการและรุ่นที่เก็บข้อมูล |
| การติดตั้ง | ติดตั้ง CRD อย่างเดียวยังสร้าง VM ไม่ได้ ต้องมี controller กลาง provider และ resource ของ provider |
| provider | ต้องรายงาน providerID สถานะเปิดปิด ที่อยู่ IP และเงื่อนไขความพร้อม |
| image และเครือข่าย | ยังต้องให้ provider แปลงค่าเอง ยังไม่มี catalog กลาง |
| GPU และ accelerator | เลือกผ่านขนาดเครื่องของ provider ได้ ช่องกลางสำหรับ accelerator ยังอยู่ระหว่างออกแบบ |
| ชุดทดสอบ conformance | อยู่ใน roadmap ยังไม่มี |
roadmap ของโครงการวางงานไว้ 4 ขั้น ได้แก่ ปรับสัญญากลางกับ provider ขยาย provider และชุดทดสอบ conformance เพิ่ม resource สำหรับจัดการ VM เป็นกลุ่ม (VirtualMachineTemplate, VirtualMachineSet, VirtualMachineService, VirtualMachineDeployment) และวางกระบวนการ release กับ governance โดย roadmap ระบุชัดว่า resource เหล่านี้ยังเป็นแผน ไม่ใช่ของที่ใช้ได้แล้ว
Proxmox และ KubeVirt อยู่ตรงไหนของ VM API
บล็อกของ VMware ยกตัวอย่างว่าฝั่งในองค์กร provider อาจเป็น KubeVM Service ที่สร้าง VM บน ESX ของ vSphere หรือปลั๊กอินสำหรับ Proxmox บน KVM และ KubeVirt ส่วนฝั่งคลาวด์อาจสร้าง EC2 บน AWS หรือ VM บน Google Cloud แต่บล็อกเขียนกำกับไว้ว่าแผนภาพและตารางเป็นตัวเลือกที่เป็นไปได้ ไม่ได้แสดง provider ที่มีอยู่ทั้งหมด และให้ดูรายชื่อ provider ที่รองรับจริงใน repository ของโครงการ ส่วน roadmap เขียนว่าจะขยายการเชื่อมต่อกับ vSphere, KubeVirt และแพลตฟอร์ม VM บนคลาวด์
provider เชิงพาณิชย์ที่บล็อกพูดถึงชัดเจนคือ KubeVM Service ของ Broadcom ซึ่งรับคำขอผ่าน VM API แล้วสร้าง VM บน VMware Cloud Foundation โดย VM ยังเห็นใน vCenter และ VCF Operations ใช้ vSphere HA, DRS และ vMotion ได้ตามเดิม รายละเอียดของบริการนี้อยู่ในข่าวKubeVM Service ของ VMware
สิ่งที่ VM API ไม่ได้ทำก็สำคัญพอกัน roadmap ระบุว่าการจัดตารางทรัพยากร high availability และ live migration ยังเป็นหน้าที่ของ provider และ VM API ไม่ได้เป็น hypervisor ไม่ย้ายสถานะของ VM ที่กำลังทำงานหรือดิสก์ข้าม provider
ตัวเลข VM ที่ Broadcom ใช้หนุนเหตุผล
ประกาศของ Broadcom อ้างรายงาน 2026 Virtual Machines Report ของ Linux Foundation ที่เผยแพร่วันเดียวกัน สำรวจผู้ปฏิบัติงาน 492 คนในเดือนกันยายน 2026 โดย Broadcom และ CNCF เป็นผู้สนับสนุนการสำรวจตามที่บล็อกของ VMware ระบุ
- VM รองรับแอปที่ใช้งานจริงเฉลี่ย 53% และมีเพียง 10% ที่ไม่มี VM ใน production เลย
- 61% ตอบว่าทีมดูแล VM กับทีม container หรือ platform ทำงานร่วมกันหรือรวมเป็นทีมเดียวแล้ว
- ในองค์กรที่กำลังขยาย VM 34% ระบุว่างาน AI และ agent เป็นเหตุผลหนึ่ง
Dilpreet Bindra ผู้อำนวยการอาวุโสฝ่ายวิศวกรรมของ VMware Cloud Foundation Division ที่ Broadcom กล่าวในประกาศว่า "เทคโนโลยีของ VMware เป็นมาตรฐานของ virtualization ระดับองค์กรมาหลายทศวรรษ แต่งาน AI และ agentic workflow สมัยใหม่ต้องการให้ VM ทำงานอยู่ในระบบนิเวศ cloud-native" ขณะที่ Matthew Flug ผู้จัดการฝ่ายวิจัยของ IDC กล่าวในประกาศเดียวกันว่าการทำตามมาตรฐานเปิดของ CNCF ช่วยลดความกังวลเรื่องการผูกติดผู้ขาย เมื่อองค์กรตัดสินใจว่างานแต่ละชิ้นควรรันแบบใด
โครงการอื่นที่ Broadcom ประกาศช่วง KubeCon
บล็อกของ Bindra วันที่ 9 พฤศจิกายน 2026 สรุปงานต้นน้ำอีกหลายส่วน
| โครงการ | สิ่งที่ประกาศ |
|---|---|
| Workload Conformance Working Group | Broadcom เป็นประธานร่วม ตั้งเกณฑ์กลางว่า workload ควรทำงานอย่างไรบน Kubernetes หลายค่าย |
| Velero 1.19 | เพิ่มการย้ายข้อมูลระดับ block เพื่อสำรองและกู้คืน persistent volume ขนาดใหญ่ได้เร็วขึ้น |
| COSI | วิศวกร Broadcom ช่วยผลักดัน Container Object Storage Interface ไปสู่ขั้น Beta และพัฒนา vSphere COSI Driver แบบโอเพนซอร์ส |
| Agent Substrate | โครงการใน CNCF Sandbox สำหรับรัน AI agent แบบแยกส่วน Broadcom กำลังประเมินการเชื่อมกับ VKS |
ฝั่ง VKS ประกาศระบุโซลูชันที่ผ่านการรับรอง เช่น Datadog, Grafana Labs, New Relic และ Splunk by Cisco ด้าน observability, CrowdStrike Falcon, Sysdig และ Tigera ด้านความปลอดภัย และ Dell PowerProtect Data Manager กับ Scality RING ด้านสตอเรจ
ทำไมเรื่องนี้สำคัญ
วันนี้การจัดการ VM ผ่าน Kubernetes ผูกอยู่กับแต่ละแพลตฟอร์ม ประกาศของ Broadcom เองยอมรับว่า Kubernetes-native VM management ส่วนใหญ่ยังเป็นของ virtualization แต่ละค่าย ถ้า VM API ได้ provider จากหลายค่ายจริง ทีม platform จะเขียนไฟล์ขอ VM ชุดเดียวแล้วใช้กับหลายที่ได้ คล้ายที่ Cluster API ทำกับคลัสเตอร์ Kubernetes
แต่ตอนนี้ยังเป็นโครงการระดับ Sandbox ซึ่งเป็นขั้นแรกของ CNCF API ยังเป็น alpha และ provider เชิงพาณิชย์ที่ระบุชื่อชัดเจนมีของ Broadcom รายเดียว การยกย่องว่าเป็นมาตรฐานกลางจึงยังเร็วเกินไป สิ่งที่ต้องดูคือมีผู้ดูแลจากค่ายอื่นเข้าร่วมหรือไม่ และ provider ของ KubeVirt หรือ Proxmox จะเกิดขึ้นจริงเมื่อไร
ผลต่อองค์กรไทย
- อย่าใช้ VM API เป็นแผนย้ายระบบ โครงการไม่ย้าย VM หรือดิสก์ระหว่างแพลตฟอร์ม องค์กรที่กำลังประเมินทางเลือกแทน VMwareยังต้องวางแผนย้าย VM แยกต่างหาก
- ติดตามรายชื่อ provider ใน repository ก่อนเลือกแพลตฟอร์มใหม่ ถ้า provider ของ Proxmox หรือ KubeVirt ออกมาจริง ไฟล์ขอ VM ที่ทีมเขียนไว้จะย้ายตามได้ง่ายขึ้น
- ทดลองใน lab ไม่ใช่ production เพราะ API รุ่น v1alpha1 อาจเปลี่ยนโครงสร้าง และยังไม่มีชุดทดสอบ conformance
- ทีมที่ใช้ VCF อยู่แล้ว ให้ดู KubeVM Service ซึ่งเป็น provider ที่ใช้ VM API ได้ก่อน พร้อมถามตัวแทน Broadcom เรื่องรุ่น VCF และเงื่อนไขไลเซนส์
- รวมทีม VM กับทีม Kubernetes ให้คุยภาษาเดียวกัน เรื่องนโยบาย ความปลอดภัย และ GitOps เพราะแนวโน้มนี้ทำให้ VM ถูกสั่งผ่าน Kubernetes มากขึ้น
ติดตามข่าวคลาวด์ Kubernetes และ virtualization ได้ที่หมวดคลาวด์
บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง
VM API ยังไม่ช่วยย้าย VM ออกจาก VMware ได้ องค์กรไทยที่ต้องตัดสินใจก่อนรอบต่ออายุสัญญาจึงยังต้องมีแผนย้ายเครื่องจริง บริการย้าย VMware ไป Proxmox VE ของ THAI DATA CLOUD ประเมินระบบและย้าย VM เป็นขั้นตอน เริ่มจากกลุ่มนำร่อง รันคู่ขนาน และมีแผนย้อนกลับทุกขั้น (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)
คำถามที่พบบ่อย
VM API ใน CNCF คืออะไร?
VM API คือโครงการโอเพนซอร์สที่ Broadcom ส่งเข้า CNCF Sandbox และประกาศเมื่อ 9 พฤศจิกายน 2026 เป็น API กลางบน Kubernetes สำหรับสร้างและดูแลวงจรชีวิตของ VM โดยแยกนิยาม VM กลางออกจาก provider ที่ลงมือสร้าง VM บนแต่ละแพลตฟอร์ม
VM API ใช้กับ Proxmox หรือ KubeVirt ได้แล้วหรือยัง?
ยังไม่มีหลักฐานว่าใช้ได้แล้ว บล็อกของ VMware ยก Proxmox และ KubeVirt เป็นตัวอย่าง provider ที่เป็นไปได้ และระบุให้ดูรายชื่อ provider ที่รองรับจริงใน repository ของโครงการ ส่วน roadmap ของ VM API ระบุว่าจะขยายการเชื่อมต่อกับ vSphere, KubeVirt และแพลตฟอร์ม VM บนคลาวด์ต่อไป
VM API ช่วยย้าย VM ออกจาก VMware ได้หรือไม่?
ไม่ได้โดยตรง roadmap ของ VM API ระบุว่าโครงการไม่ได้ทำหน้าที่ hypervisor และไม่ย้ายสถานะของ VM ที่กำลังทำงานหรือดิสก์ระหว่าง provider สิ่งที่ VM API ให้คือรูปแบบการสั่งสร้างและดูแล VM ผ่าน Kubernetes ที่เหมือนกันบนหลายแพลตฟอร์ม
VM API ต่างจาก KubeVM Service อย่างไร?
บล็อกของ VMware อธิบายว่า VM API เป็นมาตรฐานเปิดสำหรับขอ VM ส่วน KubeVM Service เป็น provider เชิงพาณิชย์ของ Broadcom ที่รับคำขอผ่าน VM API แล้วสร้าง VM บน ESX ใน VMware Cloud Foundation โดย VM ยังเห็นใน vCenter และใช้ vMotion กับ DRS ได้
แหล่งอ้างอิง
- Broadcom Contributes VM API Open Source Project to Cloud Native Computing Foundation — Broadcom
- How VM API and KubeVM Service Deliver Open Standards and Enterprise Execution — VMware Cloud Foundation Blog
- Advancing the Cloud-Native Ecosystem Through Open Collaboration — VMware Cloud Foundation Blog
- vm-api/vm-api: Provider-neutral Kubernetes APIs and core controllers for virtual machine lifecycle management — GitHub
- VM API Roadmap — GitHub
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- Broadcom29CNCF5VMware35GitHub110AWS127Google Cloud106Linux Foundation9IDC13Splunk3Cisco31CrowdStrike7Dell22
- ผลิตภัณฑ์และเทคโนโลยี
- Kubernetes48VMware Cloud Foundation15Microsoft Azure95Proxmox VE26
- เหตุการณ์และงาน
- KubeCon4
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ