Kubernetes สำหรับการจัดการ GPU: การบริหารจัดการคลัสเตอร์ GPU หลายพันตัว
อัปเดต 8 ธันวาคม 2025
การอัปเดตธันวาคม 2025: Kubernetes 1.31+ Dynamic Resource Allocation (DRA) พร้อมใช้งานแล้ว ช่วยให้สามารถแบ่งพาร์ทิชัน GPU และ time-slicing ได้อย่างละเอียด NVIDIA GPU Operator 24.6+ เพิ่มการรองรับ Blackwell และปรับปรุงการจัดการ MIG Kueue (การจัดคิว job แบบ Kubernetes-native) กำลังสู่ความพร้อมระดับการใช้งานจริงสำหรับ AI workloads Run.ai และ CoreWeave แสดงให้เห็นคลัสเตอร์ GPU มากกว่า 50,000 ตัวบน Kubernetes เครื่องมือ federation หลายคลัสเตอร์ (Liqo, Admiralty) ช่วยให้สามารถจัดการ GPU ข้าม cloud ได้ การรองรับ vGPU ปรับปรุงขึ้นสำหรับการปรับใช้ inference แบบ multi-tenant
OpenAI จัดการ GPU 25,000 ตัวข้ามหลายคลัสเตอร์ Kubernetes เพื่อฝึก GPT models โดยใช้ custom operators ที่จัดการข้อผิดพลาด GPU โดยอัตโนมัติ ปรับสมดุล workloads แบบ real-time และรักษาการใช้งาน 97% แม้จะมีข้อผิดพลาดฮาร์ดแวร์เกิดขึ้นทุก 2.5 ชั่วโมงโดยเฉลี่ย¹ ทีมโครงสร้างพื้นฐานของบริษัทค้นพบว่า vanilla Kubernetes จะล่มสลายที่ประมาณ 5,000 nodes หากไม่มีการปรับแต่งอย่างละเอียด ทำให้พวกเขาต้องใช้ hierarchical cluster federation, custom scheduling algorithms และ GPU-aware autoscaling ที่ปฏิบัติต่อ H100 แต่ละตัวที่มีราคา $30,000 เป็นทรัพยากรมีค่าที่ต้องติดตามแต่ละตัว การจัดการ GPU ในระดับใหญ่แตกต่างจากการจัดการ CPU โดยพื้นฐาน—GPU ที่ล้มเหลวระหว่าง distributed training สามารถสูญเสียค่าคำนวณหลายล้าน ในขณะที่การจัดกำหนดการที่แย่ซึ่งแยก GPUs ที่เชื่อมต่อผ่าน NVLink ทำให้ประสิทธิภาพลดลง 8 เท่า องค์กรที่สามารถจัดการ GPUs หลายพันตัวบน Kubernetes สำเร็จรายงานการใช้งานที่ดีขึ้น 35%, เวลาปรับใช้เร็วขึ้น 60% และลดค่าใช้จ่ายในการดำเนินงาน 90% เมื่อเปรียบเทียบกับการจัดการ bare-metal²
Kubernetes ครองตลาด container orchestration ด้วยส่วนแบ่งตลาด 88% แต่การรองรับ GPU มาช้าและยังคงท้าทายในระดับใหญ่³ NVIDIA GPU Operator ที่เปิดตัวในปี 2019 ในที่สุดก็นำการจัดการ GPU ระดับองค์กรมาสู่ Kubernetes ช่วยให้มีฟีเจอร์อย่างการติดตั้งไดรเวอร์แบบ dynamic, การปรับใช้ device plugin อัตโนมัติ และการตรวจสอบสุขภาพ GPU องค์กรที่รัน AI workloads บน Kubernetes ต้องจัดการกับการกำหนดค่า device plugin, กฎ node affinity, topology-aware scheduling และ resource quotas ที่ป้องกันไม่ให้ทีมใดทีมหนึ่งผูกขาด GPU resources แต่ผู้ที่เชี่ยวชาญ Kubernetes สำหรับการจัดการ GPU จะได้รับความสามารถในการปฏิบัติต่อ GPUs หลายพันตัวเป็นกลุ่มทรัพยากรที่โปรแกรมได้เพียงกลุ่มเดียว บรรลุอัตราการใช้งานและประสิทธิภาพการดำเนินงานที่เป็นไปไม่ได้ด้วย HPC schedulers แบบดั้งเดิม
สถาปัตยกรรม GPU device plugin
framework device plugin ของ Kubernetes ช่วยให้สามารถค้นหา จัดสรร และตรวจสอบสุขภาพ GPU ข้ามคลัสเตอร์:
NVIDIA GPU Device Plugin ทำหน้าที่เป็น interface หลักระหว่าง Kubernetes และ NVIDIA GPUs⁴ plugin ทำงานเป็น DaemonSet บนทุก GPU node โดยลงทะเบียน GPUs เป็น schedulable resources กับ kubelet ระหว่างการเริ่มต้น plugin จะ query NVIDIA Management Library (NVML) เพื่อค้นหา GPUs ที่มีอยู่ ความจุหน่วยความจำ compute capability และ interconnect topology plugin โฆษณา GPUs ไปยัง Kubernetes scheduler โดยใช้ชื่อทรัพยากร nvidia.com/gpu ทำให้ pods สามารถขอ GPUs ผ่านการระบุทรัพยากรมาตรฐาน
Device Plugin Registration Flow: 1. Plugin เริ่มต้นและค้นหา local GPUs ผ่าน NVML 2. ลงทะเบียนกับ kubelet ผ่าน Unix socket ที่ /var/lib/kubelet/device-plugins/ 3. โฆษณา GPUs ที่มีอยู่ด้วย device IDs ที่ไม่ซ้ำ 4. ใช้ Allocate() RPC สำหรับการมอบหมาย GPU ให้กับ container 5. ตรวจสอบสุขภาพ GPU และรายงานความล้มเหลวไปยัง kubelet 6. จัดการการ cleanup GPU ระหว่างการสิ้นสุด pod
การรองรับ Multi-Instance GPU (MIG) ช่วยให้สามารถแบ่งพาร์ทิชัน A100 และ H100 GPUs เป็น instances ที่แยกจากกัน⁵ แต่ละ MIG instance ปรากฏเป็น GPU แยกต่างหากไปยัง Kubernetes ช่วยให้สามารถจัดสรรทรัพยากรได้อย่างละเอียด device plugin จัดการ MIG profiles โดยจัดการการสร้าง การลบ และการมอบหมาย instances องค์กรบรรลุการใช้งาน GPU ที่ดีขึ้น 7 เท่าโดยการแบ่งพาร์ทิชัน GPUs ที่ใช้งานไม่เต็มที่สำหรับ workloads ขนาดเล็ก การกำหนดค่า MIG ต้องการการวางแผนอย่างระมัดระวังเนื่องจากโหมดพาร์ทิชันไม่สามารถเปลี่ยนได้โดยไม่ต้อง drain nodes
Alternative Device Plugins ให้ความหลากหลายของผู้จำหน่าย: - AMD Device Plugin รองรับ ROCm-enabled GPUs อย่าง MI250X - Intel Device Plugin จัดการ Intel GPUs และ Gaudi accelerators - Xilinx FPGA Device Plugin จัดการทรัพยากร FPGA - Google TPU Device Plugin สำหรับ GKE clusters
กลยุทธ์การจัดกำหนดการสำหรับ GPU workloads
การจัดกำหนดการ GPU ที่มีประสิทธิภาพเพิ่มการใช้งานสูงสุดในขณะที่รักษาประสิทธิภาพ:
Gang Scheduling ช่วยให้มั่นใจว่า distributed training jobs จะได้รับ GPUs ที่ขอทั้งหมดพร้อมกัน หากไม่มี gang scheduling การจัดสรรทรัพยากรบางส่วนทำให้เกิด deadlock—jobs รอ GPUs ที่เหลือไม่มีที่สิ้นสุด Kubernetes scheduler plugins อย่าง Volcano และ Apache YuniKorn ใช้ gang scheduling ผ่าน PodGroups⁶ Jobs ระบุความต้องการ GPU ขั้นต่ำ และ scheduler จะจัดสรรทรัพยากรทั้งหมดหรือจัดคิว job ทั้งหมด Gang scheduling ลดการใช้งานคลัสเตอร์ 10-15% แต่ป้องกันการขาดแคลน training job
Topology-Aware Scheduling เพิ่มประสิทธิภาพการจัดวาง GPU ตาม hardware interconnects GPUs ที่เชื่อมต่อผ่าน NVLink บรรลุแบนด์วิดท์ 600GB/s เทียบกับ 32GB/s ผ่าน PCIe⁷ scheduler ตรวจสอบ node topology เพื่อวาง related pods บน GPUs ที่มี interconnects เร็ว NVIDIA GPU Feature Discovery ใส่ label nodes ด้วยข้อมูล topology ที่ช่วยให้มีกฎ affinity การตัดสินใจ topology ที่แย่ทำให้ประสิทธิภาพลดลง 3-8 เท่าสำหรับ workloads ที่ใช้การสื่อสารมาก Topology awareness กลายเป็นสิ่งสำคัญเมื่อเกิน 8 GPUs ต่อ job
Bin Packing vs Spreading: Bin packing รวม workloads บน nodes น้อยลง ปรับปรุง cache locality และลดการรับส่งข้อมูลเครือข่าย Spreading กระจายงานข้าม nodes เพื่อความทนทานต่อข้อผิดพลาดที่ดีขึ้นและการจัดการความร้อน กลยุทธ์ที่เหมาะสมขึ้นอยู่กับลักษณะ workload—training jobs ได้ประโยชน์จาก bin packing ขณะที่ inference ชอบ spreading กลยุทธ์แบบ dynamic ปรับตามการใช้งานคลัสเตอร์และส่วนผสม workload
Priority และ Preemption: Production workloads ได้รับ priority สูงกว่า development jobs scheduler preempt pods ที่มี priority ต่ำเมื่อทรัพยากรหายาก การกำหนดค่า priority อย่างระมัดระวังป้องกัน research jobs จากการบล็อก production inference Preemption checkpointing ช่วยให้มั่นใจว่าความคืบหน้าการฝึกอบรมไม่สูญหาย Priority classes มีตั้งแต่ system-critical (1000000) ถึง development (100)
Fair Sharing และ Quotas: Resource quotas ป้องกันไม่ให้ทีมใดทีมหนึ่งผูกขาด GPUs Hierarchical quotas ช่วยให้มีข้อจำกัดทั่วทั้งองค์กรด้วย sub-quotas เฉพาะทีม Fair share scheduling ช่วยให้มั่นใจในการกระจายทรัพยากรอย่างเป็นธรรมตามเวลา ผู้ใช้ที่ใช้ทรัพยากรน้อยสะสม credits สำหรับความจุ burst ในอนาคต Queue systems อย่าง Kueue ให้การจัดคิว job ด้วย admission control ที่ซับซ้อน
การพิจารณาการปรับขนาด
การปรับขนาด Kubernetes ไปยัง GPUs หลายพันตัวต้องการการปรับแต่งสถาปัตยกรรม:
ข้อจำกัดขนาดคลัสเตอร์: คลัสเตอร์ Kubernetes เดี่ยวรองรับ nodes สูงสุด 5,000 ก่อนที่ประสิทธิภาพ etcd จะลดลง⁸ โหลด API server เพิ่มขึ้นแบบกำลังสองกับจำนวน node เนื่องจากกลไก watch Controller manager reconciliation loops ช้าลงเกิน 1,000 nodes Network policies กลายเป็นเรื่องยุ่งยากในระดับใหญ่ องค์กรส่วนใหญ่จำกัดคลัสเตอร์ที่ 500-1,000 GPU nodes เพื่อความเสถียรในการดำเนินงาน
Multi-Cluster Federation: การปรับใช้ขนาดใหญ่ใช้หลายคลัสเตอร์ Kubernetes ที่จัดการผ่าน federation Admiralty หรือ Virtual Kubelet ช่วยให้สามารถจัดกำหนดการข้ามคลัสเตอร์ได้ เครื่องมือ GitOps อย่าง Flux หรือ ArgoCD ซิงโครไนซ์การกำหนดค่าข้ามคลัสเตอร์ เทคโนโลยี Service mesh ให้เครือข่ายข้ามคลัสเตอร์ Federation เพิ่มความซับซ้อนแต่ช่วยให้สามารถปรับขนาดแนวนอนเกินข้อจำกัดคลัสเตอร์เดี่ยว
Hierarchical Resource Management: จัดระเบียบคลัสเตอร์แบบลำดับชั้นด้วย management clusters ที่ควบคุม workload clusters Management clusters รัน control plane components และ scheduling logic Workload clusters โฮสต์ GPU pods โดยไม่มี controllers ที่ซับซ้อน การออกแบบแบบลำดับชั้นลดรัศมีระเบิดของความล้มเหลว การแยกกิจกรรมที่ชัดเจนทำให้การแก้ไขปัญหาง่ายขึ้น
Custom Resource Definitions (CRDs) สำหรับ AI workloads: - TrainingJob: กำหนด distributed training specifications - InferenceService: จัดการ model serving deployments - GPUPool: แสดงการจัดกลุ่ม GPU เชิงตรรกะ - Checkpoint: จัดการความคงอยู่ของสถานะการฝึก - ModelVersion: ติดตาม model iterations และ lineage
การเพิ่มประสิทธิภาพสำหรับระดับใหญ่: - ปิดใช้งาน admission webhooks ที่ไม่ได้ใช้เพื่อลด API latency - ใช้ pod topology spread constraints สำหรับการกระจายที่สม่ำเสมอ - ใช้ local SSD สำหรับ container images หลีกเลี่ยง network bottleneck - เปิดใช้งาน CPU manager สำหรับการจัดสรร CPU ที่รับประกัน - กำหนดค่า huge pages สำหรับความต้องการหน่วยความจำ model ขนาดใหญ่
การตรวจสอบและการสังเกตการณ์
การตรวจสอบที่ครอบคลุมป้องกันเวลา GPU ว่างเปล่าหลายล้านดอลลาร์:
NVIDIA Data Center GPU Manager (DCGM) ให้ metrics เฉพาะ GPU ที่ไม่มีผ่านการตรวจสอบ Kubernetes มาตรฐาน⁹ DCGM ส่งออก metrics มากกว่า 100 รายการรวมถึง SM utilization, memory bandwidth, อุณหภูมิ, การใช้พลังงาน และ ECC errors การรวม Prometheus ช่วยให้สามารถจัดเก็บ metrics ระยะยาวและการแจ้งเตือน Grafana dashboards แสดง GPU performance ข้ามกอง fleet ทั้งหมด การแจ้งเตือนแบบกำหนดเองตรวจจับ GPUs ที่ใช้งานไม่เต็มที่ thermal throttling และการเสื่อมสภาพฮาร์ดแวร์ก่อนที่จะเกิดความล้มเหลว
Key GPU Metrics สำหรับการตรวจสอบ Kubernetes: - GPU Utilization: เปอร์เซ็นต์ของ SMs ที่ใช้งาน (เป้าหมาย >90%) - Memory Utilization: GPU memory ที่จัดสรรเทียบกับที่มีอยู่ - Power Draw: จริงเทียบกับ TDP ที่ระบุการ throttling - Temperature: อุณหภูมิ GPU และหน่วยความจำ - PCIe Bandwidth: อัตราการถ่ายโอนข้อมูลไปยัง/จาก GPU - NVLink Traffic: แบนด์วิดท์การสื่อสารระหว่าง GPU - Training Metrics: Loss curves, gradient norms, learning rates - Inference Metrics: Requests ต่อวินาที, P99 latency, batch sizes
Distributed Tracing ติดตาม requests ข้ามหลาย GPUs และ nodes การเครื่องมือ OpenTelemetry จับเวลาขั้นตอนการฝึก, data loading latency และระยะเวลา checkpoint Jaeger หรือ Tempo ให้การจัดเก็บและการวิเคราะห์ distributed trace ความสัมพันธ์ระหว่าง traces และ metrics ระบุคอขวดประสิทธิภาพ การมองเห็นแบบ end-to-end ลดเวลาเฉลี่ยในการแก้ไข 70%
Log Aggregation รวม logs จาก GPU pods หลายพัน Fluentd หรือ Fluent Bit รวบรวม container logs ด้วย overhead ขั้นต่ำ Elasticsearch เก็บ logs ด้วย automatic indexing และ retention policies Kibana ช่วยให้สามารถค้นหาและวิเคราะห์ logs ข้ามคลัสเตอร์ทั้งหมด Structured logging ด้วยรูปแบบที่สม่ำเสมอทำให้การแก้ไขปัญหาง่ายขึ้น แจ้งเตือนเมื่อมีรูปแบบข้อผิดพลาดที่ระบุปัญหาระบบ
Introl ปรับใช้และจัดการคลัสเตอร์ Kubernetes สำหรับการจัดการ GPU ข้ามพื้นที่ความครอบคลุมทั่วโลกของเรา ด้วยความเชี่ยวชาญในการปรับขนาดไปยังการปรับใช้ GPU มากกว่า 10,000 ตัว¹⁰ ทีมวิศวกรรมแพลตฟอร์มของเราได้ใช้ custom operators และการปรับปรุงการจัดกำหนดการเพื่อการใช้งาน GPU ที่เหมาะสม
รูปแบบการปรับใช้ในการใช้งานจริง
Training Cluster Architecture ที่ Anthropic: - Scale: GPUs 4,000 ตัวข้าม 8 คลัสเตอร์ Kubernetes - Topology: Hierarchical federation ด้วย central scheduler - Storage: ระบบไฟล์ Lustre แบบกระจายสำหรับข้อมูลการฝึก - Networking: RoCE v2 fabric ด้วย 200Gbps ต่อ node - Scheduling: Custom gang scheduler ด้วยการรับรู้ topology - Monitoring: DCGM + Prometheus ด้วย scrape intervals 15 วินาที - Result: การใช้งาน GPU 94%, ลดเวลาการฝึก 50%
Inference Platform ที่ Uber: - Workload: การคาดการณ์ 500 ล้านครั้งต่อวัน - Infrastructure: T4 GPUs 2,000 ตัวข้าม 20 regions - Orchestration: Kubernetes ด้วย Knative สำหรับ serverless - Autoscaling: Predictive scaling ตามรูปแบบ traffic - Load Balancing: Envoy proxy ด้วย least-latency routing - Optimization: Model caching ลด cold start เหลือ 2 วินาที - Outcome: ลดต้นทุน 65% เทียบกับสถาปัตยกรรมก่อนหน้า
Hybrid Training-Inference ที่ Spotify: - GPUs: กอง fleet V100/A100/T4 ผสม 3,000 ตัว - Scheduling: Time-sliced sharing สำหรับการพัฒนา - Isolation: Kata containers สำหรับความปลอดภัย multi-tenant - Cos
