Kubernetes สำหรับการจัดการ GPU: การบริหารคลัสเตอร์ GPU หลายพันตัว

อัปเดต 8 ธันวาคม 2025

อัปเดตธันวาคม 2025: Dynamic Resource Allocation (DRA) ของ Kubernetes 1.31+ พร้อมใช้งานอย่างเป็นทางการแล้ว ทำให้สามารถแบ่งพาร์ติชัน GPU และแบ่งเวลาใช้งานได้อย่างละเอียด NVIDIA GPU Operator 24.6+ เพิ่มการรองรับ Blackwell และปรับปรุงการจัดการ MIG Kueue (ระบบจัดคิวงานแบบ native ของ Kubernetes) กำลังเข้าสู่ความพร้อมสำหรับ production สำหรับ workload AI Run:ai และ CoreWeave แสดงให้เห็นคลัสเตอร์ GPU มากกว่า 50,000 ตัวบน Kubernetes เครื่องมือ multi-cluster federation (Liqo, Admiralty) ทำให้สามารถจัดการ GPU ข้ามคลาวด์ได้ การรองรับ vGPU ปรับปรุงดีขึ้นสำหรับการ deploy inference แบบ multi-tenant

OpenAI จัดการ GPU 25,000 ตัวข้ามคลัสเตอร์ Kubernetes หลายตัวเพื่อฝึกโมเดล GPT โดยใช้ custom operators ที่จัดการความล้มเหลวของ GPU โดยอัตโนมัติ ปรับสมดุล workload แบบเรียลไทม์ และรักษาอัตราการใช้งาน 97% แม้จะมีความล้มเหลวของฮาร์ดแวร์เกิดขึ้นทุก 2.5 ชั่วโมงโดยเฉลี่ย¹ ทีมโครงสร้างพื้นฐานของบริษัทค้นพบว่า Kubernetes แบบมาตรฐานล่มที่ประมาณ 5,000 โหนดหากไม่มีการปรับแต่งอย่างกว้างขวาง จึงต้องนำ hierarchical cluster federation, custom scheduling algorithms และ GPU-aware autoscaling ที่ปฏิบัติต่อ H100 ราคา $30,000 แต่ละตัวเป็นทรัพยากรมีค่าที่ต้องติดตามเป็นรายตัว การจัดการ GPU ในระดับขนาดใหญ่แตกต่างอย่างพื้นฐานจากการจัดการ CPU—GPU ที่ล้มเหลวระหว่างการฝึกแบบกระจายสามารถทำให้เสียเวลาการคำนวณมูลค่าหลายล้าน ในขณะที่การจัดตารางที่ไม่ดีซึ่งแยก GPU ที่เชื่อมต่อผ่าน NVLink ทำให้ประสิทธิภาพลดลง 8 เท่า องค์กรที่จัดการ GPU หลายพันตัวบน Kubernetes ได้สำเร็จรายงานอัตราการใช้งานดีขึ้น 35%, เวลา deployment เร็วขึ้น 60% และลด operational overhead 90% เมื่อเทียบกับการจัดการแบบ bare-metal²

Kubernetes ครองตลาด container orchestration ด้วยส่วนแบ่ง 88% แต่การรองรับ GPU มาถึงช้าและยังคงท้าทายในระดับขนาดใหญ่³ NVIDIA GPU Operator ซึ่งเปิดตัวในปี 2019 ในที่สุดก็นำการจัดการ GPU ระดับ enterprise มาสู่ Kubernetes ทำให้มีฟีเจอร์เช่นการติดตั้ง driver แบบไดนามิก, การ deploy device plugin อัตโนมัติ และการตรวจสอบสุขภาพ GPU องค์กรที่รัน AI workload บน Kubernetes ต้องจัดการการตั้งค่า device plugin, node affinity rules, topology-aware scheduling และ resource quotas ที่ป้องกันไม่ให้ทีมเดียวผูกขาดทรัพยากร GPU แต่ผู้ที่เชี่ยวชาญ Kubernetes สำหรับการจัดการ GPU จะได้รับความสามารถในการปฏิบัติต่อ GPU หลายพันตัวเป็น resource pool เดียวที่โปรแกรมได้ บรรลุอัตราการใช้งานและประสิทธิภาพการดำเนินงานที่เป็นไปไม่ได้ด้วย HPC schedulers แบบดั้งเดิม

สถาปัตยกรรม GPU device plugin

กรอบงาน device plugin ของ Kubernetes ช่วยให้สามารถค้นหา, จัดสรร และตรวจสอบสุขภาพ GPU ทั่วทั้งคลัสเตอร์:

NVIDIA GPU Device Plugin ทำหน้าที่เป็นอินเทอร์เฟซหลักระหว่าง Kubernetes และ NVIDIA GPUs⁴ Plugin รันเป็น DaemonSet บนทุก GPU node โดยลงทะเบียน GPU เป็นทรัพยากรที่ scheduler ใช้ได้กับ kubelet ระหว่างการเริ่มต้น plugin จะสอบถาม NVIDIA Management Library (NVML) เพื่อค้นหา GPU ที่มีอยู่ ความจุหน่วยความจำ ความสามารถในการคำนวณ และโทโพโลยีการเชื่อมต่อ Plugin ประกาศ GPU ให้ Kubernetes scheduler โดยใช้ชื่อทรัพยากร nvidia.com/gpu ทำให้ pod สามารถร้องขอ GPU ผ่านข้อกำหนดทรัพยากรมาตรฐาน

ขั้นตอนการลงทะเบียน Device Plugin: 1. Plugin เริ่มต้นและค้นหา GPU ในเครื่องผ่าน NVML 2. ลงทะเบียนกับ kubelet ผ่าน Unix socket ที่ /var/lib/kubelet/device-plugins/ 3. ประกาศ GPU ที่มีอยู่พร้อม device ID ที่ไม่ซ้ำกัน 4. implement Allocate() RPC สำหรับการมอบหมาย GPU ให้ container 5. ตรวจสอบสุขภาพ GPU และรายงานความล้มเหลวให้ kubelet 6. จัดการการทำความสะอาด GPU เมื่อ pod สิ้นสุด

Multi-Instance GPU (MIG) Support ช่วยให้สามารถแบ่งพาร์ติชัน A100 และ H100 GPUs เป็น instance ที่แยกจากกัน⁵ แต่ละ MIG instance ปรากฏเป็น GPU แยกต่างหากสำหรับ Kubernetes ทำให้สามารถจัดสรรทรัพยากรได้อย่างละเอียด Device plugin จัดการ MIG profiles โดยจัดการการสร้าง การลบ และการมอบหมาย instance องค์กรบรรลุการใช้งาน GPU ดีขึ้น 7 เท่าโดยการแบ่งพาร์ติชัน GPU ที่ใช้งานไม่เต็มที่สำหรับ workload ขนาดเล็ก การตั้งค่า MIG ต้องมีการวางแผนอย่างรอบคอบเนื่องจากโหมดการแบ่งพาร์ติชันไม่สามารถเปลี่ยนได้โดยไม่ต้อง drain nodes

Device Plugins ทางเลือก ให้ความหลากหลายของผู้ผลิต: - AMD Device Plugin รองรับ GPU ที่เปิดใช้งาน ROCm เช่น MI250X - Intel Device Plugin จัดการ Intel GPUs และ Gaudi accelerators - Xilinx FPGA Device Plugin จัดการทรัพยากร FPGA - Google TPU Device Plugin สำหรับ GKE clusters

กลยุทธ์การจัดตารางสำหรับ GPU workloads

การจัดตาราง GPU ที่มีประสิทธิภาพเพิ่มการใช้งานสูงสุดในขณะที่รักษาประสิทธิภาพ:

Gang Scheduling รับประกันว่างานฝึกแบบกระจายจะได้รับ GPU ทั้งหมดที่ร้องขอพร้อมกัน หากไม่มี gang scheduling การจัดสรรทรัพยากรบางส่วนจะทำให้เกิด deadlock—งานรอตลอดไปสำหรับ GPU ที่เหลือที่ไม่เคยพร้อมใช้งาน Kubernetes scheduler plugins เช่น Volcano และ Apache YuniKorn implement gang scheduling ผ่าน PodGroups⁶ งานระบุความต้องการ GPU ขั้นต่ำ และ scheduler จะจัดสรรทรัพยากรทั้งหมดหรือจัดคิวทั้งงาน Gang scheduling ลดการใช้งานคลัสเตอร์ 10-15% แต่ป้องกันการอดทรัพยากรของงานฝึก

Topology-Aware Scheduling เพิ่มประสิทธิภาพการวาง GPU ตามการเชื่อมต่อฮาร์ดแวร์ GPU ที่เชื่อมต่อผ่าน NVLink บรรลุ bandwidth 600GB/s เทียบกับ 32GB/s ผ่าน PCIe⁷ Scheduler ตรวจสอบโทโพโลยีของ node เพื่อวาง pods ที่เกี่ยวข้องบน GPU ที่มีการเชื่อมต่อเร็ว NVIDIA GPU Feature Discovery ติดป้าย nodes ด้วยข้อมูลโทโพโลยีที่ทำให้สามารถใช้ affinity rules ได้ การตัดสินใจโทโพโลยีที่ไม่ดีทำให้ประสิทธิภาพลดลง 3-8 เท่าสำหรับ workload ที่มีการสื่อสารหนัก การรับรู้โทโพโลยีกลายเป็นสิ่งสำคัญเมื่อเกิน 8 GPU ต่องาน

Bin Packing vs Spreading: Bin packing รวม workloads บน nodes น้อยลง ปรับปรุง cache locality และลด network traffic Spreading กระจายงานข้ามโหนดเพื่อ fault tolerance และการจัดการความร้อนที่ดีขึ้น กลยุทธ์ที่เหมาะสมขึ้นอยู่กับลักษณะของ workload—งานฝึกได้ประโยชน์จาก bin packing ในขณะที่ inference ชอบ spreading กลยุทธ์แบบไดนามิกปรับตามการใช้งานคลัสเตอร์และส่วนผสมของ workload

Priority and Preemption: Production workloads ได้รับ priority สูงกว่างานพัฒนา Scheduler จะ preempt pods ที่มี priority ต่ำกว่าเมื่อทรัพยากรขาดแคลน การตั้งค่า priority อย่างรอบคอบป้องกันงานวิจัยไม่ให้บล็อก production inference การทำ preemption checkpointing รับประกันว่าความคืบหน้าการฝึกไม่สูญหาย Priority classes มีตั้งแต่ system-critical (1000000) ถึง development (100)

Fair Sharing and Quotas: Resource quotas ป้องกันไม่ให้ทีมเดียวผูกขาด GPU Hierarchical quotas ทำให้มีขีดจำกัดทั้งองค์กรพร้อม sub-quotas เฉพาะทีม Fair share scheduling รับประกันการกระจายทรัพยากรอย่างเป็นธรรมตลอดเวลา ผู้ใช้ที่ใช้ทรัพยากรน้อยกว่าจะสะสมเครดิตสำหรับ burst capacity ในอนาคต ระบบคิวเช่น Kueue ให้การจัดคิวงานพร้อม admission control ที่ซับซ้อน

ข้อพิจารณาในการขยายระบบ

การขยาย Kubernetes เป็น GPU หลายพันตัวต้องมีการปรับเปลี่ยนสถาปัตยกรรม:

ข้อจำกัดขนาดคลัสเตอร์: Kubernetes clusters เดียวรองรับสูงสุด 5,000 nodes ก่อนที่ประสิทธิภาพ etcd จะลดลง⁸ โหลด API server เพิ่มขึ้นแบบ quadratic กับจำนวน node เนื่องจากกลไก watch Controller manager reconciliation loops ช้าลงเกิน 1,000 nodes Network policies กลายเป็นเรื่องยุ่งยากในระดับขนาดใหญ่ องค์กรส่วนใหญ่จำกัดคลัสเตอร์ไว้ที่ 500-1,000 GPU nodes เพื่อความเสถียรในการดำเนินงาน

Multi-Cluster Federation: การ deploy ขนาดใหญ่ใช้หลาย Kubernetes clusters ที่จัดการผ่าน federation Admiralty หรือ Virtual Kubelet ทำให้สามารถจัดตารางข้ามคลัสเตอร์ได้ เครื่องมือ GitOps เช่น Flux หรือ ArgoCD ซิงโครไนซ์การตั้งค่าข้ามคลัสเตอร์ เทคโนโลยี Service mesh ให้ networking ข้ามคลัสเตอร์ Federation เพิ่มความซับซ้อนแต่ทำให้สามารถขยายในแนวนอนเกินขีดจำกัดคลัสเตอร์เดียว

Hierarchical Resource Management: จัดระเบียบคลัสเตอร์แบบลำดับชั้นโดยมี management clusters ควบคุม workload clusters Management clusters รัน control plane components และ scheduling logic Workload clusters โฮสต์ GPU pods โดยไม่มี controllers ที่ซับซ้อน การออกแบบแบบลำดับชั้นลดรัศมีผลกระทบของความล้มเหลว การแยก concerns อย่างชัดเจนทำให้การแก้ไขปัญหาง่ายขึ้น

Custom Resource Definitions (CRDs) สำหรับ AI workloads: - TrainingJob: กำหนดข้อกำหนดการฝึกแบบกระจาย - InferenceService: จัดการการ deploy model serving - GPUPool: แสดงการจัดกลุ่ม GPU แบบ logical - Checkpoint: จัดการการเก็บสถานะการฝึก - ModelVersion: ติดตาม iterations และ lineage ของโมเดล

การเพิ่มประสิทธิภาพสำหรับระดับขนาดใหญ่: - ปิดการใช้งาน admission webhooks ที่ไม่ได้ใช้เพื่อลด API latency - implement pod topology spread constraints สำหรับการกระจายที่สม่ำเสมอ - ใช้ local SSD สำหรับ container images เพื่อหลีกเลี่ยง network bottleneck - เปิดใช้งาน CPU manager สำหรับการจัดสรร CPU ที่รับประกัน - ตั้งค่า huge pages สำหรับความต้องการหน่วยความจำโมเดลขนาดใหญ่

การตรวจสอบและการสังเกตการณ์

การตรวจสอบที่ครอบคลุมป้องกันเวลาว่างของ GPU มูลค่าล้านดอลลาร์:

NVIDIA Data Center GPU Manager (DCGM) ให้ metrics เฉพาะ GPU ที่ไม่มีในการตรวจสอบ Kubernetes มาตรฐาน⁹ DCGM export metrics มากกว่า 100 รายการรวมถึง SM utilization, memory bandwidth, อุณหภูมิ, การใช้พลังงาน และ ECC errors การรวม Prometheus ทำให้สามารถจัดเก็บ metrics ระยะยาวและการแจ้งเตือน Grafana dashboards แสดงภาพประสิทธิภาพ GPU ทั่วทั้ง fleet Custom alerts ตรวจจับ GPU ที่ใช้งานไม่เต็มที่, thermal throttling และการเสื่อมสภาพของฮาร์ดแวร์ก่อนที่จะเกิดความล้มเหลว

Key GPU Metrics สำหรับการตรวจสอบ Kubernetes: - GPU Utilization: เปอร์เซ็นต์ของ SMs ที่ active (เป้าหมาย >90%) - Memory Utilization: หน่วยความจำ GPU ที่จัดสรรเทียบกับที่มีอยู่ - Power Draw: การใช้พลังงานจริงเทียบกับ TDP บ่งชี้ throttling - Temperature: อุณหภูมิ GPU และหน่วยความจำ - PCIe Bandwidth: อัตราการถ่ายโอนข้อมูลเข้า/ออกจาก GPU - NVLink Traffic: bandwidth การสื่อสารระหว่าง GPU - Training Metrics: loss curves, gradient norms, learning rates - Inference Metrics: requests ต่อวินาที, P99 latency, batch sizes

Distributed Tracing ติดตาม requests ข้าม GPU และ nodes หลายตัว OpenTelemetry instrumentation จับเวลา training step, latency การโหลดข้อมูล และระยะเวลา checkpoint Jaeger หรือ Tempo ให้การจัดเก็บและการวิเคราะห์ distributed trace ความสัมพันธ์ระหว่าง traces และ metrics ระบุ performance bottlenecks การมองเห็นแบบ end-to-end ลดเวลาเฉลี่ยในการแก้ไข 70%

Log Aggregation รวมศูนย์ logs จาก GPU pods หลายพัน Fluentd หรือ Fluent Bit รวบรวม container logs ด้วย overhead น้อยที่สุด Elasticsearch จัดเก็บ logs พร้อมการ indexing และนโยบาย retention อัตโนมัติ Kibana ทำให้สามารถค้นหาและวิเคราะห์ logs ทั่วทั้งคลัสเตอร์ Structured logging ที่มีรูปแบบสอดคล้องกันทำให้การแก้ไขปัญหาง่ายขึ้น แจ้งเตือนเกี่ยวกับรูปแบบ error ที่บ่งชี้ปัญหาระบบ

Introl deploy และจัดการ Kubernetes clusters สำหรับการจัดการ GPU ทั่ว พื้นที่ให้บริการทั่วโลก ของเรา พร้อมความเชี่ยวชาญในการขยายระบบถึง 10,000+ GPU deployments¹⁰ ทีม platform engineering ของเราได้ implement custom operators และการปรับปรุง scheduling สำหรับการใช้งาน GPU ที่เหมาะสมที่สุด

รูปแบบการ deploy สำหรับ production

สถาปัตยกรรม Training Cluster ที่ Anthropic: - Scale: 4,000 GPUs ข้าม 8 Kubernetes clusters - Topology: Hierarchical federation พร้อม central scheduler - Storage: Distributed Lustre filesystem สำหรับ training data - Networking: RoCE v2 fabric พร้อม 200Gbps ต่อ node - Scheduling: Custom gang scheduler พร้อม topology awareness - Monitoring: DCGM + Prometheus พร้อม scrape intervals 15 วินาที - ผลลัพธ์: GPU utilization 94%, ลดเวลาการฝึก 50%

Inference Platform ที่ Uber: - Workload: 500 ล้าน predictions ต่อวัน - Infrastructure: 2,000 T4 GPUs ข้าม 20 regions - Orchestration: Kubernetes พร้อม Knative สำหรับ serverless - Autoscaling: Predictive scaling ตามรูปแบบ traffic - Load Balancing: Envoy proxy พร้อม least-latency routing - Optimization: Model caching ลด cold start เหลือ 2 วินาที - ผลลัพธ์: ลดต้นทุน 65% เทียบกับสถาปัตยกรรมก่อนหน้า

Hybrid Training-Inference ที่ Spotify: - GPUs: 3,000 mixed V100/A100/T4 fleet - Scheduling: Time-sliced sharing สำหรับการพัฒนา - Isolation: Kata containers สำหรับ multi-tenant security - Cos

[เนื้อหาถูกตัดสำหรับการแปล]