“Trafik ne zaman gelirse, sistem onunla beraber otomatik büyüsün, gece düştüğünde de küçülsün.” Bulutun en temel vaadi. Pratikte uygulamak için doğru autoscaling katmanını seçmek + threshold’ları doğru ayarlamak + scale lag’i yönetmek gerekiyor. Bu yazı bir e-ticaret platformunda yaptığımız Black Friday hazırlığından çıkarılan saha notları.

Autoscaling’in 4 Katmanı

Katman	Ne yapar	Tipik araç
1. Pod-level (horizontal)	Aynı uygulamanın replika sayısını artırır/azaltır	Kubernetes HPA
2. Pod-level (vertical)	Pod’un CPU/RAM request/limit’ini artırır	Kubernetes VPA
3. Node-level	Cluster’a yeni node ekler/çıkarır	Cluster Autoscaler, Karpenter
4. Infra-level	VM Scale Set, Application Gateway capacity	Azure VMSS, AWS ASG, OpenStack Heat

4 katman birlikte çalışmalı. HPA pod sayısını artırır → mevcut node’larda yer yoksa pending pod oluşur → Cluster Autoscaler yeni node ekler → node’lar boşaldığında küçülür.

HPA: Pod Sayısı Otomatik Ayarlama

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 4
  maxReplicas: 60
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 75
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "200"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30
      - type: Pods
        value: 4
        periodSeconds: 30
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 25
        periodSeconds: 60

Önemli notlar:

• scaleUp hızlı (30 saniye stabilization) — trafik gelince hemen büyü.
• scaleDown yavaş (300 saniye) — flapping (sürekli büyüme/küçülme) önleme.
• Custom metric (http_requests_per_second) Prometheus Adapter ile expose edilir.
• Multi-metric: en yüksek replica gerektiren metrik kazanır.

E-ticaret API server için: normal saatlerde 4 pod, Black Friday gece 00:00 ile 4 dakikada 32 pod oldu, peak saatte 56 pod, sabaha doğru 12 pod, sabah saat 09:00’da tekrar 18 pod (kullanıcı login dalgası).

Cluster Autoscaler: Node Ekleme/Çıkarma

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
spec:
  template:
    spec:
      containers:
      - name: cluster-autoscaler
        image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.28.0
        command:
        - ./cluster-autoscaler
        - --cloud-provider=azure
        - --nodes=3:30:nodepool-spot
        - --nodes=2:10:nodepool-ondemand
        - --scale-down-utilization-threshold=0.5
        - --scale-down-unneeded-time=10m
        - --scale-down-delay-after-add=10m
        - --max-node-provision-time=15m
        - --skip-nodes-with-local-storage=false

Best practice:

• İki node pool: spot (ucuz, eviction’a tolere edebilen workload) + on-demand (kritik workload).
• scale-down-unneeded-time = 10 dk (flapping önleme).
• scale-down-utilization-threshold = 0.5 (%50 altında utilization olan node aday).
• PodDisruptionBudget tanımla (kritik servisler için min available 2).

Black Friday gecesi cluster 8 node’dan 24 node’a çıktı (15 dakikada). Sabah 06:00’da 12 node’a indi.

Karpenter: Cluster Autoscaler’a Modern Alternatif

AWS EKS’de daha popüler, AKS için de geliyor. Avantajları:

• Pending pod’un ihtiyacına göre tam doğru SKU node provisioning (Cluster Autoscaler önceden tanımlı pool’larla sınırlı).
• Daha hızlı (60 saniye node ready).
• Daha akıllı bin-packing (pod’ları daha az node’a sığdırma).

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["Standard_D4s_v5", "Standard_D8s_v5", "Standard_D16s_v5"]
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s

VPA: Pod Boyutunu Otomatik Ayarlama

VPA (Vertical Pod Autoscaler), pod’un CPU/RAM request’ini otomatik ayarlar. Scaling modları:

• Off: Sadece öneri sunar, uygulamaz.
• Initial: Yeni pod oluşurken ayarlar.
• Auto: Mevcut pod’u kill edip yeni request’le açar.

HPA + VPA aynı anda CPU üzerinde olamaz. Bizim pratiğimiz: HPA CPU üzerine, VPA memory üzerine.

E-ticaret platformunda Auto modda kullanmadık (production’da pod restart kabul edilemez), Off modunda öneri toplayıp manuel rightsizing yaptık. Tipik öneriler %30 düşük request, ciddi kaynak tasarrufu.

KEDA: Event-Driven Autoscaling

HPA CPU/memory tabanlı. Bazı senaryolar için yetersiz: queue length, Kafka lag, RabbitMQ message count, Azure Service Bus message count.

KEDA (Kubernetes Event-Driven Autoscaling) bu eksikliği kapatır:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0
  maxReplicaCount: 50
  pollingInterval: 10
  cooldownPeriod: 300
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: orders-incoming
      messageCount: "10"
    authenticationRef:
      name: keda-trigger-auth-azure-sb

Trafik yokken minReplicaCount=0 — uygulama hiç çalışmıyor, fatura yok. Mesaj gelince 0’dan 1’e, devamında her 10 mesajda yeni bir replica.

Müşterimizin batch processing iş yükünde aylık compute fatura $1.800 → $420.

Predictive Scaling: Trafik Tahminine Göre Önceden Büyüme

Reactive autoscaling’de “trafik geldi, sistem büyümeye başladı, ama pod ready oluncaya kadar kullanıcı 503 alıyor” sorunu var. Predictive scaling bunu önler.

• Time-based scaling: Cron benzeri kurallar. “Pazartesi-Cuma 08:30’da 10 replica, 18:00’da 4’e düş” gibi.
• ML-based prediction: Geçmiş trafik datasından öğrenip 5-15 dk önce ölçeklendirme. Azure HPA AI desteği, AWS Predictive Scaling.

E-ticaret platformunda Black Friday için manuel kural eklemiştik: 23 Kasım 22:00’da min replica 8’den 24’e yükselt, 24 Kasım 06:00’da geri düşür. Trafik gelmeden önce kapasite hazırdı.

Sahada Düşülen Üç Tuzak

1. Sadece CPU’ya bakmak: I/O bound uygulamalar (database connection wait, external API call) düşük CPU ile bottleneck olur. RPS / queue depth gibi business metrik şart.
2. Scale-down agresif: Çok hızlı küçülürse trafik dalga dalga gelirse sürekli flapping. Stabilization window 5 dakika minimum.
3. PDB tanımlamamak: Cluster Autoscaler node drain ederken kritik servisin tüm pod’larını aynı anda kill edebilir. Min available 2 PDB ile koruma.

Sonuç: Autoscaling Bir Sigorta Değil, Bir Disiplin

Autoscaling açıp “iyi geceler” diyemezsin. Threshold’ları monitor et, ölçeklendirme olaylarını incele, false positive/negative’leri ayarla. Düzgün kurulduğunda gece uyuyabiliyorsun ama düzgün kurulmadığında gece üçte alarmla uyanan da o oluyor.

CloudSpark olarak Kubernetes autoscaling assessment, KEDA implementasyonu, multi-tier scaling design ve cost optimization (rightsizing + autoscaling kombinasyonu) projelerinde danışmanlık veriyoruz.