AKS Pod Otomatik Ölçeklendirme Ayarları Rehberi

Bir AKS kümesinde pod sayısını artırmak tek başına kapasite sorununu çözmez. Yeni pod’ların çalışacağı node yoksa uygulama Pending durumunda kalır; kaynak istekleri yanlış tanımlandıysa HPA beklenmedik biçimde ölçekleme yapar. Bu nedenle AKS pod otomatik ölçeklendirme ayarları, yalnızca bir YAML manifesti değil, uygulama davranışı, node kapasitesi ve maliyet yönetiminin birlikte ele alınması gereken bir üretim tasarımıdır.

Bu yapı üç farklı katmanı kapsar: Pod seviyesinde Horizontal Pod Autoscaler (HPA), node pool seviyesinde Cluster Autoscaler ve olay ya da kuyruk temelli ihtiyaçlar için KEDA. Doğru sonuç, bu bileşenlerin her birini etkinleştirmekten değil, iş yükünün gerçek darboğazına uygun olanı seçmekten gelir.

AKS Pod Otomatik Ölçeklendirme Ayarları Nasıl Çalışır?

HPA, bir Deployment veya StatefulSet altındaki replika sayısını metrik hedeflerine göre değiştirir. En yaygın kullanım CPU ve bellek kullanımına göre ölçeklemedir. Ancak HPA’nın CPU yüzdesini hesaplayabilmesi için container üzerinde `resources.requests.cpu` tanımlı olmalıdır. İstek değeri yoksa HPA, CPU kullanım oranını güvenilir biçimde hesaplayamaz ve ilgili pod’ları değerlendirme dışında bırakabilir.

Cluster Autoscaler ise pod sayısını değil, node pool içindeki VM sayısını yönetir. HPA yeni replika istediğinde Kubernetes scheduler bu pod’ları yerleştirecek uygun node bulamazsa pod’lar Pending olur. Cluster Autoscaler bu durumu algılar ve node pool maksimum sınırına kadar yeni node ekler. Trafik düştüğünde ise uygun koşullar oluşursa kullanılmayan node’ları kaldırır.

KEDA farklı bir ihtiyaca cevap verir. HTTP trafiği yerine Azure Service Bus kuyruk uzunluğu, Azure Storage Queue, Kafka consumer lag veya Prometheus metriği gibi harici sinyaller ölçekleme kararını belirliyorsa KEDA daha doğru tercihtir. Bazı worker iş yüklerinde minimum replika sayısını sıfıra indirmek de KEDA ile mümkündür.

İlk Önce Kaynak İsteklerini Doğru Tanımlayın

Otomatik ölçeklendirme çalışmalarında en sık karşılaşılan hata, CPU ve bellek limitlerini koyup request değerlerini varsayılan bırakmaktır. Kubernetes scheduler kararlarını request değerleri üzerinden verir. HPA’nın kaynak yüzdeleri de CPU için request değerine dayanır. Bu nedenle gerçekçi olmayan bir request, hem pod yerleşimini hem de ölçekleme eşiğini bozar.

Örneğin uygulama normal yükte 120m CPU kullanıyor, kısa süreli sıçramalarda 350m CPU tüketiyorsa `requests.cpu: 100m` tanımı HPA’nın çok erken ölçekleme yapmasına yol açabilir. Buna karşılık 500m request, pod’un gereksiz node kapasitesi ayırmasına ve HPA’nın geç tepki vermesine neden olabilir. Üretim metrikleri üzerinden başlangıç request değerini belirlemek, sonrasında gözlemleyerek iyileştirmek daha güvenlidir.

Bellek tarafında yaklaşım daha temkinli olmalıdır. CPU throttling uygulamayı yavaşlatabilir; bellek limiti aşıldığında ise container OOMKilled olabilir. Java, .NET veya yoğun cache kullanan servislerde bellek tüketimi pod yaşam döngüsü boyunca büyüyebilir. Bu nedenle yalnızca bellek yüzdesine dayalı HPA, bellek sızıntısını gizleyen geçici bir çözüm haline gelmemelidir.

Aşağıdaki Deployment örneği, HPA için uygun bir temel sağlar:

“`yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-service spec: replicas: 2 selector: matchLabels: app: api-service template: metadata: labels: app: api-service spec: containers:

• name: api-service

image: myregistry.azurecr.io/api-service:v1 resources: requests: cpu: 250m memory: 512Mi limits: cpu: “1” memory: 1Gi “`

Bu örnekte iki replika ile başlayan servis, pod başına 250m CPU kapasitesini scheduler’a rezerve eder. Bu değerler örnek niteliğindedir. Her uygulama için APM verileri, `kubectl top pods` çıktıları ve Azure Monitor gözlemleriyle doğrulanmalıdır.

HPA v2 ile CPU ve Bellek Tabanlı Ölçekleme

AKS üzerinde metrik tabanlı HPA kullanmak için kümede Metrics Server çalışıyor olmalıdır. Yönetilen AKS kurulumlarında bu bileşen çoğu senaryoda hazır gelir, ancak sorun giderme sırasında önce `kubectl top nodes` ve `kubectl top pods` komutlarıyla metrik erişimini doğrulamak gerekir.

Aşağıdaki HPA tanımı, CPU ortalaması request değerinin yüzde 65’ine ulaştığında replika sayısını artırır. Bellek için yüzde 75 hedefi de ikinci bir sinyal olarak kullanılır:

“`yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-service minReplicas: 2 maxReplicas: 12 behavior: scaleUp: stabilizationWindowSeconds: 0 policies:

• type: Percent

value: 100 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies:

• type: Percent

value: 25 periodSeconds: 60 metrics:

• type: Resource

resource: name: cpu target: type: Utilization averageUtilization: 65

• type: Resource

resource: name: memory target: type: Utilization averageUtilization: 75 “`

`minReplicas` değeri, uygulamanın yüksek erişilebilirlik ihtiyacına göre seçilmelidir. Tek Availability Zone veya tek node üzerinde çalışan kritik bir API için minimum 1 replika teknik olarak çalışsa da bakım, node arızası ve rolling update sırasında hizmet riski oluşturur. Çoğu kurumsal web servisi için en az iki replika ve bunların farklı node’lara dağıtılması daha doğru başlangıç noktasıdır.

`maxReplicas` ise sınırsız bırakılmamalıdır. Uygulamanın veritabanı connection pool’u, lisans limiti, üçüncü taraf API kotası veya backend kapasitesi pod sayısı arttıkça baskı altına girebilir. HPA’nın 50 replika oluşturabilmesi, bağımlı sistemlerin bu yükü kaldırabileceği anlamına gelmez.

Örnekteki `behavior` bölümü özellikle üretim ortamları için değerlidir. Scale-up hızlı tutulurken scale-down için 300 saniyelik bekleme penceresi kullanılır. Böylece kısa süreli trafik düşüşlerinde pod’lar hemen kaldırılmaz. Sürekli büyüyüp küçülen replica sayısı, bağlantı drenajı, cache ısınması ve log gürültüsü açısından operasyonel maliyet yaratır.

Node Pool ve Cluster Autoscaler Sınırları

HPA çalışıyor ancak pod’lar Pending görünüyorsa ilk bakılması gereken yer scheduler event’leridir. `kubectl describe pod` çıktısında `Insufficient cpu`, `Insufficient memory`, taint veya node selector uyumsuzluğu görülebilir. Bu durumda HPA doğru karar vermiş olabilir; sorun pod katmanında değil, node kapasitesindedir.

AKS’te Cluster Autoscaler node pool bazında etkinleştirilir. Her pool için minimum ve maksimum node sayısı belirlenir. Sistem pod’ları ile uygulama pod’larını aynı pool’da tutmak küçük kümelerde pratik olabilir; ancak kritik üretim iş yüklerinde ayrı user node pool kullanmak daha kontrollü bir tasarım sağlar. Böylece sistem bileşenlerinin kapasite ihtiyacı, uygulama trafiğinden daha az etkilenir.

Node pool maksimum değeri belirlenirken yalnızca beklenen trafik değil, VM kotası ve bölgesel kapasite de hesaba katılmalıdır. Ayrıca yeni node’un hazır hale gelmesi, mevcut bir pod’un replika olarak başlatılmasından daha uzun sürer. Ani trafik artışlarında HPA’nın ilk pod’ları mevcut kapasiteye yerleştirebilmesi için belirli bir boşluk bırakmak kritik servislerde mantıklı olabilir.

PodDisruptionBudget, topology spread constraints ve anti-affinity kuralları da autoscaler davranışını doğrudan etkiler. Fazla katı dağıtım kuralları, kümede kaynak bulunsa dahi pod’un yerleşmesini engelleyebilir. Bu ayarların yüksek erişilebilirlik hedefiyle kapasite maliyeti arasında dengelenmesi gerekir.

KEDA Ne Zaman Tercih Edilmeli?

Bir API servisinin CPU kullanımı, kullanıcı trafiğinin iyi bir göstergesi olabilir. Ancak bir arka plan worker’ında CPU düşükken kuyrukta binlerce mesaj bekliyor olabilir. Bu durumda CPU tabanlı HPA yetersiz kalır. KEDA, kuyruk uzunluğu gibi iş yükünü doğrudan temsil eden metriklere göre ölçekleme yaptığı için worker mimarilerinde daha öngörülebilir sonuç verir.

Örneğin her worker’ın hedef olarak 20 Azure Service Bus mesajını işlemesi isteniyorsa, KEDA kuyruk derinliğine göre pod sayısını artırabilir. Worker boşta kaldığında replika sayısını sıfıra düşürmek maliyeti azaltır. Buna karşın ilk mesaj geldiğinde pod başlatma gecikmesi oluşur. Kullanıcının anlık yanıt beklediği işlerde sıfıra ölçekleme uygun olmayabilir; batch veya asenkron görevlerde ise anlamlıdır.

Üretime Almadan Önce Kontrol Edin

Yapılandırmayı canlıya taşımadan önce dört noktayı test edin:

• Her container için ölçülmüş CPU ve bellek request değerleri tanımlı olmalıdır.
• HPA minimum ve maksimum replica sınırları, bağımlı servislerin kapasitesine göre doğrulanmalıdır.
• Node pool Cluster Autoscaler sınırları, HPA’nın ulaşabileceği kapasiteyi karşılamalıdır.
• Yük testi altında pod Pending, OOMKilled, throttling ve ölçekleme gecikmesi olayları izlenmelidir.

Doğrulama için `kubectl get hpa`, `kubectl describe hpa api-service-hpa`, `kubectl get pods -w` ve Kubernetes event’leri birlikte değerlendirilmelidir. Sadece replica sayısının arttığını görmek yeterli değildir. Asıl başarı ölçütü, gecikme süreleri yükselmeden ve node kapasitesi tükenmeden uygulamanın istenen yükü taşımasıdır.

AKS’te iyi otomatik ölçeklendirme, en düşük CPU yüzdesini hedeflemek değildir. Uygulamanın işleme süresi, bağımlı servisleri, node hazırlık gecikmesi ve maliyet sınırları ölçüldüğünde, az sayıda ama doğru ayarla öngörülebilir bir kapasite davranışı elde edilir.