Belajar MLOps - Kubernetes untuk ML

#Pendahuluan

Setelah di episode 16 kalian melihat managed cloud platform, sekarang sisi lainnya: Kubernetes — pilihan bagi tim yang butuh kontrol penuh, portabilitas lintas cloud dan on-premise, serta skala inference yang sulit dibatasi fitur vendor.

Mengapa K8s penting untuk ML? Karena K8s sudah menjadi lingua franca deployment modern: ia menangani penjadwalan GPU, replikasi, health check, dan autoscaling secara native. Ketika model harus melayani ribuan request per detik dengan beberapa versi sekaligus, atau training butuh puluhan GPU, K8s adalah fondasi yang paling umum dipakai industri. Episode ini membahas GPU scheduling, serving, dan autoscaling — lalu memperkenalkan KServe dan Seldon.

#Kenapa Kubernetes untuk ML

• Portabilitas — cluster yang sama bisa jalan di AWS, GCP, on-premise, atau bare metal.
• GPU scheduling — GPU diperlakukan sebagai resource yang bisa dijadwalkan seperti CPU dan memory.
• Autoscaling native — HPA menambah/mengurangi replica dari metrik usage.
• Ekosistem — KServe, Seldon, Kubeflow, dan MLflow built di atasnya.

#GPU Scheduling

GPU bukan CPU: ia resource khusus yang hanya tersedia di node tertentu. K8s mengetahuinya lewat device plugin (misal NVIDIA device plugin), yang mendaftarkan GPU sebagai resource bernama nvidia.com/gpu.

apiVersion: v1
kind: Pod
metadata:
  name: trainer
spec:
  restartPolicy: Never
  nodeSelector:
    nvidia.com/gpu.present: "true"
  containers:
    - name: train
      image: registry.example/ml/train:2.4.0
      resources:
        limits:
          nvidia.com/gpu: "1"

Aturan penting:

• requests dan limits untuk GPU harus sama — GPU tidak bisa dibagi.
• Gunakan nodeSelector atau toleransi taint untuk memastikan pod GPU hanya diletakkan di node ber-GPU.
• Jangan meminta GPU untuk servis yang tidak membutuhkannya — itu membuang resource cluster.

#Serving Model di K8s

Pola paling dasar: Deployment + Service. Deployment menjamin replika model hidup; Service menjadi pintu masuk traffic yang stabil.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: churn-svc
spec:
  replicas: 3
  selector:
    matchLabels:
      app: churn-svc
  template:
    metadata:
      labels:
        app: churn-svc
    spec:
      containers:
        - name: model
          image: registry.example/ml/churn-server:2.4.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              cpu: "1"
              memory: 2Gi
          readinessProbe:
            httpGet:
              path: /health
              port: 8080

readinessProbe itu bukan formalitas: tanpa probe, pod yang masih memuat model ke memory ikut menerima traffic — dan request pertama kalian akan timeout.

#HPA untuk Inference

HorizontalPodAutoscaler menambah replica berdasarkan metrik. Untuk inference, metrik CPU berguna, tetapi sering terlambat menanggapi lonjakan request. Kombinasi CPU + custom metrics (request per second) lebih baik.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: churn-svc-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: churn-svc
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

HPA tradisional menambah replica dalam hitungan menit. Untuk inference yang tiba-tiba padat, KEDA bisa men-skalakan dari sumber event langsung — antrean Kafka, queue, atau metrik HTTP.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: churn-consumer
spec:
  scaleTargetRef:
    name: churn-consumer
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
    - type: kafka
      metadata:
        topic: predictions
        bootstrapServers: kafka-cluster:9092
        lagThreshold: "50"

#Serving Frameworks: KServe & Seldon

Menulis Deployment manual untuk satu model itu mudah; mengelola ratusan versi model dengan canary, auto-scaling ke nol, dan monitoring per-model adalah masalah yang berbeda. Di sinilah framework serving berperan.

KServe mendeklarasikan model sebagai resource InferenceService:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: churn-predictor
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://mlops-bucket/churn/v2/

KServe menangani: memuat model dari storage, menyiapkan server inference (dengan server-agnostic protocol), auto-scaling berbasis Knative (termasuk scale-to-zero), dan traffic splitting antar revisi. Seldon Core adalah alternatif populer dengan SLO monitoring dan explainability yang terintegrasi.

#Common Pitfalls

• GPU requests dan limits berbeda — pod tidak pernah ter-schedule; keduanya harus sama.
• Tanpa readiness probe — model masih loading, traffic sudah masuk, request pertama gagal.
• HPA hanya CPU untuk inference burst — terlalu lambat; kombinasikan dengan custom metrics atau KEDA.
• GPU idle menunggu request — inference GPU harus dibarengi batching dan scale-down agar hemat (episode 22).
• Langsung KServe tanpa paham K8s dasar — debugging dan tuning jadi jauh lebih sulit.

#Penutup

Pada episode 17 ini, kalian telah menjalankan model di Kubernetes.

Inti yang harus dibawa pulang:

• GPU scheduling via device plugin: nvidia.com/gpu dengan requests = limits.
• Serving dasar = Deployment + Service + readinessProbe.
• HPA untuk CPU; KEDA untuk event-driven scaling (Kafka, queue).
• KServe dan Seldon untuk serving framework produksi: canary, scale-to-zero, monitoring.
• K8s adalah pilihan kalian saat butuh portabilitas dan kontrol penuh atas skala.

Di episode 18 selanjutnya kita akan membahas security ML — data poisoning, adversarial attacks, dan prompt injection — karena model yang kuat sekalipun bisa dikalahkan oleh serangan yang menargetkan kelemahannya. Sampai jumpa di episode 18!