Belajar Kata Containers - GPU & Device Passthrough

#Pendahuluan

Sampai episode 9, semua workload kita hanya memakai CPU dan memori virtual. Episode 10 membuka pintu yang berbeda: perangkat fisik — terutama GPU. Workload AI/ML adalah alasan utama banyak tim mulai mempertimbangkan isolasi microVM: mereka ingin menjalankan model dan agent yang mengeksekusi input tidak dikenal, tapi tetap butuh akses GPU untuk inferensi.

Kata Containers menjawab kebutuhan ini lewat VFIO passthrough: GPU dilepaskan dari host dan diberikan langsung ke microVM. Episode ini membahas cara kerja passthrough, peran NRI untuk pengelolaan device di Kubernetes, serta bagaimana KEDA dan resource limits bekerja di lingkungan microVM.

#VFIO Passthrough untuk AI/ML

#Mengapa Passthrough Bukan Virtual Device

GPU virtual (vGPU) punya kompatibilitas terbatas dan overhead. Untuk AI/ML production, tim lebih memilih passthrough penuh: GPU fisik terlihat di guest sebagai perangkat nyata. Aplikasi di guest memakai CUDA/ROCm langsung, seolah-olah berjalan di bare-metal.

Prinsip VFIO (dari episode 8): perangkat dibind ke driver vfio-pci di host, lalu diattach ke microVM. Guest melihat GPU sebagai PCI device dengan resource penuh — memory GPU, compute unit, semuanya.

#Prasyarat Passthrough

Passthrough menuntut dukungan IOMMU. Tanpa IOMMU, perangkat tidak bisa diisolasi untuk passthrough dengan aman. Persiapkan host:

Aktifkan IOMMU di host

# Di kernel boot params (GRUB): intel_iommu=on (Intel) / amd_iommu=on (AMD)
cat /proc/cmdline | grep iommu
ls /sys/kernel/iommu_groups/

cat /proc/cmdline | grep iommu memverifikasi IOMMU aktif pada kernel yang berjalan. ls /sys/kernel/iommu_groups/ menampilkan group IOMMU — perangkat dalam group yang sama tidak bisa dipasang-pasang secara terpisah.

Setelah IOMMU aktif, bind perangkat ke vfio-pci:

Bind GPU ke vfio-pci

lspci -nn | grep -i nvidia
echo "10de 2684" > /sys/bus/pci/drivers/vfio-pci/new_id

lspci -nn | grep -i nvidia mencari vendor/device ID GPU. ID tersebut didaftarkan ke vfio-pci agar perangkat bisa di-passthrough.

#Menyediakan GPU ke Pod Kata

Kubernetes menyediakan GPU lewat device plugin yang membuat extended resource (misalnya nvidia.com/gpu). Pod yang meminta resource tersebut dijadwalkan ke node dengan GPU. Untuk Kata, GPU dialokasikan ke microVM via VFIO. Contoh pod:

apiVersion: v1
kind: Pod
metadata:
  name: kata-gpu
spec:
  runtimeClassName: kata
  containers:
    - name: ml
      image: nvidia/cuda:12.2-base
      command: ["nvidia-smi"]
      resources:
        limits:
          nvidia.com/gpu: 1

nvidia.com/gpu: 1 meminta satu GPU. Setelah pod berjalan, nvidia-smi di dalam guest harus menampilkan GPU — bukti passthrough berhasil.

#NRI: Node Resource Interface

NRI (Node Resource Interface) adalah standar yang menghubungkan container runtime dengan device plugin dan komponen lain di node. Dengan NRI, plugin (misalnya plugin GPU) bisa berinteraksi dengan lifecycle container lewat callback — tanpa memodifikasi runtime.

Bagi Kata, NRI berarti device plugin tidak perlu memahami detail microVM. Plugin memberi tahu runtime "container ini butuh GPU ini", dan lapisan Kata menerjemahkannya ke konfigurasi VFIO untuk microVM. Ini menyederhanakan integrasi perangkat di lingkungan Kata.

Untuk mengaktifkan NRI di containerd, tambahkan ke /etc/containerd/config.toml:

/etc/containerd/config.toml

version = 2
 
[plugins."io.containerd.grpc.v1.cri"]
  enable_nri = true
  enable_unprivileged_ports = false
 
[plugins."io.containerd.nri.v1.nri"]
  disable = false
  socket_path = "/var/run/nri/nri.sock"

enable_nri = true mengaktifkan integrasi NRI. Dengan NRI aktif, plugin device bekerja mulus dengan pod Kata.

#Resource Limits yang Diterapkan di VM

Dari episode 5 kita tahu bahwa limit pod diterjemahkan ke alokasi microVM. Dalam konteks GPU dan workload besar, ini berarti:

• CPU dan memori dialokasikan untuk seluruh VM — proses di guest bersaing dalam batas VM, bukan batas cgroup host.
• GPU dialokasikan via passthrough — satu GPU untuk satu pod (atau dibagi sesuai mode MIG/SR-IOV pada dukungan VMM).
• Oversubscription tidak disarankan: karena VM menahan resource secara fisik, jangan menjadwalkan lebih banyak pod Kata daripada kapasitas node.

Perhatikan perbedaan filosofi ini: di container biasa, cgroup menekan proses saat melebihi limit. Di Kata, limit menentukan ukuran VM. Ini lebih tegas tapi kurang fleksibel — itulah harga isolasi.

#Integrasi Autoscaling KEDA

KEDA (Kubernetes Event-Driven Autoscaling) adalah tool autoscaling berbasis event. Bagaimana ia berinteraksi dengan Kata? Karena pod Kata terlihat seperti pod biasa di Kubernetes, KEDA bekerja tanpa perubahan — ia menskalakan Deployment berdasarkan metrik, dan pod baru lahir sebagai microVM baru.

Yang perlu diperhatikan adalah waktu boot: karena setiap pod baru menunggu microVM boot, scale-up Kata sedikit lebih lambat daripada runc. Untuk workload yang butuh scale cepat, pertimbangkan:

• Menjaga jumlah pod minimum (KEDA minReplicaCount) agar microVM sudah hangat.
• Mengukur latency boot di environment kalian (episode 20).
• Menggunakan backend VMM yang boot-nya cepat (episode 6).

Contoh trigger KEDA yang sederhana:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kata-http-scaler
spec:
  scaleTargetRef:
    name: kata-app
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        metricName: http_requests_total
        threshold: "100"

maxReplicaCount: 10 membatasi skala maksimal. Karena setiap replica adalah microVM, pikirkan kapasitas node: sepuluh replica berarti sepuluh microVM yang masing-masing menahan resource-nya sendiri.

#Common Pitfalls

• Lupa IOMMU: passthrough gagal total tanpa IOMMU aktif.
• VFIO bind yang tidak persisten: bind vfio-pci hilang setelah reboot — gunakan udev rule atau modprobe config.
• GPU di node tanpa device plugin: pod minta GPU tapi resource tidak ada — pastikan device plugin berjalan.
• Overcommit memori: menjadwalkan terlalu banyak pod Kata membuat node kekurangan memori karena setiap VM menahan alokasinya.

#Penutup

Inti yang harus dibawa pulang:

• VFIO passthrough memberikan GPU fisik ke microVM untuk workload AI/ML.
• IOMMU adalah prasyarat wajib untuk passthrough.
• NRI menghubungkan device plugin dengan runtime tanpa modifikasi runtime.
• Resource limits menentukan ukuran VM, bukan sekadar batas cgroup.
• KEDA bekerja dengan pod Kata tanpa perubahan; perhitungkan boot time saat scale-up.
• nvidia-smi di dalam guest membuktikan GPU passthrough berhasil.

Di episode 11 selanjutnya kita akan membahas Confidential Containers (CoCo) — enkripsi workload dengan TDX/SEV/SEV-SNP lewat runtimeclass kata-qemu-coco-dev, proses attestation dan measurement, serta kasus penggunaan dan keterbatasannya.