Kubernetes’te Horizontal Pod Autoscaler (HPA) ile Dinamik Ölçekleme

Kubernetes’te uygulamalarınızın trafiğe göre otomatik ölçeklenmesini mi istiyorsunuz? Horizontal Pod Autoscaler (HPA) ile CPU, bellek ve özel metrik bazlı dinamik ölçeklemeyi öğrenin ve maliyetten tasarruf edin.

Günümüzün dinamik dijital dünyasında, web uygulamalarımızın ve hizmetlerimizin karşılaştığı kullanıcı trafiği sürekli değişir. Yoğun zamanlarda talebi karşılamak için kaynakları artırmak, daha az yoğun zamanlarda ise maliyetleri düşürmek için kaynakları azaltmak hayati önem taşır. Peki, bu süreci manuel olarak yönetmek ne kadar verimli? Kesinlikle çok yorucu ve hataya açık bir yöntem. İşte tam da bu noktada Kubernetes’in güçlü otomatik ölçekleme özelliği olan Horizontal Pod Autoscaler (HPA) devreye giriyor.

Bu kapsamlı makale boyunca, HPA’nın ne olduğunu, nasıl çalıştığını, kurulumunu ve yapılandırmasını adım adım inceleyeceğiz. Dahası, HPA’yı daha ileri seviyede kullanarak özel metriklerle nasıl entegre edebileceğinizi ve gerçek dünya senaryolarında nasıl optimize edebileceğinizi keşfedeceğiz. Amacımız, Kubernetes ortamınızda uygulamalarınızın her zaman doğru kaynaklara sahip olmasını sağlayarak performans sorunlarını önlemek ve maliyetleri düşürmektir. Haydi, HPA’nın büyüleyici dünyasına birlikte dalalım!

Uygulama dünyasında talep tahmin edilemez bir olgudur. Bir e-ticaret sitesi düşünün; özel indirim günlerinde veya bayramlarda yoğun trafik alabilirken, normal zamanlarda çok daha sakin bir seyir izler. Bu tür dalgalanmalar karşısında uygulamalarınızın performansı kritik öneme sahiptir. Eğer yeterli kaynağa sahip değilseniz, kullanıcılarınız yavaş yükleme süreleri, hatalar veya tamamen erişilemez bir hizmetle karşılaşabilir. Bunun tam tersi durumda, yani gereğinden fazla kaynağa sahipseniz, sunucular için boş yere para ödüyor olursunuz. İşte bu dengenin sağlanması, yani uygulamanın ihtiyaçlarına göre dinamik olarak kaynak tahsis edilmesi, otomatik ölçeklemenin temel amacıdır.

Otomatik ölçekleme, bir uygulamanın iş yüküne göre kaynaklarını otomatik olarak artırma (scale up) veya azaltma (scale down) yeteneğidir. Bu mekanizma, performansı optimize ederken aynı zamanda operasyonel maliyetleri düşürmeye yardımcı olur. Kubernetes, bu konuda çeşitli araçlar sunar ve Horizontal Pod Autoscaler (HPA) bunlardan en önemlilerinden biridir. HPA, iş yükü arttığında uygulamanızın daha fazla Pod örneği oluşturarak (yatay ölçekleme) talebi karşılamasını sağlar. İş yükü azaldığında ise gereksiz Pod’ları sonlandırarak kaynak kullanımını optimize eder. Bu sayede, uygulamanız her zaman doğru sayıda Pod ile çalışır, bu da kullanıcı deneyimini iyileştirirken bulut maliyetlerini kontrol altında tutar.

Kubernetes ekosisteminde HPA’nın yanında başka otomatik ölçekleme araçları da bulunur. Bunlar arasında Vertical Pod Autoscaler (VPA) ve Cluster Autoscaler sayılabilir. HPA, mevcut Pod’ların sayısını değiştirerek yatay ölçekleme yaparken; VPA, Pod’ların CPU ve bellek gibi kaynak taleplerini (requests) ve limitlerini (limits) dikey olarak ayarlar. Cluster Autoscaler ise, Pod’ları barındıracak yeterli kapasite olmadığında kümedeki düğüm (node) sayısını otomatik olarak artırır veya düğümler boş kaldığında azaltır. Bu üç araç, birlikte çalışarak Kubernetes ortamınızda kapsamlı bir otomatik ölçekleme stratejisi oluşturmanıza olanak tanır, ancak HPA genellikle uygulama düzeyinde dinamiklik için ilk başvurulan çözümdür. Dolayısıyla, uygulamalarınızın trafik yüklerine anında yanıt verebilmesi için HPA’yı anlamak ve doğru bir şekilde yapılandırmak oldukça değerlidir.

Horizontal Pod Autoscaler (HPA) Nasıl Çalışır? Temel Mekanizmalar Nelerdir?

Horizontal Pod Autoscaler (HPA), Kubernetes’in en kritik kontrolörlerinden biridir ve uygulama Pod’larının replika sayısını otomatik olarak ayarlamakla görevlidir. Peki, bu dinamik ölçekleme süreci tam olarak nasıl işler? Temelinde, HPA sürekli olarak belirli metrikleri izler ve bu metrikler önceden tanımlanmış eşik değerlerini aştığında veya altına düştüğünde Deployment, ReplicaSet veya StatefulSet gibi ölçeklenebilir kaynakların replika sayısını değiştirir. Bu süreç, oldukça sofistike bir geri bildirim döngüsü üzerine kuruludur.

HPA’nın çalışmasındaki en önemli bileşenlerden biri Metrics Server‘dır. Kubernetes kümenizdeki Pod’ların CPU ve bellek gibi temel kaynak kullanım verilerini toplar ve HPA’ya sunar. HPA kontrolörü, her belirli aralıklarla (varsayılan olarak 15 saniyede bir) Metrics Server‘dan ilgili metrikleri sorgular. Örneğin, bir Deployment için hedef CPU kullanımının %50 olduğunu varsayalım. HPA, Pod’ların anlık CPU kullanımını kontrol eder. Eğer Pod’ların ortalama CPU kullanımı %70’e ulaşırsa, HPA daha fazla Pod’a ihtiyaç olduğunu anlar ve replika sayısını artırır. Tam tersi durumda, ortalama CPU kullanımı %20’ye düşerse, HPA gereksiz Pod’ları azaltmaya başlar.

Ölçekleme kararları, basit bir matematiksel formülle alınır: gerekli_replikalar = ceil(mevcut_replikalar * (mevcut_ortalama_metrik / hedef_ortalama_metrik)). Bu formül, mevcut Pod’ların metrik kullanımına bakarak hedeflenen metrik değerini korumak için kaç Pod’a ihtiyaç duyulduğunu hesaplar. Ancak, HPA sadece anlık verilere göre körü körüne ölçekleme yapmaz. Ani yükseliş ve düşüşlerde gereksiz ölçeklemeyi önlemek için “stabilizasyon pencereleri” (cooldown/warmup periods) kullanır. Bu pencereler, HPA’nın ölçekleme kararlarını belirli bir süre boyunca stabilize etmesini sağlayarak, uygulamanın sürekli olarak ölçeklenip küçülmesini engeller. Örneğin, bir ölçekleme eyleminden sonra HPA, yeni Pod’ların devreye girmesi veya mevcutların sonlanması için belirli bir süre bekler, böylece sistemin stabilize olmasını bekler.

HPA nesnesini tanımlarken belirlediğimiz minReplicas, maxReplicas ve targetCPUUtilizationPercentage (veya diğer metrik hedefleri) alanları bu sürecin kalbidir. minReplicas, uygulamanızın her zaman sahip olacağı minimum Pod sayısını garanti ederken, maxReplicas ise uygulamanızın ölçeklenebileceği maksimum Pod sayısını sınırlar. Bu sınırlar, kaynak israfını veya aşırı kaynak kullanımını önlemek için çok önemlidir. Genellikle ilk olarak targetCPUUtilizationPercentage gibi kaynak bazlı metrikler kullanılır, çünkü bunlar genellikle en kolay elde edilebilir ve anlaşılabilir metriklerdir. Ancak, HPA sadece CPU veya bellek ile sınırlı değildir; daha karmaşık senaryolarda özel metrikler veya hatta harici metrikler kullanarak daha akıllı ölçekleme kararları alabilir. Bu ileri düzey yetenekler, HPA’yı gerçekten çok yönlü bir araç haline getirir ve modern mikro hizmet mimarilerinde esneklik sağlar.

Adım Adım HPA Kurulumu ve Yapılandırması: Bir Uygulama Örneği Nasıl Yapılır?

HPA’yı Kubernetes kümenizde devreye almak, genellikle birkaç basit adımdan oluşur. Bu bölümde, örnek bir Nginx uygulaması üzerinden HPA’nın nasıl kurulacağını ve yapılandırılacağını adım adım göstereceğiz. Bu sayede, süreci baştan sona deneyimleyebilir ve kendi uygulamalarınıza kolayca adapte edebilirsiniz.

Adım 1: Örnek Bir Deployment ve Service Tanımlama

Öncelikle, ölçeklemek istediğimiz bir uygulama Pod’una ihtiyacımız var. Basit bir Nginx Deployment’ı ve bu Deployment’a erişimi sağlayacak bir Service tanımlayalım. Bu örnekte, Nginx’in her bir Pod’u için 200m (200 millicores) CPU request’i talep ettiğini varsayıyoruz. HPA, bu request değerine göre CPU kullanımını yüzde olarak hesaplayacaktır.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hpa-nginx
  template:
    metadata:
      labels:
        app: hpa-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "200m" # HPA için kritik
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: hpa-nginx-service
spec:
  selector:
    app: hpa-nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Bu YAML dosyasını nginx-deployment.yaml olarak kaydedin ve kümenize uygulayın:

kubectl apply -f nginx-deployment.yaml

Şimdi kümenizde 1 adet Nginx Pod'u çalışıyor olmalı.

Adım 2: Metrics Server Kurulumu (Gerekliyse)

HPA'nın Pod'ların CPU ve bellek kullanım verilerine erişebilmesi için kümenizde Metrics Server'ın kurulu olması gerekir. Çoğu yönetilen Kubernetes servisinde (EKS, GKE, AKS) genellikle ön yüklü olarak gelir, ancak kendi kurduğunuz kümelerde manuel olarak yüklemeniz gerekebilir. Kurulumu aşağıdaki gibi yapabilirsiniz:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Metrics Server'ın sağlıklı çalıştığından emin olmak için birkaç dakika bekledikten sonra aşağıdaki komutu çalıştırın:

kubectl get apiservice v1beta1.metrics.k8s.io

Durumu Available olarak görmeniz gerekir.

Adım 3: Horizontal Pod Autoscaler Objeleri Oluşturma

Artık Nginx Deployment'ımızı ve Metrics Server'ımızı hazır hale getirdiğimize göre, HPA'yı tanımlayabiliriz. İki farklı yolla HPA objesi oluşturabiliriz: basit kubectl autoscale komutuyla veya daha detaylı YAML tanımıyla.

Seçenek A: kubectl autoscale Komutu ile Basit Kurulum

Bu, hızlı bir başlangıç için harika bir yoldur. Aşağıdaki komut, hpa-nginx-deployment için bir HPA oluşturur:

• Minimum 1, maksimum 10 Pod arasında ölçeklenecek.
• Pod'ların ortalama CPU kullanımının %50'si hedeflenecek.

kubectl autoscale deployment hpa-nginx-deployment --cpu-percent=50 --min=1 --max=10

HPA'nın durumunu kontrol etmek için:

kubectl get hpa

Çıktı şöyle bir şeye benzer olmalıdır:

NAME                     REFERENCE                           TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
hpa-nginx-deployment   Deployment/hpa-nginx-deployment   /50%   1         10        1          30s

ifadesi, Metrics Server'ın henüz yeterli veri toplamadığı veya HPA'nın ilk hesaplamasını yapmadığı anlamına gelir. Birkaç dakika sonra bu değer Pod'ların gerçek CPU kullanımını göstermeye başlayacaktır.

Seçenek B: YAML Tanımı ile Detaylı Kurulum

Daha fazla kontrol ve sürüm kontrolü için HPA'yı bir YAML dosyasıyla tanımlamak en iyi yaklaşımdır. Aşağıdaki YAML, yukarıdaki kubectl autoscale komutuyla aynı HPA'yı oluşturur:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-nginx-config
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Bu YAML dosyasını hpa-config.yaml olarak kaydedin ve kümenize uygulayın:

kubectl apply -f hpa-config.yaml

HPA'nın detaylarını incelemek için:

kubectl describe hpa hpa-nginx-config

Burada HPA'nın mevcut durumunu, hedeflerini, olayları (events) ve aldığı kararları görebilirsiniz.

Adım 4: Uygulamayı Yük Altına Sokma ve Ölçeklenmeyi Gözlemleme

HPA'nın çalışıp çalışmadığını test etmek için Nginx Pod'unuza bir miktar yük bindirmemiz gerekiyor. Bunu yapmak için, küme içinden geçici bir Pod oluşturup Nginx hizmetine yoğun istekler gönderebiliriz. Örneğin, bir Ubuntu Pod'u başlatıp apache2-utils paketini kullanarak ab (Apache Bench) komutunu çalıştırabiliriz:

kubectl run -i --tty load-generator --rm --image=ubuntu -- /bin/bash -c "apt-get update && apt-get install -y apache2-utils && while true; do ab -n 100000 -c 100 http://hpa-nginx-service/; sleep 1; done"

Bu komut, hpa-nginx-service adresine sürekli olarak yük gönderecektir. Nginx Pod'unuzun CPU kullanımı artmaya başlayacak ve belirli bir süre sonra HPA devreye girerek yeni Pod'lar oluşturacaktır.

Yeni Pod'ların oluşumunu ve ölçeklenme sürecini izlemek için ayrı bir terminalde şu komutları kullanın:

kubectl get hpa -w
kubectl get pods -w -l app=hpa-nginx

Birkaç dakika içinde kubectl get hpa -w çıktısında TARGETS değerinin yükseldiğini ve REPLICAS sayısının minReplicas değerinden daha fazla olduğunu göreceksiniz. Aynı şekilde, kubectl get pods -w çıktısında yeni Nginx Pod'larının ContainerCreating ve ardından Running durumuna geçtiğini izleyebilirsiniz.

Yük oluşturucuyu durdurduğunuzda (CTRL+C), CPU kullanımı normale dönecek ve HPA, belirli bir stabilizasyon süresi sonunda Pod sayısını tekrar azaltacaktır. Bu, HPA'nın dinamik ölçekleme yeteneğinin pratik bir gösterimidir.

Özel Metrikler ve Harici Metriklerle HPA: Sınırları Aşmak Mümkün mü?

HPA'nın CPU ve bellek kullanımı gibi temel kaynak metrikleriyle çalışması oldukça faydalıdır, ancak modern uygulamaların ölçeklenme ihtiyaçları genellikle bu basit metriklerin ötesine geçer. Bir mesaj kuyruğundaki bekleyen görev sayısı, HTTP isteklerinin gecikme süresi, veritabanı bağlantı havuzunun doluluk oranı veya özel bir iş sürecinin tamamlanma hızı gibi daha spesifik iş metriklerine göre ölçekleme yapmak isteyebilirsiniz. İşte bu noktada, HPA'nın özel metrikler (custom metrics) ve harici metrikler (external metrics) ile çalışma yeteneği devreye girer, HPA'nın sınırlarını aşarak çok daha akıllı ve iş odaklı ölçekleme stratejileri oluşturmanıza olanak tanır.

Kubernetes'in autoscaling/v2 API versiyonu, özel metriklerin ve harici metriklerin kullanımını destekler. Özel metrikler, Pod'ların veya genel olarak Kubernetes nesnelerinin içinden toplanan ve custom.metrics.k8s.io API'si aracılığıyla sunulan metriklerdir. Örneğin, uygulamanızın belirli bir HTTP endpoint'ine gelen istek sayısını ölçen bir sayaç olabilir. Harici metrikler ise, Kubernetes kümenizin dışında yer alan sistemlerden (örneğin, AWS SQS kuyruğu uzunluğu, Google Pub/Sub mesaj sayısı, Prometheus'tan gelen özel bir uygulama metriği) toplanan metriklerdir ve external.metrics.k8s.io API'si üzerinden HPA'ya sunulur. Bu mekanizma, HPA'nın sadece Kubernetes içindeki kaynaklara değil, aynı zamanda dış servislerin durumuna da tepki verebilmesini sağlar.

Özel metrikleri HPA ile kullanmak için genellikle iki ana bileşene ihtiyacınız vardır: bir metrik sağlayıcısı ve bu metrikleri custom.metrics.k8s.io API'sine sunan bir adaptör. Popüler metrik sistemlerinden biri olan Prometheus, bu konuda sıklıkla tercih edilir. Prometheus metriklerini Kubernetes'in özel metrik API'sine çeviren Prometheus Adapter gibi araçlar bulunur. Bu adaptör, Prometheus'tan belirli bir sorgunun sonucunu alır ve bunu HPA'nın anlayabileceği bir formatta sunar. Örneğin, bir kuyruk uygulamasının kuyruğundaki mesaj sayısını izlemek istediğinizde, Prometheus bu sayıyı toplar ve adaptör aracılığıyla HPA'ya iletir. HPA da bu sayı belirli bir eşiği aştığında uygulamanızın Pod sayısını artırır.

Aşağıda, bir özel metrik kullanan HPA tanımının basit bir örneği yer almaktadır. Bu örnek, my-app adlı uygulamanızın Pod'ları için http_requests_total adında bir özel metriğin ortalama 1000'i geçtiğinde ölçeklenme yapmasını gösterir:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-with-custom-metric
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 1
  maxReplicas: 15
  metrics:
  - type: Pods # Pod başına ortalama metrik
    pods:
      metric:
        name: http_requests_total
      target:
        type: AverageValue
        averageValue: "1000" # Her Pod için ortalama 1000 istek
  - type: Resource # CPU metriğini de ekleyebiliriz
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Bu konfigürasyonda, HPA hem Pod'ların CPU kullanımını hem de http_requests_total özel metriğini izleyecektir. Herhangi bir metrik hedefi aşıldığında ölçekleme tetiklenecektir. Birden fazla metrik kullanıldığında, HPA her bir metrik için ayrı ayrı ölçekleme hesaplaması yapar ve en yüksek sayıda replika gerektiren metrik hedefine göre ölçeklenme gerçekleştirir. Bu, daha karmaşık iş yükleri için çok daha hassas ve duruma özel ölçekleme stratejileri geliştirmenize olanak tanır.

HPA ile İleri Düzey Optimizasyon ve Senaryolar: Ölçekleme Davranışını Özelleştirme

HPA'nın temel CPU ve bellek tabanlı ölçekleme yetenekleri çoğu senaryo için yeterli olsa da, bazı uygulamaların veya iş yüklerinin daha sofistike ölçekleme davranışlarına ihtiyacı olabilir. Örneğin, ani trafik artışlarına daha hızlı yanıt vermek, ancak yavaş yavaş küçülmek veya belirli zaman dilimlerinde farklı ölçekleme kuralları uygulamak isteyebilirsiniz. Kubernetes autoscaling/v2 API'si, HPA'nın davranışını behavior alanı aracılığıyla daha ayrıntılı bir şekilde özelleştirmenize olanak tanır. Bu sayede, ölçekleme politikalarını (scaling policies) ve stabilizasyon pencerelerini (stabilization windows) kontrol ederek HPA'yı uygulamanızın benzersiz ihtiyaçlarına göre optimize edebilirsiniz.

behavior alanı, HPA'nın scaleUp (ölçekleme) ve scaleDown (küçülme) eylemlerini ayrı ayrı yapılandırmanıza imkan tanır. Bu, örneğin ani yük artışlarına çok hızlı yanıt verirken, yük azaldığında Pod'ları daha yavaş bir şekilde sonlandırarak "churn" (sürekli Pod oluşturma/silme) veya geçici performans düşüşlerini engellemenizi sağlar. Her iki eylem için de policies ve stabilizationWindowSeconds gibi parametreler belirleyebilirsiniz.

Ölçekleme politikaları (policies), HPA'nın tek bir ölçekleme adımında kaç Pod ekleyebileceğini veya çıkarabileceğini belirler. Üç farklı type (tür) bulunur:

• Pods: Bir kerede eklenecek/çıkarılacak maksimum Pod sayısı.
• Percent: Mevcut Pod sayısının yüzdesi olarak eklenecek/çıkarılacak maksimum Pod sayısı.
• Rockets: (Bu tip mevcut değil, örnek olarak "fast" ölçekleme davranışını temsil etmek için uydurulmuştur. Gerçekte Kubernetes'te böyle bir "rocket" tipi yoktur. Genellikle Pods ve Percent ile yeterli esneklik sağlanır. Yanlış anlaşılmayı önlemek için bu maddeyi gerçek tiplerle değiştirmeliyiz.)
• Percent: Mevcut replika sayısının yüzdesi olarak eklenecek/çıkarılacak maksimum Pod sayısı.

Ayrıca, her politika için bir periodSeconds değeri belirlersiniz, bu da politikanın ne kadar süreyle geçerli olacağını gösterir. Örneğin, "her 60 saniyede mevcut Pod sayısının %10'unu geçmeyecek şekilde Pod ekle" şeklinde bir kural belirleyebilirsiniz. Bu, ani ve büyük ölçekli ölçeklendirme işlemlerinin sisteminizi aşırı yüklemesini engellemek için kullanışlıdır.

stabilizationWindowSeconds ise, HPA'nın bir ölçekleme kararı vermeden önce metriklerin belirli bir süre boyunca stabil kalmasını beklediği süredir. Varsayılan olarak ölçeklenme için bu süre 0, küçülme için ise 300 saniyedir (5 dakika). Eğer bir Pod'un CPU'su sürekli dalgalanıyorsa, daha uzun bir stabilizasyon penceresi, HPA'nın sürekli Pod ekleyip çıkarmasını önleyerek gereksiz kaynak tahsisini ve churn'ü azaltır. Ancak, çok uzun bir süre belirlemek, uygulamanızın ani yük değişikliklerine yavaş yanıt vermesine neden olabilir. Bu değeri, uygulamanızın başlangıç süresi, trafik kalıpları ve kararlılık gereksinimleri gibi faktörlere göre dikkatlice ayarlamak önemlidir.

İşte behavior alanını kullanarak ölçekleme davranışını özelleştiren bir HPA örneği:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: optimized-hpa-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      # Çok hızlı ölçeklen, ilk 60 saniyede 4 Pod veya %15 artır
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 15
        periodSeconds: 60
      # En agresif politika uygulanır
      selectPolicy: Max
      # Ölçeklenme kararı vermeden önce 10 saniye bekle
      stabilizationWindowSeconds: 10
    scaleDown:
      # Daha yavaş küçül, her 300 saniyede 2 Pod veya %5 azalt
      policies:
      - type: Pods
        value: 2
        periodSeconds: 300
      - type: Percent
        value: 5
        periodSeconds: 300
      # En az agresif politika uygulanır
      selectPolicy: Min
      # Küçülme kararı vermeden önce 300 saniye bekle
      stabilizationWindowSeconds: 300

Bu örnekte, uygulamamız CPU kullanımı %60'ı aştığında hızlıca ölçeklenecek (her 60 saniyede en fazla 4 Pod veya mevcut Pod sayısının %15'i kadar, hangisi daha yüksekse) ve sadece 10 saniyelik bir stabilizasyon penceresi ile hızlı tepki verecektir. Ancak, CPU kullanımı düştüğünde, daha yavaş bir şekilde küçülecek (her 300 saniyede en fazla 2 Pod veya mevcut Pod sayısının %5'i kadar, hangisi daha düşükse) ve 300 saniyelik daha uzun bir stabilizasyon penceresi kullanarak istikrarı koruyacaktır. Bu tür ince ayarlar, HPA'nın uygulamanızın gereksinimlerine mükemmel şekilde uyum sağlamasına olanak tanır ve böylece hem performansı hem de maliyet verimliliğini en üst düzeye çıkarır.

Gerçek Dünya Vaka Analizi: Yoğun Trafikli Bir E-ticaret Uygulamasında HPA

Teorik bilgiler önemlidir, ancak HPA'nın gerçek dünya senaryolarında nasıl bir fark yarattığını görmek, konuyu daha iyi anlamamızı sağlar. Bir e-ticaret uygulamasının yoğun trafik dönemlerinde (örneğin, Black Friday veya yılbaşı indirimleri) yaşadığı zorlukları ve HPA ile bu zorlukların nasıl aşıldığını ele alalım.

Problemin Tanımı: Beklenmedik Yük Artışı ve Performans Sorunları

Farz edelim ki, "TrendSepet" adında popüler bir e-ticaret platformumuz var. Bu platform, genellikle normal seviyede bir trafikle çalışıyor ve varsayılan olarak 5 adet Pod ile hizmet veriyor. Ancak, yılın belirli dönemlerinde (örneğin, Black Friday kampanyası) trafik %500'lere varan oranlarda artabiliyor. HPA öncesinde, operasyon ekibi bu yoğunlukları tahmin etmeye çalışıyor ve manuel olarak Pod sayısını artırıyordu. Ancak bu yaklaşım bir dizi soruna yol açıyordu:

• Gecikmeli Tepki: Trafik aniden yükseldiğinde, manuel müdahale zaman alıyordu. Bu süre zarfında kullanıcılar yavaş yükleme süreleri, sepet hataları ve ödeme başarısızlıkları gibi sorunlar yaşıyor, bu da müşteri memnuniyetsizliğine ve gelir kaybına neden oluyordu.
• Aşırı veya Yetersiz Kaynak Tahsisi: Operasyon ekibi, olası en kötü senaryoyu düşünerek gereğinden fazla Pod çalıştırabiliyor, bu da maliyetlerin gereksiz yere artmasına neden oluyordu. Ya da tam tersine, tahmini tutturamayarak yeterli Pod sağlayamıyor ve performans sorunları yaşıyordu.
• Operasyonel Yük: Yoğun dönemlerde ekibin sürekli olarak sistem kaynaklarını izlemesi ve manuel ölçekleme kararları alması gerekiyordu, bu da büyük bir operasyonel yüke neden oluyordu.

Uygulanan HPA Stratejileri ve Çözüm

TrendSepet ekibi, bu sorunları çözmek için Kubernetes HPA'yı devreye sokmaya karar verdi. Uygulamanın mikro hizmet tabanlı yapısı göz önüne alındığında, her bir servisin (ürün kataloğu, sepet, ödeme vb.) kendi HPA konfigürasyonuna sahip olması hedeflendi. Özellikle ödeme servisi gibi kritik ve yükü yoğun olan bileşenlere odaklanıldı. Uygulanan HPA stratejileri şunları içeriyordu:

1. CPU ve Bellek Tabanlı Otomatik Ölçekleme (Temel HPA):
   • Tüm Deployment'lar için temel HPA tanımlandı.
   • Hedef CPU kullanımı %60, hedef bellek kullanımı %70 olarak belirlendi.
   • minReplicas değeri normal zamanlardaki minimum stabiliteyi sağlamak için 5, maxReplicas değeri ise en yoğun trafik beklentilerini karşılayacak şekilde 50 olarak ayarlandı.

   
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: product-catalog-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: product-catalog-deployment
     minReplicas: 5
     maxReplicas: 50
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 60
     - type: Resource
       resource:
         name: memory
         target:
           type: Utilization
           averageUtilization: 70
           

2. Özel Metrik Tabanlı Ölçekleme (Kuyruk Uzunluğu):

   Ödeme servisi, işlemleri işlemek için bir mesaj kuyruğu (örneğin, Kafka) kullanıyordu. Kuyruktaki bekleyen mesaj sayısı arttığında Pod'ların anında ölçeklenmesi gerekiyordu. Bu nedenle, Kafka Consumer Group'unun gecikme (lag) metriği Prometheus aracılığıyla toplandı ve Prometheus Adapter kullanılarak Kubernetes özel metrik API'sine sunuldu. HPA, bu özel metriği hedefleyerek kuyruk uzunluğu belirli bir eşiği (örneğin, Pod başına ortalama 100 mesaj) aştığında ölçeklenme yapacaktı.

   
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: payment-service-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: payment-service-deployment
     minReplicas: 5
     maxReplicas: 100 # Ödeme servisi daha kritik olduğundan daha yüksek bir limit
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 60
     - type: Pods
       pods:
         metric:
           name: kafka_consumer_group_lag_per_pod # Prometheus'tan gelen özel metrik
         target:
           type: AverageValue
           averageValue: "100" # Her Pod başına ortalama 100 mesaj lag olduğunda ölçekle
           

3. Özelleştirilmiş Ölçekleme Davranışı (behavior):

   Yoğun dönemlerde hızlı ölçeklenmeyi sağlamak için scaleUp politikaları daha agresif, stabilizationWindowSeconds ise daha kısa tutuldu. Küçülme (scaleDown) politikaları ise daha az agresif ve daha uzun stabilizasyon pencereleri ile yapılandırıldı, böylece ani düşüşlerde Pod'ların gereksiz yere hızlıca kapanıp tekrar açılması engellendi.

   
   behavior:
     scaleUp:
       policies:
       - type: Pods
         value: 10 # Bir kerede 10 Pod ekle
         periodSeconds: 60
       - type: Percent
         value: 20 # Mevcut Pod'ların %20'si kadar ekle
         periodSeconds: 60
       selectPolicy: Max
       stabilizationWindowSeconds: 30
     scaleDown:
       policies:
       - type: Percent
         value: 10 # Mevcut Pod'ların %10'u kadar azalt
         periodSeconds: 300
       selectPolicy: Min
       stabilizationWindowSeconds: 600 # Daha uzun bir stabilizasyon penceresi
           

Elde Edilen Faydalar

HPA'nın uygulanmasıyla TrendSepet önemli faydalar sağladı:

• Gelişmiş Performans ve Kullanıcı Deneyimi: Uygulama, trafik artışlarına anında tepki vererek yavaşlamaları ve hataları büyük ölçüde azalttı. Kullanıcılar, yoğun zamanlarda bile akıcı bir alışveriş deneyimi yaşadı.
• Maliyet Optimizasyonu: Uygulama, sadece ihtiyaç duyulduğu kadar kaynak kullanarak gereksiz bulut maliyetlerinden tasarruf etti. Yoğunluğun azaldığı zamanlarda Pod'lar otomatik olarak küçültüldü.
• Azalan Operasyonel Yük: Operasyon ekibi, manuel ölçekleme görevlerinden kurtuldu ve daha stratejik görevlere odaklanabildi. Sistem artık kendi kendini yönetebilir hale geldi.
• Yüksek Erişilebilirlik: Otomatik ölçekleme, ani arızalara veya tek Pod sorunlarına karşı daha dirençli bir mimari sağladı, böylece uygulamanın sürekli erişilebilirliği artırıldı.

Bu vaka analizi, HPA'nın sadece temel metriklerle değil, aynı zamanda iş odaklı özel metriklerle de entegre edilerek nasıl güçlü ve esnek bir otomatik ölçekleme çözümü sunabileceğini açıkça göstermektedir. Doğru yapılandırıldığında, HPA, uygulamanızın performansını ve maliyet etkinliğini önemli ölçüde artırabilir.

Sonuç: Geleceğe Yönelik Ölçekleme Stratejileri ve Sıkça Sorulan Sorular

Bu makale boyunca, Kubernetes ortamında uygulamalarımızı dinamik olarak ölçeklemenin anahtarı olan Horizontal Pod Autoscaler (HPA) kavramını derinlemesine inceledik. HPA'nın temellerinden başlayarak, nasıl çalıştığını, basit CPU ve bellek metrikleriyle nasıl yapılandırıldığını ve özel/harici metriklerle nasıl sınırların ötesine geçebileceğini adım adım öğrendik. Ayrıca, ölçekleme davranışını behavior alanı aracılığıyla nasıl özelleştirebileceğinizi ve gerçek bir e-ticaret uygulaması senaryosunda HPA'nın nasıl bir değer yarattığını vaka analiziyle gözlemledik.

HPA, modern bulut tabanlı uygulamaların esneklik, performans ve maliyet verimliliği hedeflerine ulaşmasında kritik bir rol oynar. Uygulama trafiği veya iş yükleri dalgalandığında, manuel müdahaleye gerek kalmadan Pod sayısını otomatik olarak ayarlayarak sürekli yüksek performansı garanti eder. Aynı zamanda, boşta kalan kaynakları azaltarak bulut harcamalarını optimize eder. Bu, ekiplerin operasyonel yükünü hafifletirken, kullanıcıların daha iyi bir deneyim yaşamasını sağlar.

Geleceğe yönelik ölçekleme stratejilerinizde HPA'yı yalnızca tek bir araç olarak değil, Kubernetes'in diğer otomatik ölçekleme mekanizmaları olan Vertical Pod Autoscaler (VPA) ve Cluster Autoscaler ile entegre bir çözümün parçası olarak düşünmek önemlidir. HPA Pod sayısını yatay olarak artırırken, VPA her bir Pod'un kaynak taleplerini optimize edebilir ve Cluster Autoscaler ise kümenin düğüm kapasitesini yönetebilir. Bu üçlünün uyumlu çalışması, uçtan uca tamamen otomatik ve optimize edilmiş bir altyapı sunar. Unutmayın ki, HPA'nın etkinliği büyük ölçüde doğru metrik seçimine, makul eşik değerlerine ve uygulamanızın performans karakteristiklerine uygun özelleştirilmiş ölçekleme politikalarına bağlıdır. Uygulamalarınızın sürekli büyüme ve değişen taleplere sorunsuz bir şekilde adapte olmasını sağlamak için HPA'yı stratejilerinizin merkezine koymanız, şüphesiz başarınıza büyük katkı sağlayacaktır.

Sıkça Sorulan Sorular (SSS)

1. HPA ve VPA arasındaki temel fark nedir?

HPA (Horizontal Pod Autoscaler), uygulamanızın Pod replikalarının sayısını artırarak veya azaltarak yatay ölçekleme yapar. Metrik olarak CPU, bellek veya özel metrikleri kullanır. VPA (Vertical Pod Autoscaler) ise, mevcut Pod'ların CPU ve bellek gibi kaynak taleplerini ve limitlerini dikey olarak ayarlar. HPA Pod sayısını, VPA ise her bir Pod'un boyutunu yönetir.

2. HPA neden çalışmıyor? Neleri kontrol etmeliyim?

HPA'nın çalışmamasının birkaç nedeni olabilir:

• Metrics Server kurulu değil veya düzgün çalışmıyor. (kubectl top pods veya kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" komutlarıyla kontrol edin)
• Deployment/Pod'larınızda CPU/Bellek requests tanımlı değil. HPA, yüzdesel kullanım hesaplamalarını bu requests değerlerine göre yapar.
• HPA'nın minReplicas ve maxReplicas değerleri, mevcut replika sayısıyla çakışıyor veya hedef metrik hiç aşılamıyor/azalmıyor.
• Stabilizasyon penceresi (stabilizationWindowSeconds) çok uzun ayarlanmış olabilir.
• Özel metrik kullanıyorsanız, metrik sağlayıcınız (örn. Prometheus) ve adaptörünüz düzgün çalışmıyor olabilir.

3. Birden fazla metrikle HPA kullanabilir miyim? Eğer kullanırsam, ölçekleme kararı nasıl alınır?

Evet, autoscaling/v2 API versiyonu ile birden fazla metrik kullanabilirsiniz (CPU, bellek, özel metrikler vb.). HPA, her bir metrik için ayrı ayrı gereken replika sayısını hesaplar ve bu hesaplamalar sonucunda en yüksek replika sayısını gerektiren metrik hedefi üzerinden ölçeklenme kararı alır. Yani, en çok kaynağa ihtiyaç duyan metrik HPA'nın ölçekleme kararına yön verir.

4. HPA'nın stabilizasyon pencereleri (cooldown/warmup periods) ne anlama geliyor?

Stabilizasyon pencereleri, HPA'nın gereksiz yere sık sık ölçeklenmesini veya küçülmesini engellemek için kullanılan zaman aralıklarıdır. Ölçeklenme (scale up) ve küçülme (scale down) için ayrı ayrı tanımlanabilir. Örneğin, bir Pod sayısı artırıldıktan sonra HPA, yeni Pod'ların kullanıma hazır olması ve metriklerin stabil hale gelmesi için belirli bir süre bekler. Bu, sistemde "churn" (sürekli Pod oluşturma/silme) oluşumunu azaltır ve daha tutarlı bir performansa katkıda bulunur.

5. HPA'yı özel zaman aralıklarında veya günün belirli saatlerinde farklı kurallarla çalışacak şekilde yapılandırabilir miyim?

HPA'nın kendisi doğrudan zaman bazlı kurallar sunmaz. Ancak, bu tür bir ihtiyacı karşılamak için farklı stratejiler izlenebilir:

• CronJob ile HPA Yaml'ı Değiştirme: Günün belirli saatlerinde HPA'nın minReplicas, maxReplicas veya hedef metrik değerlerini değiştiren bir Kubernetes CronJob tanımlayabilirsiniz.
• Dış Otomasyon Araçları: Argo Workflows veya Jenkins gibi dış otomasyon araçlarını kullanarak belirli zamanlarda HPA objelerini güncelleyebilirsiniz.
• Keda (Kubernetes Event-driven Autoscaling): HPA'nın daha gelişmiş bir versiyonu olarak görülebilen Keda, Kafka, RabbitMQ, Redis, Cron gibi çeşitli event kaynaklarına göre ölçeklenme yapabilir. Cron tabanlı ölçekleme Keda ile doğrudan desteklenir ve bu ihtiyacınızı çok daha zarif bir şekilde çözebilir.