Detailed image of illuminated server racks showcasing modern technology infrastructure.

“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.

🇹🇷 Türkçe🇬🇧 English🇩🇪 Deutsch🇫🇷 Français🇸🇦 العربية🇷🇺 Русский🇪🇸 Español