Kubernetes untuk Orkestrasi GPU: Mengelola Kluster dengan Ribuan GPU

Diperbarui 8 Desember 2025

Pembaruan Desember 2025: Dynamic Resource Allocation (DRA) Kubernetes 1.31+ kini GA, memungkinkan partisi GPU yang lebih granular dan time-slicing. NVIDIA GPU Operator 24.6+ menambahkan dukungan Blackwell dan manajemen MIG yang lebih baik. Kueue (job queueing native Kubernetes) mencapai kematangan produksi untuk beban kerja AI. Run:ai dan CoreWeave mendemonstrasikan kluster 50.000+ GPU di Kubernetes. Alat federasi multi-kluster (Liqo, Admiralty) memungkinkan orkestrasi GPU lintas cloud. Dukungan vGPU meningkat untuk deployment inferensi multi-tenant.

OpenAI mengorkestrasi 25.000 GPU di berbagai kluster Kubernetes untuk melatih model GPT, menggunakan operator kustom yang secara otomatis menangani kegagalan GPU, menyeimbangkan ulang beban kerja secara real-time, dan mempertahankan utilisasi 97% meskipun kegagalan perangkat keras terjadi rata-rata setiap 2,5 jam.¹ Tim infrastruktur perusahaan menemukan bahwa Kubernetes vanilla kolaps di sekitar 5.000 node tanpa modifikasi ekstensif, memaksa mereka mengimplementasikan federasi kluster hierarkis, algoritma penjadwalan kustom, dan autoscaling sadar-GPU yang memperlakukan setiap H100 seharga $30.000 sebagai sumber daya berharga yang memerlukan pelacakan individual. Mengelola GPU dalam skala besar berbeda secara fundamental dari orkestrasi CPU—GPU yang gagal selama pelatihan terdistribusi dapat membuang jutaan dolar dalam waktu komputasi, sementara penjadwalan yang buruk yang memisahkan GPU yang terhubung via NVLink menyebabkan degradasi kinerja 8x lipat. Organisasi yang berhasil mengorkestrasi ribuan GPU di Kubernetes melaporkan utilisasi 35% lebih baik, waktu deployment 60% lebih cepat, dan pengurangan overhead operasional 90% dibandingkan manajemen bare-metal.²

Kubernetes mendominasi orkestrasi container dengan pangsa pasar 88%, tetapi dukungan GPU datang terlambat dan tetap menantang dalam skala besar.³ NVIDIA GPU Operator, diluncurkan pada 2019, akhirnya membawa manajemen GPU kelas enterprise ke Kubernetes, memungkinkan fitur seperti instalasi driver dinamis, deployment device plugin otomatis, dan pemantauan kesehatan GPU. Organisasi yang menjalankan beban kerja AI di Kubernetes harus menavigasi konfigurasi device plugin, aturan node affinity, penjadwalan sadar-topologi, dan kuota sumber daya yang mencegah tim tunggal memonopoli sumber daya GPU. Namun mereka yang menguasai Kubernetes untuk orkestrasi GPU mendapatkan kemampuan untuk memperlakukan ribuan GPU sebagai satu kumpulan sumber daya yang dapat diprogram, mencapai tingkat utilisasi dan efisiensi operasional yang tidak mungkin dengan penjadwal HPC tradisional.

Arsitektur device plugin GPU

Framework device plugin Kubernetes memungkinkan penemuan, alokasi, dan pemantauan kesehatan GPU di seluruh kluster:

NVIDIA GPU Device Plugin berfungsi sebagai antarmuka utama antara Kubernetes dan GPU NVIDIA.⁴ Plugin ini berjalan sebagai DaemonSet di setiap node GPU, mendaftarkan GPU sebagai sumber daya yang dapat dijadwalkan dengan kubelet. Selama inisialisasi, plugin menanyakan NVIDIA Management Library (NVML) untuk menemukan GPU yang tersedia, kapasitas memorinya, kemampuan komputasi, dan topologi interkoneksi. Plugin mengiklankan GPU ke penjadwal Kubernetes menggunakan nama sumber daya nvidia.com/gpu, memungkinkan pod meminta GPU melalui spesifikasi sumber daya standar.

Alur Registrasi Device Plugin: 1. Plugin dimulai dan menemukan GPU lokal via NVML 2. Mendaftar dengan kubelet melalui Unix socket di /var/lib/kubelet/device-plugins/ 3. Mengiklankan GPU yang tersedia dengan ID perangkat unik 4. Mengimplementasikan RPC Allocate() untuk penugasan GPU container 5. Memantau kesehatan GPU dan melaporkan kegagalan ke kubelet 6. Menangani pembersihan GPU selama terminasi pod

Dukungan Multi-Instance GPU (MIG) memungkinkan partisi GPU A100 dan H100 menjadi instance terisolasi.⁵ Setiap instance MIG muncul sebagai GPU terpisah di Kubernetes, memungkinkan alokasi sumber daya yang lebih granular. Device plugin mengelola profil MIG, menangani pembuatan, penghapusan, dan penugasan instance. Organisasi mencapai utilisasi GPU 7x lebih baik dengan mempartisi GPU yang kurang dimanfaatkan untuk beban kerja yang lebih kecil. Konfigurasi MIG memerlukan perencanaan yang cermat karena mode partisi tidak dapat diubah tanpa mengosongkan node.

Device Plugin Alternatif menyediakan keragaman vendor: - AMD Device Plugin mendukung GPU berkemampuan ROCm seperti MI250X - Intel Device Plugin mengelola GPU Intel dan akselerator Gaudi - Xilinx FPGA Device Plugin mengorkestrasi sumber daya FPGA - Google TPU Device Plugin untuk kluster GKE

Strategi penjadwalan untuk beban kerja GPU

Penjadwalan GPU yang efektif memaksimalkan utilisasi sambil mempertahankan kinerja:

Gang Scheduling memastikan pekerjaan pelatihan terdistribusi menerima semua GPU yang diminta secara bersamaan. Tanpa gang scheduling, alokasi sumber daya parsial menyebabkan deadlock—pekerjaan menunggu selamanya untuk GPU tersisa yang tidak pernah tersedia. Plugin penjadwal Kubernetes seperti Volcano dan Apache YuniKorn mengimplementasikan gang scheduling melalui PodGroups.⁶ Pekerjaan menentukan kebutuhan GPU minimum, dan penjadwal mengalokasikan semua sumber daya atau mengantrekan seluruh pekerjaan. Gang scheduling mengurangi utilisasi kluster sebesar 10-15% tetapi mencegah kelaparan pekerjaan pelatihan.

Penjadwalan Sadar-Topologi mengoptimalkan penempatan GPU berdasarkan interkoneksi perangkat keras. GPU yang terhubung via NVLink mencapai bandwidth 600GB/s versus 32GB/s melalui PCIe.⁷ Penjadwal memeriksa topologi node untuk menempatkan pod terkait pada GPU dengan interkoneksi cepat. NVIDIA GPU Feature Discovery memberi label node dengan informasi topologi yang memungkinkan aturan affinity. Keputusan topologi yang buruk menyebabkan degradasi kinerja 3-8x untuk beban kerja yang intensif komunikasi. Kesadaran topologi menjadi kritis di atas 8 GPU per pekerjaan.

Bin Packing vs Spreading: Bin packing mengkonsolidasikan beban kerja pada node yang lebih sedikit, meningkatkan lokalitas cache dan mengurangi lalu lintas jaringan. Spreading mendistribusikan pekerjaan ke seluruh node untuk toleransi kesalahan yang lebih baik dan manajemen termal. Strategi optimal tergantung pada karakteristik beban kerja—pekerjaan pelatihan mendapat manfaat dari bin packing sementara inferensi mendukung spreading. Strategi dinamis menyesuaikan berdasarkan utilisasi kluster dan campuran beban kerja.

Prioritas dan Preemption: Beban kerja produksi menerima prioritas lebih tinggi daripada pekerjaan pengembangan. Penjadwal melakukan preempt pod prioritas lebih rendah ketika sumber daya menjadi langka. Konfigurasi prioritas yang cermat mencegah pekerjaan riset memblokir inferensi produksi. Checkpointing preemption memastikan kemajuan pelatihan tidak hilang. Kelas prioritas berkisar dari system-critical (1000000) hingga development (100).

Fair Sharing dan Kuota: Kuota sumber daya mencegah tim tunggal memonopoli GPU. Kuota hierarkis memungkinkan batasan di tingkat organisasi dengan sub-kuota spesifik tim. Penjadwalan fair share memastikan distribusi sumber daya yang adil dari waktu ke waktu. Pengguna yang mengonsumsi lebih sedikit sumber daya mengakumulasi kredit untuk kapasitas burst di masa depan. Sistem antrian seperti Kueue menyediakan job queueing dengan kontrol penerimaan yang canggih.

Pertimbangan penskalaan

Menskalakan Kubernetes ke ribuan GPU memerlukan modifikasi arsitektur:

Keterbatasan Ukuran Kluster: Kluster Kubernetes tunggal mendukung maksimum 5.000 node sebelum kinerja etcd menurun.⁸ Beban API server meningkat secara kuadratik dengan jumlah node karena mekanisme watch. Loop rekonsiliasi controller manager melambat di atas 1.000 node. Network policy menjadi tidak praktis dalam skala besar. Sebagian besar organisasi membatasi kluster hingga 500-1.000 node GPU untuk stabilitas operasional.

Federasi Multi-Kluster: Deployment besar menggunakan beberapa kluster Kubernetes yang dikelola melalui federasi. Admiralty atau Virtual Kubelet memungkinkan penjadwalan lintas kluster. Alat GitOps seperti Flux atau ArgoCD menyinkronkan konfigurasi di seluruh kluster. Teknologi service mesh menyediakan jaringan lintas kluster. Federasi menambah kompleksitas tetapi memungkinkan penskalaan horizontal melampaui batas kluster tunggal.

Manajemen Sumber Daya Hierarkis: Organisir kluster secara hierarkis dengan kluster manajemen yang mengontrol kluster beban kerja. Kluster manajemen menjalankan komponen control plane dan logika penjadwalan. Kluster beban kerja menampung pod GPU tanpa controller kompleks. Desain hierarkis mengurangi blast radius kegagalan. Pemisahan tanggung jawab yang jelas menyederhanakan troubleshooting.

Custom Resource Definitions (CRDs) untuk beban kerja AI: - TrainingJob: Mendefinisikan spesifikasi pelatihan terdistribusi - InferenceService: Mengelola deployment model serving - GPUPool: Merepresentasikan pengelompokan GPU logis - Checkpoint: Menangani persistensi state pelatihan - ModelVersion: Melacak iterasi model dan lineage

Optimisasi kinerja untuk skala: - Nonaktifkan admission webhook yang tidak digunakan untuk mengurangi latensi API - Implementasikan pod topology spread constraints untuk distribusi merata - Gunakan SSD lokal untuk image container menghindari bottleneck jaringan - Aktifkan CPU manager untuk alokasi CPU yang dijamin - Konfigurasi huge pages untuk kebutuhan memori model besar

Pemantauan dan observabilitas

Pemantauan komprehensif mencegah waktu idle GPU bernilai jutaan dolar:

NVIDIA Data Center GPU Manager (DCGM) menyediakan metrik spesifik GPU yang tidak tersedia melalui pemantauan Kubernetes standar.⁹ DCGM mengekspor 100+ metrik termasuk utilisasi SM, bandwidth memori, suhu, konsumsi daya, dan error ECC. Integrasi Prometheus memungkinkan penyimpanan metrik jangka panjang dan alerting. Dashboard Grafana memvisualisasikan kinerja GPU di seluruh armada. Alert kustom mendeteksi GPU yang kurang dimanfaatkan, throttling termal, dan degradasi perangkat keras sebelum kegagalan terjadi.

Metrik GPU Utama untuk pemantauan Kubernetes: - Utilisasi GPU: Persentase SM aktif (target >90%) - Utilisasi Memori: Memori GPU yang dialokasikan versus tersedia - Konsumsi Daya: Aktual versus TDP yang mengindikasikan throttling - Suhu: Suhu GPU dan memori - Bandwidth PCIe: Kecepatan transfer data ke/dari GPU - Lalu Lintas NVLink: Bandwidth komunikasi antar-GPU - Metrik Pelatihan: Kurva loss, norma gradien, learning rate - Metrik Inferensi: Request per detik, latensi P99, ukuran batch

Distributed Tracing melacak request di berbagai GPU dan node. Instrumentasi OpenTelemetry menangkap waktu langkah pelatihan, latensi pemuatan data, dan durasi checkpoint. Jaeger atau Tempo menyediakan penyimpanan dan analisis distributed trace. Korelasi antara trace dan metrik mengidentifikasi bottleneck kinerja. Visibilitas end-to-end mengurangi mean time to resolution sebesar 70%.

Agregasi Log memusatkan log dari ribuan pod GPU. Fluentd atau Fluent Bit mengumpulkan log container dengan overhead minimal. Elasticsearch menyimpan log dengan pengindeksan otomatis dan kebijakan retensi. Kibana memungkinkan pencarian dan analisis log di seluruh kluster. Structured logging dengan format konsisten menyederhanakan troubleshooting. Alert pada pola error yang mengindikasikan masalah sistemik.

Introl melakukan deployment dan mengelola kluster Kubernetes untuk orkestrasi GPU di seluruh area cakupan global kami, dengan keahlian menskalakan hingga deployment 10.000+ GPU.¹⁰ Tim platform engineering kami telah mengimplementasikan operator kustom dan peningkatan penjadwalan untuk utilisasi GPU yang optimal.

Pola deployment produksi

Arsitektur Kluster Pelatihan di Anthropic: - Skala: 4.000 GPU di 8 kluster Kubernetes - Topologi: Federasi hierarkis dengan penjadwal pusat - Penyimpanan: Filesystem Lustre terdistribusi untuk data pelatihan - Jaringan: Fabric RoCE v2 dengan 200Gbps per node - Penjadwalan: Gang scheduler kustom dengan kesadaran topologi - Pemantauan: DCGM + Prometheus dengan interval scrape 15 detik - Hasil: Utilisasi GPU 94%, pengurangan waktu pelatihan 50%

Platform Inferensi di Uber: - Beban Kerja: 500 juta prediksi setiap hari - Infrastruktur: 2.000 GPU T4 di 20 region - Orkestrasi: Kubernetes dengan Knative untuk serverless - Autoscaling: Penskalaan prediktif berdasarkan pola lalu lintas - Load Balancing: Envoy proxy dengan routing least-latency - Optimisasi: Model caching mengurangi cold start hingga 2 detik - Hasil: Pengurangan biaya 65% versus arsitektur sebelumnya

Hybrid Training-Inference di Spotify: - GPU: Armada campuran 3.000 V100/A100/T4 - Penjadwalan: Time-sliced sharing untuk pengembangan - Isolasi: Kata containers untuk keamanan multi-tenant - Cos

[Konten dipotong untuk terjemahan]