Konteyner orkestrasyon platformlarının en büyük vaatlerinden biri iş yüklerine göre otomatik ölçeklemedir. Ancak Kubernetes’te ölçekleme tek boyutlu değildir. Farklı katmanlarda farklı ölçekleme mekanizmaları çalışır ve bunların doğru konfigürasyonu hem performans hem de maliyet açısından kritiktir. Pod düzeyinde yatay ve dikey ölçekleme, node düzeyinde cluster ölçekleme birlikte çalışmalıdır. Gelin bu üç mekanizmayı derinlemesine inceleyelim.

Horizontal Pod Autoscaler (HPA)

HPA, Kubernetes’in en yaygın kullanılan ölçekleme mekanizmasıdır. Belirli metriklere göre pod sayısını (replica count) otomatik olarak artırır veya azaltır. Varsayılan metrik CPU kullanımıdır ancak bellek, özel uygulama metrikleri veya harici metrikler de kullanılabilir.

HPA’nın çalışma prensibi şudur: Her 15 saniyede (varsayılan) metrics server’dan mevcut pod’ların metrik değerlerini çeker. Bu değerlerin ortalamasını alır ve hedef değerle karşılaştırır. Eğer mevcut kullanım hedefin üzerindeyse pod sayısını artırır, altındaysa azaltır. Hesaplama formülü basittir: istenenReplika = ceil(mevcutReplika × (mevcutMetrik / hedefMetrik)). Örneğin 3 pod’unuz var, ortalama CPU yüzde 80, hedefiniz yüzde 50 ise: ceil(3 × (80/50)) = ceil(4.8) = 5 pod’a ölçeklenir.

HPA Konfigürasyon Örneği

Tipik bir HPA tanımında minimum replica sayısı, maksimum replica sayısı ve hedef metrik belirlenir. Minimum değeri en az 2 olarak ayarlamanız önerilir; tek pod çalışırken o pod’un yeniden başlaması servis kesintisine yol açar. Maksimum değeri ise cluster kaynaklarınızla uyumlu tutun, aksi halde HPA pod oluşturmaya çalışır ancak node kapasitesi yetmediğinde pod’lar Pending durumunda kalır.

Dikkat edilmesi gereken bir nokta: HPA’nın düzgün çalışması için pod’larınızda resource request tanımlanmış olması şarttır. CPU bazlı ölçekleme yapıyorsanız resources.requests.cpu mutlaka belirtilmelidir. Bu değer olmadan HPA kullanım oranını hesaplayamaz.

Custom ve External Metrikler

CPU ve bellek dışında uygulama seviyesinde metriklerle ölçekleme yapmak çoğu zaman daha etkilidir. Prometheus Adapter veya KEDA (Kubernetes Event-Driven Autoscaling) kullanarak kuyruk derinliği, istek sayısı, ortalama cevap süresi gibi metriklere göre ölçekleme yapabilirsiniz. Mesela bir mesaj kuyruğundaki bekleyen mesaj sayısı 100’ü aştığında worker pod sayısını artırmak, CPU bazlı ölçeklemeden çok daha anlamlı bir stratejidir.

Vertical Pod Autoscaler (VPA)

HPA pod sayısını değiştirirken VPA mevcut pod’ların kaynak taleplerini (CPU ve memory request/limit) ayarlar. Bazı iş yükleri yatay ölçeklemeye uygun değildir: stateful uygulamalar, veritabanları veya lider seçimi yapan servisler. Bu tür iş yüklerinde pod sayısını artırmak yerine mevcut pod’a daha fazla kaynak vermek mantıklıdır.

VPA üç modda çalışır: Off modu yalnızca öneri üretir, pod’lara dokunmaz. Initial modu yalnızca pod oluşturulurken önerilen değerleri uygular. Auto modu çalışan pod’ları yeniden başlatarak kaynak değerlerini günceller. Auto modu kullanırken dikkatli olun çünkü pod yeniden başlatma servis kesintisine neden olabilir, PodDisruptionBudget tanımlayarak bu riski azaltabilirsiniz.

Önemli bir kısıtlama: HPA ve VPA aynı metrik üzerinde aynı anda kullanılamaz. Örneğin hem HPA hem VPA CPU bazlı çalışıyorsa çakışma oluşur. Yaygın uygulama, HPA’nın custom metriklerle yatay ölçekleme yapması ve VPA’nın CPU/memory bazında dikey ayar yapmasıdır.

Cluster Autoscaler

HPA ve VPA pod seviyesinde çalışır ancak pod’ların çalışabilmesi için yeterli node kapasitesi olması gerekir. Cluster Autoscaler tam bu katmanda devreye girer: kaynak yetersizliği nedeniyle Pending durumunda kalan pod’lar olduğunda yeni node ekler, boş node’ları ise kaldırarak maliyeti düşürür.

Cluster Autoscaler’ın karar mekanizması şöyle işler: Bir pod planlanamadığında (Pending) nedeni kontrol edilir. Eğer neden kaynak yetersizliği ise ve mevcut node pool’un maksimum boyutuna ulaşılmamışsa yeni node eklenir. Eklenen node’un hazır olması birkaç dakika sürer (VM provisioning süresi). Diğer yönde, bir node üzerindeki tüm pod’lar başka node’lara taşınabilir durumda ise ve node belirli bir süre (varsayılan 10 dakika) boş kalırsa node kaldırılır.

Node Pool Stratejileri

Farklı iş yükleri için farklı node pool’lar tanımlamak en iyi uygulamadır. Genel amaçlı iş yükleri için Standard_D tipinde node pool, bellek yoğun uygulamalar için Standard_E tipinde, GPU gerektiren ML iş yükleri için Standard_NC tipinde ayrı pool’lar oluşturabilirsiniz. Her pool’un min/max boyutunu ayrı belirlersiniz. Spot node pool ekleyerek önceliksiz iş yükleri için maliyeti yüzde 60-90 oranında düşürebilirsiniz.

Üç Mekanizmanın Birlikte Çalışması

En etkili ölçekleme stratejisi üç mekanizmanın koordineli çalışmasıdır. Tipik bir senaryo şöyledir: Trafik arttığında HPA pod sayısını yükseltir. Yeni pod’lar için mevcut node’larda yeterli kaynak yoksa Cluster Autoscaler yeni node ekler. VPA ise uzun vadeli kaynak trendlerini izleyerek pod’ların request/limit değerlerini optimize eder, böylece hem aşırı kaynak ayrımını (overprovisioning) hem de yetersiz kaynağı (underprovisioning) önler.

İzleme ve Sorun Giderme

Otomatik ölçeklemenin düzgün çalıştığını izlemek için metrics-server’ın sağlıklı olduğundan emin olun. kubectl get hpa komutuyla HPA durumunu, kubectl describe hpa ile detaylı olayları kontrol edin. Cluster Autoscaler loglarını izlemek için kubectl logs -n kube-system cluster-autoscaler kullanın. Ölçekleme gecikmesi yaşıyorsanız --scale-down-delay-after-add ve --scale-down-unneeded-time parametrelerini gözden geçirin.

KEDA: Event-Driven Autoscaling

Kubernetes’in yerleşik HPA mekanizması CPU ve bellek gibi kaynak metriklerine dayalı çalışır ancak modern event-driven mimarilerde bu yeterli olmayabilir. KEDA (Kubernetes Event-Driven Autoscaling) bu boşluğu dolduran bir CNCF projesidir. KEDA sayesinde Azure Service Bus kuyruğundaki mesaj sayısına, Kafka topic’teki lag’a, Redis stream uzunluğuna, PostgreSQL sorgu sonucuna veya Prometheus metriğine göre pod sayısını ölçekleyebilirsiniz. Hatta sıfıra kadar ölçekleme yapabilirsiniz ki bu HPA ile mümkün değildir.

KEDA’nın çalışma prensibi şöyledir: ScaledObject tanımında bir trigger kaynağı ve hedef deployment belirtirsiniz. KEDA belirli aralıklarla trigger kaynağını sorgular ve metrik değerine göre pod sayısını ayarlar. Kuyrukta mesaj yoksa pod sayısı sıfıra düşer, mesaj geldiğinde pod oluşturulur ve mesajlar işlenir. Bu yaklaşım özellikle aralıklı iş yükleri (sporadik trafik, batch processing, cron job benzeri görevler) için idealdir. Mesaj yokken hiç kaynak tüketimi olmaz, dolayısıyla maliyet de sıfırdır.

Azure Kubernetes Service (AKS) ortamında KEDA kurulumu basittir. Helm chart ile birkaç dakikada deploy edebilirsiniz. Azure Service Bus, Azure Storage Queue, Azure Event Hubs gibi Azure hizmetleri için hazır trigger’lar mevcuttur. Managed Identity ile kimlik doğrulama yaparak secret yönetimi yükünden de kurtulabilirsiniz.

Ölçekleme Stratejisi Tasarımı

Etkin bir ölçekleme stratejisi tasarlamak için iş yükünüzün karakteristiğini anlamanız gerekir. Farklı iş yükü tipleri farklı ölçekleme yaklaşımları gerektirir.

Stateless web servisleri: HPA ile CPU veya request-per-second bazlı yatay ölçekleme idealdir. Pod sayısını minimum 2’de tutarak tek pod arızası durumunda kesinti yaşanmasını önleyin. PodDisruptionBudget ile rolling update sırasında en az bir pod’un çalışır durumda kalmasını garanti edin.

Worker veya consumer pod’ları: KEDA ile kuyruk derinliğine dayalı ölçekleme yapın. Sıfıra ölçekleme özelliğiyle boşta kaynak tüketimini engelleyin. maxReplicaCount ile aşırı ölçeklemeyi önleyin; çok fazla consumer olması downstream sistemleri (veritabanı, API) aşırı yükleyebilir.

Stateful uygulamalar (veritabanları, cache): VPA ile dikey ölçekleme tercih edin. StatefulSet üzerinde HPA kullanmak veri tutarlılığı sorunlarına yol açabilir. VPA’nın Off modunda çalıştırıp önerilerini kontrollü biçimde uygulamak güvenli bir yaklaşımdır.

Ölçekleme Reaksiyon Süresi ve Buffer Kapasitesi

Otomatik ölçeklemenin arka planda zaman alması zaman zaman gözden kaçan kritik bir konudur. HPA’nın metrik topladıktan sorma karar vermesi 15-30 saniye, yeni pod’un başlatılması 5-60 saniye (imaj boyutu ve pull süresine bağlı), Cluster Autoscaler’ın yeni node eklemesi ise 3-5 dakika sürebilir. Bu toplam gecikme bir trafik spike’ı sırasında servis kalitesini düşürebilir.

Bu gecikmeyi azaltmak için birkaç strateji kullanılabilir. Birincisi overprovisioning: gerçek ihtiyaçtan biraz daha fazla pod çalıştırarak ani artışlara karşı tampon oluşturun. İkincisi priority-based preemption: düşük öncelikli placeholder pod’lar oluşturun, bu pod’lar node kapasitesini hazır tutar ve gerçek iş yükü geldiğinde yerlerini gerçek pod’lara bırakır. Üçüncüsü image caching: sık kullanılan imajları DaemonSet ile tüm node’lara önceden çekin, böylece yeni pod başlatılırken imaj pull süresi ortadan kalkar.

Ölçekleme İzleme ve Alarming

Otomatik ölçeklemenin doğru çalıştığını izlemek için aşağıdaki metrikleri ve olayları takip edin. HPA current/desired replica sayıları, mevcut metrik değerleri ve target utilization oranları Prometheus veya Azure Monitor ile izlenmelidir. Cluster Autoscaler’ın ekleme ve kaldırma olayları loglanmalı ve anormal durumlar (uzun süreli Pending pod, scale-up failures) için alarmlar oluşturulmalıdır.

Grafana dashboard’ları ile ölçekleme davranışını görselleştirmek yaygın bir uygulamadır. Pod sayısı, node sayısı, kaynak kullanım oranları ve ölçekleme olaylarının zaman serisini tek bir dashboard’da görmek, ölçekleme stratejinizin etkinliğini değerlendirmenize ve ayarlama yapmanıza yardımcı olur.

Sıkça Karşılaşılan Sorunlar

HPA flapping: Pod sayısının sürekli artıp azalması durumu. Bu genellikle hedef metrik değerinin iş yüküne göre çok hassas ayarlanmasından kaynaklanır. behavior alanında stabilizasyon penceresi tanımlayarak (örneğin scaleDown stabilizasyonu 300 saniye) ani dalgalanmaları önleyebilirsiniz.

Pending pods: HPA pod sayısını artırır ama node kapasitesi yetmez. Cluster Autoscaler devreye girer ancak node eklenmesi dakikalar alır. Bu süre zarfında pod’lar Pending kalır. Çözüm olarak node pool max boyutunun yeterli olduğundan emin olun ve cluster autoscaler profileında scan-interval değerini düşürün.

Memory-based HPA sorunları: Bellek kullanımı CPU’ya göre daha az elastiktir çünkü birçok uygulama belleği serbest bırakmak yerine cache olarak tutar. Bellek bazlı HPA pod sayısını sürekli artırabilir ama bellek düşmediği için azaltamaz. Bu nedenle bellek bazlı HPA dikkatli kullanılmalıdır, tercihen memory leak olmayan ve bellek davranışı tahmin edilebilir uygulamalarda.

Sonuç

Kubernetes otomatik ölçekleme, doğru yapılandırıldığında hem performans hem maliyet açısından büyük avantaj sağlar. HPA ile iş yükünüze göre pod sayısını dinamik tutun, VPA ile kaynak tahsisini optimize edin, Cluster Autoscaler ile altyapıyı elastik hale getirin. Bu üç mekanizmanın birlikte çalışması, üretim ortamınızın hem sağlıklı hem de ekonomik olmasını sağlayacaktır.

Cloudspark Kubernetes ve konteyner yönetimi hizmetlerimizle cluster’larınızın ölçekleme stratejisini tasarlıyor ve uyguluyoruz.