Praktik terbaik GPU untuk Azure Kubernetes Service (AKS)

Menjalankan beban kerja GPU pada kluster AKS memerlukan penyiapan yang tepat dan validasi berkelanjutan untuk memastikan bahwa sumber daya komputasi dapat diakses, aman, dan digunakan secara optimal. Artikel ini menguraikan praktik terbaik untuk mengelola simpul berkemampuan GPU, memvalidasi konfigurasi, dan mengurangi gangguan beban kerja menggunakan perintah diagnostik khusus vendor.

Beban kerja GPU, seperti pelatihan model AI, inferensi real time, simulasi, dan pemrosesan video, sering bergantung pada konfigurasi berikut:

  • Memperbaiki driver GPU dan kompatibilitas runtime.
  • Penjadwalan sumber daya GPU yang akurat.
  • Akses ke perangkat keras GPU di dalam kontainer.

Kesalahan konfigurasi dapat menyebabkan biaya tinggi, kegagalan pekerjaan yang tidak terduga, atau kurangnya penggunaan GPU.

Menerapkan penempatan beban kerja GPU

Secara default, penjadwal AKS menempatkan pod pada simpul yang tersedia dengan CPU dan memori yang memadai. Tanpa panduan, ini dapat menyebabkan dua masalah utama:

  1. Beban kerja GPU dapat dijadwalkan pada simpul tanpa GPU dan gagal dimulai, atau
  2. Beban kerja tujuan umum dapat menempati simpul GPU, membuang-buang sumber daya yang mahal.

Untuk menerapkan penempatan yang benar:

  • Taint node GPU Anda menggunakan kunci seperti [gpu-vendor].com/gpu: NoSchedule (misalnya, nvidia.com/gpu: NoSchedule). Ini memblokir beban kerja non-GPU agar tidak dijadwalkan di sana.
  • Tambahkan toleransi yang cocok dalam spesifikasi pod beban kerja GPU Anda sehingga dapat dijadwalkan pada simpul GPU yang ternoda.
  • Tentukan permintaan dan batasan sumber daya GPU di pod Anda, untuk memastikan penjadwal mencadangkan kapasitas GPU, seperti:
resources:
  limits:
    [gpu-vendor].com/gpu: 1
  • Gunakan kebijakan validasi atau pengontrol penerimaan untuk menegakkan bahwa beban kerja GPU mencakup toleransi dan batas sumber daya yang diperlukan.

Pendekatan ini menjamin bahwa hanya beban kerja siap GPU yang mendarat di simpul GPU dan memiliki akses ke sumber daya komputasi khusus yang mereka butuhkan.

Sebelum menyebarkan beban kerja GPU produksi, selalu validasi bahwa kumpulan simpul GPU Anda adalah:

  • Dilengkapi dengan driver GPU yang kompatibel.
  • Hosting DaemonSet Plugin Perangkat Kubernetes yang sehat.
  • [gpu-vendor].com/gpu Mengekspos sebagai sumber daya yang dapat di-schedulable.

Anda dapat mengonfirmasi versi driver saat ini yang berjalan pada kumpulan simpul GPU Anda dengan antarmuka manajemen sistem (SMI) yang terkait dengan vendor GPU.

Perintah berikut dijalankan nvidia-smi dari dalam pod penyebaran plugin perangkat GPU Anda, untuk memverifikasi penginstalan driver dan kesiapan runtime pada kumpulan simpul berkemampuan GPU NVIDIA:

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

Output Anda harus menyerupai contoh output berikut:

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

Ulangi langkah di atas untuk setiap kumpulan simpul GPU untuk mengonfirmasi versi driver yang diinstal pada simpul Anda.

Pada kumpulan simpul yang mendukung GPU AMD Anda, sebarkan komponen GPU AMD dan jalankan amd-smi perintah di pod plugin perangkat ROCm untuk mengonfirmasi versi driver yang diinstal.

Menjaga simpul yang diaktifkan GPU diperbarui ke gambar OS simpul terbaru

Untuk memastikan performa, keamanan, dan kompatibilitas beban kerja GPU Anda di AKS, penting untuk selalu memperbarui kumpulan simpul GPU Anda dengan gambar OS simpul terbaru yang direkomendasikan. Pembaruan ini sangat penting karena:

  • Sertakan driver GPU tingkat produksi terbaru, menggantikan versi yang tidak digunakan lagi atau berakhir masa pakai (EOL).
  • Sepenuhnya diuji untuk kompatibilitas dengan versi Kubernetes Anda saat ini.
  • Mengatasi kerentanan yang diketahui yang diidentifikasi oleh vendor GPU.
  • Menggabungkan os terbaru dan peningkatan runtime kontainer untuk meningkatkan stabilitas dan efisiensi.

Tingkatkan kumpulan simpul GPU Anda ke gambar OS simpul terbaru yang direkomendasikan yang dirilis oleh AKS, baik dengan mengatur saluran autoupgrade atau melalui peningkatan manual. Anda dapat memantau dan melacak rilis gambar simpul terbaru menggunakan pelacak rilis AKS.

Pisahkan beban kerja GPU saat menggunakan kluster bersama

Jika satu kluster AKS dengan kumpulan simpul GPU menjalankan beberapa jenis beban kerja GPU, seperti pelatihan model, inferensi real time, atau pemrosesan batch, penting untuk memisahkan beban kerja ini untuk:

  • Hindari gangguan yang tidak disengaja atau ketidakcocokan sumber daya antara berbagai jenis beban kerja.
  • Meningkatkan keamanan dan mempertahankan batas kepatuhan.
  • Menyederhanakan manajemen dan pemantauan penggunaan sumber daya GPU per kategori beban kerja.

Anda dapat mengisolasi beban kerja GPU dalam satu kluster AKS dengan menggunakan namespace layanan dan kebijakan jaringan. Ini memungkinkan tata kelola yang lebih jelas melalui kuota, batas, dan konfigurasi pengelogan khusus beban kerja.

Contoh skenario

Pertimbangkan kluster AKS yang menghosting dua jenis beban kerja GPU berbeda yang tidak perlu berkomunikasi satu sama lain:

  • Beban Kerja Pelatihan: Pekerjaan pelatihan model AI intensif sumber daya.
  • Beban Kerja Inferensi: Layanan inferensi real-time yang sensitif terhadap latensi.

Anda dapat menggunakan langkah-langkah berikut untuk memisahkan dua beban kerja:

  1. Buat namespace khusus per jenis beban kerja menggunakan kubectl create namespace perintah .

    kubectl create namespace gpu-training
kubectl create namespace gpu-inference

  2. Beri label pod beban kerja GPU berdasarkan jenis, seperti yang ditunjukkan dalam contoh berikut:

    metadata:
  namespace: gpu-training
  labels:
    workload: training

  3. Terapkan kebijakan jaringan untuk mengisolasi lalu lintas antar jenis beban kerja. Manifes berikut memblokir semua ingress dan egress untuk gpu-training namespace (kecuali diizinkan secara eksplisit):

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: gpu-training
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []

Kebijakan ini:

  • Berlaku untuk semua pod di gpu-training namespace layanan.
  • Menolak semua lalu lintas masuk dan keluar secara default, mendukung isolasi yang kuat.

Model ini meningkatkan kejelasan, kontrol, dan keamanan di lingkungan GPU bersama, terutama ketika jenis beban kerja memiliki profil runtime, tingkat risiko, atau persyaratan operasional yang berbeda.

Mengoptimalkan penggunaan sumber daya pada simpul GPU menggunakan GPU multi-instans (MIG)

Beban kerja GPU yang berbeda berkisar dalam persyaratan memori, dan penyebaran yang lebih kecil (misalnya NVIDIA A100 40GB) mungkin tidak memerlukan seluruh GPU. Namun, satu beban kerja secara default memonopoli sumber daya GPU bahkan ketika kurang digunakan.

AKS mendukung pengoptimalan sumber daya pada simpul GPU dengan membaginya menjadi irisan yang lebih kecil menggunakan GPU multi-instans (MIG), sehingga tim dapat menjadwalkan pekerjaan yang lebih kecil dengan lebih efisien. Pelajari selengkapnya tentang ukuran GPU yang didukung dan cara memulai GPU multi-instans di AKS.

Menggunakan disk data NVMe Sementara sebagai cache berkinerja tinggi

Untuk beban kerja AI yang berjalan pada VM GPU di AKS, akses cepat dan andal ke penyimpanan sementara sangat penting untuk memaksimalkan pelatihan dan performa inferensi. Disk data NVMe sementara menyediakan throughput tinggi dan penyimpanan berlatensi rendah yang terhubung langsung ke host VM, membuatnya ideal untuk skenario seperti caching himpunan data, menyimpan checkpoint sementara dan bobot model, atau menyediakan ruang sementara untuk pra-pemrosesan data dan analitik.

Saat menyebarkan node pool berkemampuan GPU untuk beban kerja AI, konfigurasikan disk data NVMe sementara untuk berfungsi sebagai cache berkinerja tinggi atau ruang sementara. Pendekatan ini membantu menghilangkan hambatan I/O, mempercepat operasi intensif data, dan memastikan bahwa sumber daya GPU Anda tidak menganggur saat menunggu data.

Disk data NVMe Ephemeral didukung di berbagai keluarga VM GPU Azure. Tergantung pada ukuran VM GPU, ia memiliki hingga 8 disk data NVMe ephemeral dengan kapasitas gabungan hingga 28 TiB. Untuk konfigurasi terperinci tentang ukuran VM, lihat dokumentasi seri ND H100 v5 atau dokumentasi ukuran VM untuk keluarga GPU yang Anda pilih.

Untuk menyederhanakan provisi dan manajemen, gunakan Azure Container Storage, yang dapat secara otomatis mendeteksi dan mengatur disk NVMe sementara untuk beban kerja Kubernetes Anda.

Skenario yang direkomendasikan meliputi:

  • Pencaching himpunan data besar dan model checkpoint untuk pelatihan dan inferensi AI.
  • Penyimpanan sementara bobot model untuk inferensi AI. Misalnya, model hosting KAITO sebagai artefak OCI pada NVMe lokal.
  • Menyediakan ruang disk sementara yang cepat untuk tugas batch dan aliran data.

Penting

Data pada disk NVMe sementara dan akan hilang jika VM dibatalkan alokasinya atau disebarkan ulang. Gunakan disk ini hanya untuk data non-kritis, sementara, dan simpan informasi penting tentang solusi penyimpanan Azure yang persisten.

Untuk panduan selengkapnya tentang disk data NVMe ephemeral, lihat Praktik terbaik untuk disk data NVMe ephemeral di AKS.

Langkah selanjutnya

Untuk mempelajari selengkapnya tentang penyebaran dan manajemen beban kerja GPU di AKS, lihat artikel berikut ini:

  • Last updated on