2026'da Kubernetes autoscaling, HPA, VPA, KEDA ve Karpenter'ın birlikte çalışması demek

dev.to'da yayımlanan bir rehber, Horizontal Pod Autoscaler'ın tek başına artık üretim Kubernetes'i için yeterli olmadığı görüşünü savunuyor ve HPA, VPA, KEDA ile Karpenter'ın her araca tasarlandığı yığın katmanı atandığında nasıl güvenle birleştirilebileceğini açıklıyor.

Autoscaling üç seviyede gerçekleşir

Makale, küme autoscaling'i üç bağımsız seviye olarak çerçeveliyor: HPA ve KEDA'nın sorumlu olduğu replika sayısı; VPA'nın yönettiği pod başına CPU ve bellek istekleri; ve Cluster Autoscaler ya da Karpenter'ın üstlendiği node sayısı. Yazara göre en yaygın tasarım hatası, bir aracı yanlış seviyede kurmak. HPA replika sayısını artırabilir ama node oluşturamaz; dolayısıyla mevcut node'lar tamamen doluysa yeni podlar Pending durumunda bekler. Benzer şekilde KEDA kuyruk derinliğini okuyabilir ama baştan yanlış yapılandırılmış kaynak isteklerini düzeltemez.

HPA: kanıtlanmış, ama küçültmeyi ayarlayın

HPA, CPU ve bellek temelli ölçeklendirme için standart seçim olmaya devam ediyor ve autoscaling/v2 ile birlikte, Prometheus Adapter gibi bir metrics adapter kuruluysa, saniye başına istek veya kuyruk uzunluğu gibi özel metriklere de tepki verebiliyor. Makale, stabilizasyon penceresini hafife alınan bir ayar olarak öne çıkarıyor: ölçek küçültme için en fazla dakikada %10 pod kaldırılacak şekilde 300 saniyelik bir pencere öneriyor, ölçek büyütmeyi ise anlık bırakıyor. Yazar, bu yapılandırmanın kısa yük sıçramalarının sürekli yukarı-aşağı dalgalanmaya yol açmasını engellediğini yazıyor.

KEDA: olay temelli ölçeklendirme ve sıfıra küçültme

KEDA, HPA modelini 60'tan fazla yerel scaler ile genişletiyor; Kafka consumer gecikmesi, RabbitMQ kuyruk derinliği, AWS SQS ve Redis liste uzunluğu gibi kaynakları kapsıyor. Klasik HPA'nın aksine, bekleyen olay kalmadığında iş yüklerini sıfıra kadar küçültabiliyor; makale bunun batch işlerine, arka plan worker'larına ve mevsimsel trafiğe uygun olduğunu söylüyor. Yazıya göre Eylül 2026'da yayımlanan KEDA 2.16, ClusterTriggerAuthentication için dosya tabanlı kimlik doğrulama ve yeni Kubernetes kaynak scaler'ları ekliyor; bir sonraki sürüm Ocak 2027'ye planlanmış. HTTP iş yükleri için bir KEDA eklentisi gelen istekleri tamponlayıp podları gerektiğinde bekleme modundan çıkarıyor; yazar bunu sürekli çalışan API gateway instance'larına alternatif olarak sunuyor.

VPA: yerinde yeniden boyutlandırma yeniden başlatma cezasını kaldırıyor

Makaleye göre Vertical Pod Autoscaler yakın zamanda belirleyici sıçramasını yaptı: yerinde pod yeniden boyutlandırma Aralık 2025'te Kubernetes 1.35 ile genel kullanıma açıldı ve VPA 1.2 ile sonrası, podu zorunlu olarak yeniden başlatmadan kaynak isteklerini ayarlayan bir InPlaceOrRecreate modu sunuyor. Bu, yazarın VPA'yı üretimde çalıştırmanın en büyük engeli dediği sorunu ortadan kaldırıyor.

Ancak iki araç arasındaki bilinen etkileşim tehlikesi sürüyor. HPA ve VPA aynı CPU ya da bellek metriklerini okuduğunda, VPA istekleri geçmişe göre düşürüyor, HPA da aynı mutlak kullanımı daha yüksek bir yüzde olarak yorumlayıp yatayda ölçekleniyor ve ikisi birbirini besliyor. Önerilen çözümler, VPA CPU ve bellekten sorumluyken HPA'yı RPS veya kuyruk derinliği gibi özel metriklerle sürmek, ya da VPA'yı sadece öneri toplayıp uygulamayan Off modunda çalıştırmak.

Karpenter: node grupları olmadan node sağlama

Altyapı katmanında makale, Karpenter'ın AWS'de Cluster Autoscaler'ın yerini büyük ölçüde aldığını söylüyor. Karpenter, önceden tanımlı node grupları üzerinden çalışmak yerine node'ları doğrudan bulut API'si ile sağlıyor, bekleyen podlar için en maliyet-etkin instance türünü seçiyor ve az kullanılan node'ları agresif biçimde birleştiriyor. Arkasındaki satıcı, klasik Cluster Autoscaler'a kıyasla %40–60 daha iyi node kullanımı sağladığını iddia ediyor; makale bu rakamı bir satıcı iddiası olarak aktarıyor. Google Kubernetes Engine'de ise Google Cloud için üretim hazır bir Karpenter sağlayıcısı bulunmadığından Cluster Autoscaler şimdilik varsayılan olarak kalıyor.

İş yüküne göre önerilen eşleştirmeler

Rehber, iş yükü başına tariflerle kapanıyor. Durumsuz, gecikmeye duyarlı bir web API'si, CPU artı RPS özel metriği üzerinden HPA ile Off modundaki VPA ile eşleşmeli ve Spot ile On-Demand kapasitesini karıştıran Karpenter node'larında çalışmalı. Kuyruk dinleyen arka plan worker'ları, Spot instance'larda sıfıra küçültmeyle KEDA'ya uyuyor; iş yeniden deneme mekanizmaları tek tek kaybedilen podları telafi ediyor. GPU tabanlı ML çıkarımı, GPU node'larının ayağa kaldırılmasının pahalı olması nedeniyle daha uzun bekleme süresiyle HTTP veya özel Prometheus metrikleri kullanan KEDA ile en iyi ölçekleniyor.

Neden önemli

Yazı, Kubernetes kapasite yönetiminin tek kollu bir sorundan ne kadar uzaklaşıp çok araçlı bir disipline dönüştüğünü yansıtıyor. Yazarın savunduğu gibi, artık faydalı soru hangi autoscaler'ın en iyi olduğu değil, hangi sinyalin hangi nesneyi ölçeklediği. Her iş yükü için otomatik olarak HPA'yı seçen — en yaygın hata olarak gösterilen — ekipler hem istikrarsızlık hem de aşırı harcama riski taşırken, replika, pod ve node katmanları arasında bilinçli bir sorumluluk paylaşımı maliyet verimliliğini ve istikrarı aynı anda iyileştirebiliyor.