Kubernetes untuk Orkestrasi GPU: Mengelola Kluster GPU Multi-Ribu

Diperbarui 8 Desember 2025

Pembaruan Desember 2025: Kubernetes 1.31+ Dynamic Resource Allocation (DRA) kini GA, memungkinkan partisi GPU yang presisi dan time-slicing. NVIDIA GPU Operator 24.6+ menambahkan dukungan Blackwell dan manajemen MIG yang ditingkatkan. Kueue (job queueing native Kubernetes) mencapai kematangan produksi untuk beban kerja AI. Run:ai dan CoreWeave mendemonstrasikan kluster 50,000+ GPU pada Kubernetes. Tools federasi multi-kluster (Liqo, Admiralty) memungkinkan orkestrasi GPU lintas cloud. Dukungan vGPU berkembang untuk deployment inference multi-tenant.

OpenAI mengorkestrasi 25,000 GPU di beberapa 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 hardware terjadi setiap 2,5 jam rata-rata.¹ Tim infrastruktur perusahaan menemukan bahwa Kubernetes vanilla runtuh sekitar 5,000 node tanpa modifikasi ekstensif, memaksa mereka mengimplementasikan federasi kluster hierarkis, algoritma scheduling kustom, dan autoscaling GPU-aware 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 training terdistribusi dapat menghabiskan jutaan waktu komputasi, sedangkan scheduling yang buruk yang memisahkan GPU yang terhubung via NVLink menyebabkan degradasi performa 8x. Organisasi yang berhasil mengorkestrasi ribuan GPU pada 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, yang 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 pada Kubernetes harus menavigasi konfigurasi device plugin, aturan node affinity, scheduling topology-aware, dan kuota sumber daya yang mencegah tim tunggal memonopoli sumber daya GPU. Namun mereka yang menguasai Kubernetes untuk orkestrasi GPU memperoleh kemampuan untuk memperlakukan ribuan GPU sebagai pool sumber daya yang dapat diprogram tunggal, mencapai tingkat utilisasi dan efisiensi operasional yang tidak mungkin dengan scheduler HPC tradisional.

Arsitektur device plugin GPU

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

NVIDIA GPU Device Plugin berfungsi sebagai antarmuka utama antara Kubernetes dan GPU NVIDIA.⁴ Plugin berjalan sebagai DaemonSet pada 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 memori mereka, kemampuan komputasi, dan topologi interkoneksi. Plugin mengiklankan GPU ke scheduler Kubernetes menggunakan nama sumber daya nvidia.com/gpu, memungkinkan pod meminta GPU melalui spesifikasi sumber daya standar.

Alur Registrasi Device Plugin: 1. Plugin mulai 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 yang terisolasi.⁵ Setiap instance MIG muncul sebagai GPU terpisah ke Kubernetes, memungkinkan alokasi sumber daya yang presisi. 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 hati-hati karena mode partisi tidak dapat berubah tanpa menguras node.

Device Plugin Alternatif menyediakan keragaman vendor: - AMD Device Plugin mendukung GPU yang diaktifkan 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 scheduling untuk beban kerja GPU

Scheduling GPU yang efektif memaksimalkan utilisasi sambil mempertahankan performa:

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

Topology-Aware Scheduling mengoptimalkan penempatan GPU berdasarkan interkoneksi hardware. GPU yang terhubung via NVLink mencapai bandwidth 600GB/s versus 32GB/s melalui PCIe.⁷ Scheduler memeriksa topologi node untuk menempatkan pod terkait pada GPU dengan interkoneksi cepat. NVIDIA GPU Feature Discovery melabeli node dengan informasi topologi yang memungkinkan aturan affinity. Keputusan topologi yang buruk menyebabkan degradasi performa 3-8x untuk beban kerja yang berat komunikasi. Kesadaran topologi menjadi kritis di atas 8 GPU per job.

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

Priority dan Preemption: Beban kerja produksi menerima prioritas lebih tinggi dari job pengembangan. Scheduler melakukan preempt pod prioritas rendah ketika sumber daya menjadi langka. Konfigurasi prioritas yang hati-hati mencegah job riset memblokir inference produksi. Checkpointing preemption memastikan kemajuan training 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 batas organisasi dengan sub-kuota spesifik tim. Scheduling fair share memastikan distribusi sumber daya yang adil dari waktu ke waktu. Pengguna yang mengonsumsi sumber daya lebih sedikit mengakumulasi kredit untuk kapasitas burst masa depan. Sistem antrian seperti Kueue menyediakan job queueing dengan kontrol admisi yang canggih.

Pertimbangan scaling

Scaling Kubernetes ke ribuan GPU memerlukan modifikasi arsitektur:

Keterbatasan Ukuran Kluster: Kluster Kubernetes tunggal mendukung maksimal 5,000 node sebelum performa etcd menurun.⁸ Beban API server meningkat secara kuadrat dengan jumlah node karena mekanisme watch. Loop rekonsiliasi controller manager melambat di atas 1,000 node. Kebijakan jaringan menjadi tidak dapat dikelola dalam skala besar. Sebagian besar organisasi membatasi kluster ke 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 scheduling lintas kluster. Tools GitOps seperti Flux atau ArgoCD menyinkronkan konfigurasi di seluruh kluster. Teknologi service mesh menyediakan jaringan lintas kluster. Federasi menambah kompleksitas tetapi memungkinkan scaling horizontal di luar batas kluster tunggal.

Manajemen Sumber Daya Hierarkis: Atur kluster secara hierarkis dengan kluster manajemen yang mengontrol kluster beban kerja. Kluster manajemen menjalankan komponen control plane dan logika scheduling. Kluster beban kerja meng-host pod GPU tanpa controller kompleks. Desain hierarkis mengurangi radius ledakan kegagalan. Pemisahan masalah yang jelas menyederhanakan troubleshooting.

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

Optimasi performa untuk skala: - Nonaktifkan admission webhook yang tidak digunakan 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 terjamin - Konfigurasikan huge pages untuk persyaratan memori model besar

Monitoring dan observability

Monitoring komprehensif mencegah waktu idle GPU senilai jutaan dolar:

NVIDIA Data Center GPU Manager (DCGM) menyediakan metrik spesifik GPU yang tidak tersedia melalui monitoring 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 performa GPU di seluruh fleet. Alert kustom mendeteksi GPU yang kurang dimanfaatkan, thermal throttling, dan degradasi hardware sebelum kegagalan terjadi.

Metrik GPU Kunci untuk monitoring Kubernetes: - Utilisasi GPU: Persentase SM aktif (target >90%) - Utilisasi Memori: Memori GPU yang dialokasikan versus tersedia - Konsumsi Daya: Aktual versus TDP menunjukkan throttling - Suhu: Suhu GPU dan memori - Bandwidth PCIe: Tingkat transfer data ke/dari GPU - Traffic NVLink: Bandwidth komunikasi antar GPU - Metrik Training: Kurva loss, norma gradien, learning rates - Metrik Inference: Request per detik, latensi P99, ukuran batch

Distributed Tracing melacak request di beberapa GPU dan node. Instrumentasi OpenTelemetry menangkap waktu step training, latensi loading data, dan durasi checkpoint. Jaeger atau Tempo menyediakan penyimpanan dan analisis trace terdistribusi. Korelasi antara trace dan metrik mengidentifikasi bottleneck performa. 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 kebijakan indexing dan retensi otomatis. Kibana memungkinkan pencarian dan analisis log di seluruh kluster. Structured logging dengan format konsisten menyederhanakan troubleshooting. Alert pada pola error yang menunjukkan masalah sistemik.

Introl melakukan deploy dan mengelola kluster Kubernetes untuk orkestrasi GPU di seluruh area cakupan global kami, dengan keahlian scaling hingga 10,000+ deployment GPU.¹⁰ Tim platform engineering kami telah mengimplementasikan operator kustom dan peningkatan scheduling untuk utilisasi GPU optimal.

Pola deployment produksi

Arsitektur Kluster Training di Anthropic: - Skala: 4,000 GPU di 8 kluster Kubernetes - Topologi: Federasi hierarkis dengan scheduler sentral - Storage: Filesystem Lustre terdistribusi untuk data training - Networking: Fabric RoCE v2 dengan 200Gbps per node - Scheduling: Gang scheduler kustom dengan kesadaran topologi - Monitoring: DCGM + Prometheus dengan interval scrape 15 detik - Hasil: Utilisasi GPU 94%, pengurangan waktu training 50%

Platform Inference di Uber: - Beban Kerja: 500 juta prediksi harian - Infrastruktur: 2,000 GPU T4 di 20 region - Orkestrasi: Kubernetes dengan Knative untuk serverless - Autoscaling: Scaling prediktif berdasarkan pola traffic - Load Balancing: Proxy Envoy dengan routing latensi terendah - Optimasi: Caching model mengurangi cold start ke 2 detik - Hasil: Pengurangan biaya 65% versus arsitektur sebelumnya

Hybrid Training-Inference di Spotify: - GPU: Fleet campuran 3,000 V100/A100/T4 - Scheduling: Sharing time-sliced untuk pengembangan - Isolasi: Container Kata untuk keamanan multi-tenant - Cos