Kubernetes ile AI Model Dağıtımı

📑 İçindekiler

• 1. Giriş: Neden Kubernetes ile AI Model Dağıtımı?
• 2. AI Modellerinin Containerize Edilmesi
• 3. Model Serving Frameworkleri
• 3.1 TensorFlow Serving
• 3.2 TorchServe
• 3.3 NVIDIA Triton Inference Server
• 4. GPU Scheduling ve Kaynak Yönetimi
• 5. Auto-Scaling Stratejileri
• 6. Helm Charts ile Deployment Yönetimi
• 7. Monitoring ve Observability
• 8. CI/CD Pipeline Entegrasyonu
• 9. Best Practices ve Güvenlik
• 10. Sonuç
• 11. Sıkça Sorulan Sorular (FAQ)

💡 Bilgi

2026 itibarıyla, Fortune 500 şirketlerinin %85'inden fazlası production ML workload'larını Kubernetes üzerinde çalıştırmaktadır. Bu oran her geçen yıl artmaya devam etmektedir.

# Multi-stage Dockerfile for AI Model
FROM python:3.11-slim AS builder

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM nvidia/cuda:12.3-runtime-ubuntu22.04 AS runtime

COPY --from=builder /install /usr/local
COPY model/ /app/model/
COPY src/ /app/src/

WORKDIR /app
EXPOSE 8080

# Health check endpoint
HEALTHCHECK --interval=30s --timeout=5s \
  CMD curl -f http://localhost:8080/health || exit 1

CMD ["python", "src/serve.py", "--port", "8080"]

# Init container ile model indirme
apiVersion: v1
kind: Pod
metadata:
  name: ai-model-server
spec:
  initContainers:
  - name: model-downloader
    image: amazon/aws-cli:latest
    command: ["aws", "s3", "cp", "s3://models/v2.1/model.onnx", "/models/"]
    volumeMounts:
    - name: model-volume
      mountPath: /models
  containers:
  - name: inference-server
    image: my-inference:latest
    volumeMounts:
    - name: model-volume
      mountPath: /models
  volumes:
  - name: model-volume
    emptyDir: {}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tf-serving
  labels:
    app: tf-serving
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tf-serving
  template:
    metadata:
      labels:
        app: tf-serving
    spec:
      containers:
      - name: tf-serving
        image: tensorflow/serving:latest-gpu
        ports:
        - containerPort: 8500  # gRPC
        - containerPort: 8501  # REST
        args:
        - "--model_config_file=/config/models.config"
        - "--monitoring_config_file=/config/monitoring.config"
        resources:
          limits:
            nvidia.com/gpu: 1
            memory: "8Gi"
          requests:
            memory: "4Gi"
        volumeMounts:
        - name: model-config
          mountPath: /config
      volumes:
      - name: model-config
        configMap:
          name: tf-serving-config

# TorchServe Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: torchserve
spec:
  replicas: 2
  selector:
    matchLabels:
      app: torchserve
  template:
    spec:
      containers:
      - name: torchserve
        image: pytorch/torchserve:latest-gpu
        ports:
        - containerPort: 8080  # Inference
        - containerPort: 8081  # Management
        - containerPort: 8082  # Metrics
        env:
        - name: TS_NUM_GPU
          value: "1"
        - name: TS_MAX_BATCH_SIZE
          value: "32"
        - name: TS_MAX_BATCH_DELAY
          value: "100"
        resources:
          limits:
            nvidia.com/gpu: 1
          requests:
            cpu: "2"
            memory: "4Gi"

# Triton Inference Server Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: triton-inference
spec:
  replicas: 3
  selector:
    matchLabels:
      app: triton
  template:
    spec:
      containers:
      - name: triton
        image: nvcr.io/nvidia/tritonserver:24.01-py3
        ports:
        - containerPort: 8000  # HTTP
        - containerPort: 8001  # gRPC
        - containerPort: 8002  # Metrics
        args:
        - "tritonserver"
        - "--model-repository=/models"
        - "--strict-model-config=false"
        - "--log-verbose=1"
        resources:
          limits:
            nvidia.com/gpu: 2
            memory: "16Gi"
          requests:
            cpu: "4"
            memory: "8Gi"
        readinessProbe:
          httpGet:
            path: /v2/health/ready
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10

# GPU Operator kurulumu
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true \
  --set devicePlugin.enabled=true \
  --set mig.strategy=mixed

# GPU Time-Slicing ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: gpu-sharing-config
data:
  any: |-
    version: v1
    sharing:
      timeSlicing:
        renameByDefault: false
        resources:
        - name: nvidia.com/gpu
          replicas: 4  # Her GPU 4 pod arasında paylaşılır

⚠️ Uyarı

GPU time-slicing, GPU belleğini izole etmez. Birden fazla workload aynı GPU belleğini paylaşır ve OOM (Out of Memory) riski oluşabilir. Kritik production workload'ları için MIG veya dedicated GPU kullanmanız önerilir.

# GPU node'larına taint ekleme
kubectl taint nodes gpu-node-1 nvidia.com/gpu=present:NoSchedule

# Pod'a toleration ekleme
spec:
  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Equal"
    value: "present"
    effect: "NoSchedule"
  nodeSelector:
    accelerator: nvidia-a100

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: triton-inference
  minReplicas: 2
  maxReplicas: 20
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 120
  metrics:
  - type: Pods
    pods:
      metric:
        name: inference_request_queue_size
      target:
        type: AverageValue
        averageValue: "10"
  - type: Pods
    pods:
      metric:
        name: gpu_utilization_percent
      target:
        type: AverageValue
        averageValue: "70"

ai-model-chart/
├── Chart.yaml
├── values.yaml
├── values-staging.yaml
├── values-production.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   ├── secret.yaml
│   ├── servicemonitor.yaml
│   └── _helpers.tpl
└── tests/
    └── test-connection.yaml

# values.yaml - Parametrik yapılandırma
replicaCount: 2
image:
  repository: registry.example.com/ai-model
  tag: "v2.1.0"
  pullPolicy: IfNotPresent

model:
  name: "text-classifier"
  version: "2.1"
  framework: "triton"
  storageUri: "s3://models/text-classifier/v2.1/"

resources:
  limits:
    nvidia.com/gpu: 1
    memory: "8Gi"
  requests:
    cpu: "2"
    memory: "4Gi"

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetGPUUtilization: 70

monitoring:
  enabled: true
  serviceMonitor: true

# Staging deployment
helm upgrade --install ai-model ./ai-model-chart \
  -f values-staging.yaml \
  --namespace ai-staging

# Production deployment
helm upgrade --install ai-model ./ai-model-chart \
  -f values-production.yaml \
  --namespace ai-production

# ServiceMonitor for Prometheus
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: inference-monitor
spec:
  selector:
    matchLabels:
      app: triton-inference
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics
  namespaceSelector:
    matchNames:
    - ai-production

# GitHub Actions - AI Model CI/CD Pipeline
name: AI Model Deploy
on:
  push:
    paths: ['models/**', 'src/serving/**']

jobs:
  validate-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Run Model Validation
      run: |
        python scripts/validate_model.py \
          --model-path models/latest \
          --min-accuracy 0.95 \
          --max-latency-ms 100
    
    - name: Build & Push Container
      run: |
        docker build -t $REGISTRY/ai-model:${{ github.sha }} .
        docker push $REGISTRY/ai-model:${{ github.sha }}
    
    - name: Deploy Canary
      run: |
        helm upgrade ai-model ./charts/ai-model \
          --set image.tag=${{ github.sha }} \
          --set canary.enabled=true \
          --set canary.weight=10
    
    - name: Validate Canary Metrics
      run: |
        python scripts/check_canary.py \
          --duration 600 \
          --max-error-rate 0.01 \
          --max-p99-latency 200
    
    - name: Full Rollout
      if: success()
      run: |
        helm upgrade ai-model ./charts/ai-model \
          --set image.tag=${{ github.sha }} \
          --set canary.enabled=false

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: ai-model-rollout
spec:
  strategy:
    canary:
      canaryService: ai-model-canary
      stableService: ai-model-stable
      analysis:
        templates:
        - templateName: inference-success-rate
        startingStep: 1
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 30
      - pause: {duration: 5m}
      - setWeight: 60
      - pause: {duration: 10m}
      - setWeight: 100

💡 İpucu

Model serving endpoint'lerinize mutual TLS (mTLS) eklemek için Istio veya Linkerd gibi service mesh çözümlerini kullanabilirsiniz. Bu, hem güvenlik hem de traffic management açısından büyük avantaj sağlar.

Kubernetes olmadan AI model deployment yapılabilir mi?

Evet, AWS SageMaker, Google Vertex AI veya Azure ML gibi managed servisler kullanılabilir. Ancak Kubernetes, vendor lock-in'den kaçınma, tam kontrol ve hybrid/multi-cloud esnekliği sunar. Küçük ölçekli projeler için Docker Compose veya serverless seçenekler de değerlendirilebilir.

Hangi model serving framework'ünü seçmeliyim?

Framework seçimi kullanılan ML framework'üne ve gereksinimlere bağlıdır. Yalnızca TensorFlow modelleri serve ediyorsanız TF Serving, PyTorch modelleri için TorchServe idealdir. Birden fazla framework kullanıyorsanız veya gelişmiş ensemble/pipeline desteğine ihtiyacınız varsa NVIDIA Triton en kapsamlı çözümdür.

GPU olmadan Kubernetes'te model serving yapılabilir mi?

Evet, birçok model CPU üzerinde de verimli şekilde çalıştırılabilir. ONNX Runtime, OpenVINO gibi araçlar CPU inference performansını optimize eder. Küçük modeller, quantize edilmiş modeller veya düşük throughput gereksinimleri için CPU-only deployment makul bir seçenektir. Ancak büyük transformer modelleri için GPU neredeyse zorunludur.

Canary deployment sırasında model performansı nasıl değerlendirilir?

Canary deployment'ta yeni modele kademeli olarak trafik yönlendirilirken, inference latency (P50/P95/P99), error rate, prediction distribution ve business metrikleri (conversion rate, kullanıcı etkileşimi) karşılaştırılır. Argo Rollouts veya Flagger gibi araçlar, bu metrikleri Prometheus'tan çekerek otomatik rollback kararı verebilir.

Scale-to-zero yaklaşımı AI inference için uygun mudur?

Scale-to-zero, maliyet açısından cazip olsa da AI inference için cold start süreleri önemli bir dezavantajdır. GPU pod'larının başlatılması, model yüklenmesi ve warmup süreci dakikalar alabilir. KEDA ile scale-to-zero uygulanabilir ancak yalnızca düşük trafik alan veya latency-insensitive workload'lar için önerilir. Kritik inference endpoint'leri için minimum 1-2 replica her zaman çalışır durumda tutulmalıdır.

KServe (eski adıyla KFServing) nedir ve ne zaman kullanılmalıdır?

KServe, Kubernetes üzerinde standardize model serving sağlayan bir CRD (Custom Resource Definition) ve controller'dır. InferenceService abstraction'ı ile TF Serving, TorchServe ve Triton gibi runtime'ları tek bir API altında birleştirir. Transformer ve Explainer bileşenleri ile pre/post processing ve model açıklanabilirliği entegre edilebilir. Kubeflow ekosistemi ile çalışıyorsanız KServe doğal bir seçimdir.