Kubernetes Üzerinde Mikroservisler İçin Hpa Nasıl Yapılandırılır?

Kubernetes Üzerinde Mikroservisler İçin HPA Nasıl Yapılandırılır?

Modern bulut yerel (cloud-native) mimarilerde, trafik dalgalanmalarına karşı uygulamanın sürekliliğini sağlamak kritik bir öneme sahiptir. Kubernetes üzerinde mikroservisler için HPA (Horizontal Pod Autoscaler) yapılandırmak, sistemin kaynak kullanımını gerçek zamanlı izleyerek, yük arttığında pod sayısını otomatik olarak artırmanızı ve yük azaldığında ise kaynak tasarrufu için bu sayıları düşürmenizi sağlar. 2026 yılı itibarıyla, mikroservis mimarilerinde verimliliği maksimize etmek için HPA, standart bir operasyonel gereklilik haline gelmiştir.

HPA, sadece bir kaynak yönetim aracı değil, aynı zamanda maliyet optimizasyonu ve yüksek erişilebilirlik sağlayan stratejik bir bileşendir. Doğru yapılandırılmamış bir HPA, "flapping" denilen hızlı ölçeklenme döngülerine veya yetersiz kaynak nedeniyle servis kesintilerine yol açabilir. Bu rehberde, Kubernetes kümenizdeki mikroservisler için en sağlıklı HPA kurulumunu, metrik seçimlerinden limit yönetimine kadar adım adım ele alacağız.

Kubernetes HPA Mimarisi ve Çalışma Prensipleri

HPA, Kubernetes kontrol düzleminde (control plane) yer alan bir denetleyicidir. Belirlenen periyotlarla (varsayılan olarak 15 saniye) hedef kaynağın metriklerini sorgular. Eğer gözlemlenen metrik, sizin belirlediğiniz hedef değerin üzerine çıkarsa, HPA, ReplicationController veya Deployment üzerindeki pod sayısını artırmak için bir ölçeklendirme isteği gönderir.

Metrik Sunucusu (Metrics Server) Gereksinimi

HPA'nın düzgün çalışabilmesi için kümenizde mutlaka bir Metrics Server kurulu olmalıdır. Metrics Server, kubelet'lerden kaynak kullanım verilerini toplayarak bunları Kubernetes API'sine sunar. Eğer kümenizde bu bileşen yoksa, HPA metrikleri okuyamaz ve ölçeklendirme işlemi gerçekleşmez. Kurulumun doğruluğunu kontrol etmek için kubectl top pods komutunu kullanarak, podların anlık CPU ve bellek tüketimlerini görüp görmediğinizi teyit etmelisiniz.

HPA Kontrol Döngüsü Nasıl İşler?

HPA, sadece mevcut durumu izlemez, aynı zamanda bir algoritma kullanarak ihtiyaç duyulan pod sayısını hesaplar. Hesaplama formülü temel olarak şöyledir: İstenen Pod Sayısı = ceil(Mevcut Pod Sayısı * (Mevcut Metrik Değeri / Hedef Metrik Değeri)). Bu formül, sistemin yükü karşılamak için ne kadar kapasiteye ihtiyaç duyduğunu matematiksel olarak belirler.

Kritik Uyarı: HPA yapılandırmadan önce, podlarınızın mutlaka resources.requests tanımlarının yapılmış olduğundan emin olun. HPA, kaynak kullanımını hesaplarken podun toplam kapasitesine değil, tanımlanmış olan "request" değerine göre oranlama yapar. Request değeri eksik olan podlar için HPA sağlıklı metrik hesaplayamaz.

Mikroservisler İçin HPA Yapılandırma Adımları

Mikroservislerinizi ölçeklendirmek için izlemeniz gereken yol, uygulamanızın karakteristiğine göre değişiklik gösterir. CPU tabanlı ölçeklendirme en yaygın yöntem olsa da, bellek veya özel metrikler bazen daha doğru sonuçlar verebilir.

1. Adım: Kaynak İsteklerini (Requests) Belirleyin

HPA yapılandırmasına başlamadan önce, her bir mikroservis için gerçekçi kaynak limitleri ve istekleri belirlemelisiniz. Mikroservisinizin normal yük altındaki CPU tüketimini analiz edin ve buna göre bir requests.cpu değeri atayın. Örneğin, 100m (0.1 çekirdek) olarak belirlenen bir istek, HPA'nın %50 hedef değerinde 50m CPU kullanıldığında ölçeklendirme yapmasını sağlar.

2. Adım: HPA Manifest Dosyasını Oluşturun

HPA, YAML dosyası üzerinden kolayca tanımlanabilir. Aşağıdaki örnek, bir Deployment'ı hedefleyen standart bir HPA tanımıdır:

• apiVersion: autoscaling/v2
• kind: HorizontalPodAutoscaler
• metadata: Mikroservis isminizle eşleşen bir isim.
• spec: Hedef deployment, minimum/maksimum pod sayısı ve metrik hedefleri.

3. Adım: Ölçeklendirme Stratejisini Test Edin

Yapılandırmayı uyguladıktan sonra, yük testi araçları kullanarak mikroservisinizi zorlayın. Sistemin belirlenen CPU eşiğine ulaştığında yeni podları oluşturup oluşturmadığını izleyin. kubectl get hpa komutu ile mevcut durumu ve hedef metrikleri anlık olarak takip edebilirsiniz.

CPU ve Bellek Tabanlı Ölçeklendirme Arasındaki Farklar

Mikroservisleriniz için hangi metriği seçeceğiniz, uygulamanın doğasına bağlıdır. CPU, işlemci yoğunluklu (hesaplama yapan) servisler için idealdir; bellek ise genellikle veri işleme veya önbellekleme yapan servisler için kritik bir göstergedir.

Gelişmiş Ölçeklendirme: Özel Metrikler ve KEDA

2026 yılı standartlarında, sadece CPU ve bellek ile ölçeklendirme yapmak bazen yetersiz kalabilir. Özellikle mesaj kuyrukları (RabbitMQ, Kafka) ile çalışan mikroservislerde, kuyruktaki mesaj sayısı arttığında ölçeklendirme yapmak çok daha verimlidir. Bu noktada KEDA (Kubernetes Event-driven Autoscaling) devreye girer.

Neden KEDA Tercih Edilmeli?

KEDA, standart HPA'nın yeteneklerini genişleterek, dış kaynaklardan gelen verilere göre ölçeklendirme yapmanıza olanak tanır. Örneğin, bir mikroservisiniz kuyruktan mesaj okuyorsa, kuyruk derinliği 100'ü geçtiğinde pod sayısını artıracak bir kural tanımlayabilirsiniz. Bu, geleneksel HPA ile doğrudan yapılandırılamayan bir senaryodur.

Özel Metrik API'si ile Entegrasyon

Eğer KEDA kullanmak istemiyorsanız, Prometheus gibi izleme araçlarını kullanarak "Custom Metrics API" üzerinden kendi metriklerinizi Kubernetes'e tanıtabilirsiniz. Bu yöntem, mikroservislerinizin iş mantığına özel (örneğin saniye başına başarılı işlem sayısı) metriklerle ölçeklenmesini sağlar.

HPA Yapılandırmasında Sık Yapılan Hatalar ve Çözümleri

HPA yapılandırırken yapılan hatalar, genellikle sistemin kararsız hale gelmesine veya kaynakların boşa harcanmasına neden olur. En sık karşılaşılan sorunları ve çözüm yollarını aşağıda bulabilirsiniz.

Yetersiz Kaynak Limitleri

Podlara resources.limits tanımlanmaması, bir mikroservisin tüm küme kaynaklarını tüketmesine neden olabilir. HPA, bu durumda yanlış metrikler alabilir. Her zaman requests ve limits tanımlarını dengeli bir şekilde yapın.

Agresif Ölçeklendirme Eşikleri

CPU eşiğini çok düşük (örneğin %20) tutmak, podların sürekli olarak oluşturulup silinmesine (flapping) neden olur. Bu durum, podların hazır hale gelme süresini (readiness probe) etkileyerek servisin kullanılabilirliğini düşürür. İdeal eşik genellikle %50 ile %70 arasındadır.

Readiness Probe İhmali

Ölçeklenen bir podun trafiği karşılayabilmesi için "hazır" olması gerekir. Eğer readinessProbe tanımlamazsanız, Kubernetes podu oluşturur oluşturmaz ona trafik göndermeye başlar. Bu da mikroservisiniz henüz ayağa kalkmadan gelen isteklerin başarısız olmasına (503 hatası) yol açar.

Uzman Tavsiyesi: Ölçeklendirme politikalarınızda behavior (davranış) ayarlarını kullanarak, ölçek küçültme (scale-down) işlemlerini bir süre geciktirebilirsiniz. Bu, anlık trafik düşüşlerinde podlarınızın gereksiz yere silinmesini engeller ve sistemin kararlılığını artırır.

Sıkça Sorulan Sorular

HPA neden pod sayısını artırmıyor?

Öncelikle Metrics Server'ın çalıştığından ve podlarınızın requests tanımlarının yapıldığından emin olun. Ayrıca, kubectl describe hpa [isim] komutunu kullanarak hata mesajlarını ve metriklerin alınıp alınmadığını kontrol edin.

Minimum ve maksimum pod sayısı nasıl belirlenir?

Minimum pod sayısı, yüksek erişilebilirlik (HA) için en az 2 olmalıdır. Maksimum pod sayısı ise kümenizin toplam kapasitesi ve mikroservisinizin tek başına tükettiği maksimum kaynak miktarı göz önüne alınarak, kümenin çökmesini engelleyecek bir sınırda tutulmalıdır.

HPA ve VPA birlikte kullanılabilir mi?

Evet, ancak dikkatli olunmalıdır. HPA pod sayısını, VPA ise podun kaynak limitlerini (CPU/RAM) değiştirir. İkisini aynı metrik için (örneğin CPU) kullanmak çakışmalara yol açar. Genellikle HPA pod ölçeklendirmesi için, VPA ise kaynak optimizasyonu için ayrı ayrı yapılandırılmalıdır.

HPA'nın ölçeklendirme hızını nasıl ayarlarım?

Kubernetes v2 API ile gelen behavior bloğu sayesinde, ölçeklendirme için geçen süreyi ve stabilizasyon penceresini (stabilizationWindowSeconds) özelleştirebilirsiniz. Bu, ani trafik artışlarında daha hızlı tepki vermenizi sağlar.

Ölçeklendirme için özel metrikleri nasıl kullanırım?

Özel metrikler için Prometheus Adapter gibi bir ara katman kullanarak, Prometheus'ta tutulan metriklerin Kubernetes API'sine "Custom Metrics" olarak yansıtılmasını sağlamanız gerekir. Ardından HPA konfigürasyonunda type: Pods veya type: Object kullanarak bu metrikleri referans gösterebilirsiniz.

Sonuç

Kubernetes üzerinde mikroservisler için HPA yapılandırmak, sisteminizin dayanıklılığını ve verimliliğini artıran temel bir adımdır. Başarılı bir yapılandırma için Metrics Server kurulumundan, doğru kaynak limitlerinin belirlenmesine ve ölçeklendirme davranışlarının optimize edilmesine kadar tüm süreçlerin titizlikle yönetilmesi gerekir. 2026 yılı standartlarında, sadece CPU/RAM odaklı değil, uygulamanızın ihtiyaçlarına göre özelleştirilmiş metrikler ve KEDA gibi modern araçlarla desteklenen bir ölçeklendirme stratejisi, mikroservis mimarinizin başarısını doğrudan etkileyecektir.

Unutmayın ki, HPA bir "kur ve unut" aracı değildir. Uygulamanızın trafik desenleri değiştikçe, belirlediğiniz eşikleri ve limitleri düzenli olarak gözden geçirmeniz ve performans testleri ile doğrulamanız gerekir. Bu rehberde paylaşılan adımları takip ederek, daha ölçeklenebilir ve kararlı bir Kubernetes ortamı oluşturabilir, operasyonel yükünüzü minimize edebilirsiniz.

Kubernetes Üzerinde Mikroservisler İçin HPA Nasıl Yapılandırılır?

Mikroservis mimarilerinde trafik yükünün tahmin edilemez olması, sistemlerin ayakta kalması için dinamik bir ölçeklendirme mekanizmasını zorunlu kılar. Kubernetes Horizontal Pod Autoscaler (HPA), bu noktada devreye girerek pod sayısını gerçek zamanlı metrikler üzerinden otomatik olarak ayarlar. Ancak HPA'yı sadece bir manifest dosyası olarak görmek, sistemin kararsızlaşmasına neden olabilir.

Kubernetes HPA Mimarisi ve Çalışma Prensipleri

HPA, Kubernetes kontrol düzleminde bir denetleyici döngüsü (control loop) olarak çalışır. Temel amacı, tanımlanan hedef metrikler ile mevcut podların durumunu sürekli kıyaslamaktır. Bu mimari, HorizontalPodAutoscaler nesnesi üzerinden yönetilir ve kube-controller-manager tarafından periyodik olarak sorgulanır.

Metrik Sunucusu (Metrics Server) Gereksinimi

HPA'nın çalışması için küme içerisinde Metrics Server'ın kurulu olması şarttır. Metrics Server, kubelet'ten gelen kaynak kullanım verilerini toplar ve bunları Kubernetes API'sine sunar. Eğer Metrics Server yüklü değilse, HPA metrikleri okuyamaz ve ölçeklendirme tetiklenemez.

HPA Kontrol Döngüsü Nasıl İşler?

HPA döngüsü şu adımlarla ilerler:

• Veri Toplama: Metrics Server üzerinden CPU veya bellek kullanımı sorgulanır.
• Hesaplama: Mevcut kullanım ile hedef kullanım (target utilization) oranlanır.
• Karar Verme: Yeni pod sayısı, ceil(currentReplicas * (currentMetricValue / desiredMetricValue)) formülü ile hesaplanır.
• Uygulama: Deployment veya ReplicaSet nesnesinin replicas değeri güncellenir.

Mikroservisler İçin HPA Yapılandırma Adımları

1. Adım: Kaynak İsteklerini (Requests) Belirleyin

HPA, "requests" değerini baz alarak yüzde hesabı yapar. Eğer bir pod için resources.requests.cpu tanımlanmamışsa, HPA hesaplama yapamaz. Bu nedenle her mikroservis için gerçekçi CPU ve bellek istekleri tanımlanmalıdır.

2. Adım: HPA Manifest Dosyasını Oluşturun

Aşağıdaki örnek, CPU kullanımı %50'yi geçtiğinde ölçeklenen bir HPA konfigürasyonunu göstermektedir:

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

3. Adım: Ölçeklendirme Stratejisini Test Edin

Yük test araçları (k6, Locust veya Apache JMeter) kullanarak servislerinize trafik gönderin ve kubectl get hpa -w komutu ile ölçeklenme sürecini canlı izleyin.

CPU ve Bellek Tabanlı Ölçeklendirme Arasındaki Farklar

Gelişmiş Ölçeklendirme: Özel Metrikler ve KEDA

Standart CPU/RAM metrikleri bazen yetersiz kalır. Örneğin, bir mesaj kuyruğundaki (RabbitMQ, Kafka) mesaj sayısına göre ölçekleme yapmak istiyorsanız, KEDA (Kubernetes Event-driven Autoscaling) kullanmalısınız.

Neden KEDA Tercih Edilmeli?

KEDA, HPA'nın üzerine inşa edilmiş bir operatördür. 50'den fazla dış kaynağı (AWS SQS, Azure Service Bus, Redis, Prometheus) destekler ve "sıfıra ölçekleme" (scale-to-zero) yeteneği sunar.

HPA Yapılandırmasında Sık Yapılan Hatalar ve Çözümleri

Yetersiz Kaynak Limitleri

Eğer resources.limits değerleri çok düşük tutulursa, podlar CPU throttled (kısıtlama) durumuna düşer. HPA pod sayısını artırsa bile, mevcut podlar kısıtlandığı için performans artışı yaşanmaz.

Agresif Ölçeklendirme Eşikleri

Hedef kullanımı çok düşük (örneğin %20) tutmak, "flapping" denilen sürekli ölçekleme döngüsüne (sürekli yeni pod aç-kapa) neden olur. İdeal eşik genellikle %60-%80 arasındadır.

Readiness Probe İhmali

Yeni açılan podların trafiği karşılamaya hazır olup olmadığını belirleyen readinessProbe tanımlanmazsa, HPA podu hazır sanıp trafiği yönlendirir ancak pod henüz başlamamıştır. Bu durum kesintilere yol açar.

Güvenlik ve Operasyonel İpuçları

HPA yapılandırırken güvenliği göz ardı etmeyin. Özellikle "Custom Metrics" kullanırken, Metrics API'sine erişim yetkilerini (RBAC) kısıtlayın. Ayrıca, ölçeklendirme sırasında podların birbirini etkilememesi için PodDisruptionBudget (PDB) nesnelerini kullanarak minimum kullanılabilirlik oranlarını garanti altına alın.

Örnek Senaryo: Yüksek Trafikli Bir API

Bir e-ticaret uygulamasında kampanya dönemlerinde trafik 10 katına çıkabilir. Bu durumda sadece CPU'ya güvenmek yerine, HPA Behavior ayarlarını kullanarak ölçeklendirme hızını (scale-up velocity) artırmanız önerilir. stabilizationWindowSeconds parametresini düşürerek sistemin trafiğe daha hızlı yanıt vermesini sağlayabilirsiniz.

Sıkça Sorulan Sorular

HPA neden pod sayısını artırmıyor?

Genellikle Metrics Server'ın veriyi çekememesi veya podlarda resources.requests değerinin tanımlanmamış olmasından kaynaklanır. kubectl describe hpa [isim] komutu ile "Conditions" kısmındaki hataları kontrol edin.

Minimum ve maksimum pod sayısı nasıl belirlenir?

Minimum sayı, uygulamanın yüksek erişilebilirlik (HA) için ihtiyaç duyduğu en az pod sayısı olmalıdır (genellikle 2). Maksimum sayı ise kümenizin toplam kapasitesi ve bütçe kısıtlamalarına göre belirlenmelidir.

HPA ve VPA birlikte kullanılabilir mi?

Aynı metrik (CPU/RAM) üzerinden hem HPA hem de VPA kullanmak çakışmaya neden olur. Ancak, VPA'yı sadece "recommendation" modunda kullanarak kaynak limitlerini optimize edebilir, HPA'yı ise ölçeklendirme için kullanabilirsiniz.

HPA'nın ölçeklendirme hızını nasıl ayarlarım?

Kubernetes v1.18+ ile gelen behavior alanı sayesinde scaleUp ve scaleDown stratejilerini saniye bazında özelleştirebilir, ani artışlarda hızlı, düşüşlerde ise daha temkinli davranmasını sağlayabilirsiniz.

Ölçeklendirme için özel metrikleri nasıl kullanırım?

Özel metrikler için Prometheus Adapter kullanarak, Prometheus'ta tutulan metriklerin Kubernetes API'sine "Custom Metrics" olarak yansıtılmasını sağlamanız gerekir. Ardından HPA konfigürasyonunda type: Pods veya type: Object kullanarak bu metrikleri referans gösterebilirsiniz.

Kubernetes Üzerinde Mikroservisler İçin HPA Nasıl Yapılandırılır?

Modern mikroservis mimarilerinde, uygulamanın trafik dalgalanmalarına karşı esnek olması, sistemin sürekliliği için hayati önem taşır. Kubernetes Horizontal Pod Autoscaler (HPA), bu ihtiyacı karşılayan temel mekanizmadır. Ancak, HPA'yı sadece bir manifest dosyası olarak görmek, potansiyel performans sorunlarını göz ardı etmek demektir.

Kubernetes HPA Mimarisi ve Çalışma Prensipleri

HPA, Kubernetes kontrol düzleminde bir "kontrol döngüsü" (control loop) olarak çalışır. Belirli aralıklarla (varsayılan olarak 15 saniye) podların kaynak tüketimini izler ve hedef değerlere ulaşıp ulaşmadığını kontrol eder. Mimari, API sunucusu ile Metrics Server arasındaki sürekli bir veri alışverişine dayanır.

Metrik Sunucusu (Metrics Server) Gereksinimi

Metrics Server, küme genelindeki kaynak kullanım verilerini toplayan ve bunları Kubernetes API'sine sunan bir bileşendir. Eğer kümenizde Metrics Server kurulu değilse, kubectl top komutu çalışmayacak ve HPA "unknown" durumunda kalacaktır.

HPA Kontrol Döngüsü Nasıl İşler?

Döngü şu adımları izler: Ölçüm, Karşılaştırma, Hesaplama ve Uygulama. HPA, mevcut pod sayısını şu formülle hesaplar: İstenen Pod Sayısı = ceil(Mevcut Pod Sayısı * (Mevcut Metrik Değeri / İstenen Metrik Değeri)).

Mikroservisler İçin HPA Yapılandırma Adımları

1. Adım: Kaynak İsteklerini (Requests) Belirleyin

HPA'nın sağlıklı çalışması için podların resources.requests değerlerinin net bir şekilde tanımlanmış olması gerekir. Eğer "request" tanımlanmazsa, HPA yüzdesel hesaplama yapamaz.

2. Adım: HPA Manifest Dosyasını Oluşturun

Manifest dosyasında minReplicas, maxReplicas ve targetCPUUtilizationPercentage gibi kritik parametreler yer almalıdır. YAML yapısı, ölçeklenecek olan Deployment veya StatefulSet'i referans göstermelidir.

3. Adım: Ölçeklendirme Stratejisini Test Edin

Yük test araçları (k6, Locust veya JMeter) kullanarak uygulamanızı stres testine sokun. HPA'nın pod sayısını artırıp artırmadığını kubectl get hpa -w komutu ile canlı izleyin.

CPU ve Bellek Tabanlı Ölçeklendirme Arasındaki Farklar

Gelişmiş Ölçeklendirme: Özel Metrikler ve KEDA

Standart CPU ve RAM metrikleri her zaman iş ihtiyaçlarını karşılamaz. Örneğin, bir mesaj kuyruğundaki (RabbitMQ veya Kafka) mesaj sayısı arttığında ölçeklenmek isteyebilirsiniz. İşte bu noktada KEDA (Kubernetes Event-driven Autoscaling) devreye girer.

Neden KEDA Tercih Edilmeli?

KEDA, 50'den fazla dış kaynağı (Event Source) destekler. HPA'nın sınırlı metrik setini genişleterek, uygulamanın "olay tabanlı" (event-driven) ölçeklenmesini sağlar.

HPA Yapılandırmasında Sık Yapılan Hatalar ve Çözümleri

Yetersiz Kaynak Limitleri

Podlara çok düşük CPU limitleri atamak, uygulamanın "throttling" yaşamasına neden olur. Bu durum, HPA'nın yanlış metrikler okumasına ve gereksiz yere sürekli ölçeklenmesine (flapping) yol açar.

Agresif Ölçeklendirme Eşikleri

Ölçeklendirme eşiğini %50 gibi çok düşük bir değerde tutmak, sistemin sürekli pod ekleyip çıkarmasına neden olur. İdeal olan, %60-%80 aralığında bir hedef belirlemektir.

Readiness Probe İhmali

Yeni oluşturulan podların trafiği karşılamaya hazır olup olmadığını anlamak için readinessProbe zorunludur. Aksi takdirde, HPA podu "hazır" kabul edip trafiği yönlendirir ancak pod henüz başlamamış olabilir.

Güvenlik ve Operasyonel İpuçları

HPA yapılandırmanızda scaleDown davranışlarını kontrol altına alarak, ani trafik düşüşlerinde podların hemen silinmesini engelleyip "cool-down" süreleri tanımlayabilirsiniz. Bu, uygulamanın kararlılığını artırır. Ayrıca, HPA'nın yönettiği Deployment üzerinde manuel replika değişikliği yapmaktan kaçının; aksi takdirde HPA ile çakışma yaşanacaktır.

Örnek Senaryo: Yüksek Trafikli Bir API

Bir e-ticaret API'si düşünün. Kampanya dönemlerinde trafik 10 katına çıkıyor. Bu senaryoda, sadece CPU'ya güvenmek yerine, istek sayısı (requests per second) metriğini Prometheus üzerinden alarak HPA'yı external metriklerle tetiklemek en profesyonel yaklaşımdır. Böylece CPU ısınmadan, trafik artışını öngörerek ölçeklenebilirsiniz.

HPA Yapılandırmasında Dikkat Edilmesi Gereken Kontrol Listesi

• Tüm podlarda resources.requests tanımlı mı?
• Metrics Server küme üzerinde çalışır durumda mı?
• HPA için belirlenen maxReplicas değeri küme düğüm kapasitesini aşıyor mu?
• readinessProbe yapılandırması servis yanıt süresine uygun mu?
• Loglarda "failed to get cpu utilization" gibi hatalar var mı?

Özetle; HPA, mikroservislerin esnekliği için bir temel taşıdır ancak doğru metrik seçimi ve kaynak yönetimi olmadan verimsiz çalışabilir. Her zaman izleme (monitoring) araçlarınızla (Prometheus/Grafana) HPA hareketlerini korelasyon içinde takip edin.

HPA Yapılandırmasında İleri Seviye Optimizasyon Teknikleri

Temel HPA yapılandırmasının ötesine geçmek, mikroservis mimarinizin kararlılığını doğrudan etkiler. Ölçeklendirme davranışını ince ayarlarla yönetmek, "thrashing" (hızlı ve gereksiz ölçeklenme döngüsü) sorununu engellemek için kritik öneme sahiptir.

Ölçeklendirme Davranışlarını (Behavior) Özelleştirme

Kubernetes 1.18 ve üzeri sürümlerde, HPA'nın ölçeklenme hızını behavior bloğu ile kontrol edebilirsiniz. Bu özellik, özellikle ani trafik dalgalanmalarında sistemin aşırı tepki vermesini engeller.

• scaleUp: Pod sayısının ne kadar hızlı artacağını belirler.
• scaleDown: Pod sayısının ne kadar hızlı azalacağını belirler.
• stabilizationWindowSeconds: Ölçek küçültme sırasında sistemin kararlı kalması için beklenen süredir.

İpucu: Kritik servisleriniz için scaleDown penceresini geniş tutarak, trafiğin tamamen kesilmediği durumlarda podların sürekli silinip tekrar oluşturulmasını (churn) engelleyebilirsiniz.

HPA ve Kaynak Yönetimi Karşılaştırması

Aşağıdaki tablo, farklı ölçeklendirme metriklerinin kullanım senaryolarını ve uygulama yöntemlerini özetlemektedir.

HPA Yapılandırmasında Güvenlik ve İzolasyon

HPA yapılandırırken sadece performans değil, güvenlik de ön planda tutulmalıdır. Özellikle çok kiracılı (multi-tenant) ortamlarda, bir servisin kontrolsüz ölçeklenmesi küme kaynaklarını tüketerek "Denial of Service" (DoS) etkisi yaratabilir.

Resource Quotas ile HPA Sınırlandırma

HPA'nın maxReplicas değerini belirlerken, namespace bazlı ResourceQuota nesnelerini kullanın. Bu sayede, bir yazılım hatası nedeniyle HPA sonsuz döngüye girse bile, namespace için tanımlanan toplam CPU ve RAM kotasını aşamazsınız.

Güvenlik için Kontrol Listesi:

• Namespace bazlı limitler tanımlayın.
• HPA için RBAC yetkilerini sadece gerekli servis hesaplarına verin.
• Pod Disruption Budgets (PDB) kullanarak, ölçeklendirme sırasında kümenin kullanılabilirliğini koruyun.

HPA ve Yatay Ölçeklendirme Senaryoları

Gerçek dünya senaryolarında, sadece CPU'ya bakmak çoğu zaman yanıltıcıdır. Örneğin, bir API servisi yüksek CPU kullanmıyor olsa bile, veritabanı bağlantı havuzunun dolması nedeniyle yanıt süresi artabilir.

Senaryo: "Gecikme Odaklı Ölçeklendirme"

Eğer uygulamanız çok sayıda dış API çağrısı yapıyorsa, CPU kullanımı düşük kalabilir ancak yanıt süreleri (latency) artabilir. Bu durumda, Prometheus üzerinden http_request_duration_seconds metriğini kullanarak, ortalama yanıt süresi 500ms'yi geçtiğinde HPA'yı tetiklemek çok daha verimli bir sonuç verir.

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 100

HPA Hata Giderme: "Neden Ölçeklenmiyor?"

HPA'nın beklendiği gibi çalışmadığı durumlarda izlemeniz gereken standart bir hata giderme akışı mevcuttur:

1. kubectl describe hpa [isim]: İlk bakılacak yerdir. "Conditions" kısmında "FailedGetResourceMetric" veya "MissingMetrics" hatalarını kontrol edin.
2. Metrics Server Kontrolü: kubectl top pods komutu çalışmıyorsa, HPA veriyi alamıyor demektir.
3. Request Tanımı: Pod manifestinde resources.requests tanımlı değilse, HPA yüzde hesaplaması yapamaz.
4. Cooldown Süresi: HPA, ölçeklendirme yaptıktan sonra belirli bir süre (varsayılan 300 saniye) yeni bir ölçeklendirme yapmayabilir.

Operasyonel İpuçları: HPA ve CI/CD Entegrasyonu

HPA yapılandırmasını kod olarak (GitOps) yönetmek, manuel hataları minimize eder. Helm chartları veya Kustomize kullanarak, her mikroservis için standart bir HPA şablonu oluşturun. Bu şablon, ortam değişkenleri (environment variables) ile farklı çevrelerde (dev, staging, prod) farklı eşik değerleri almalıdır.

Özellikle üretim ortamında, HPA'nın minReplicas değerini asla 1'in altına düşürmeyin (eğer yüksek erişilebilirlik gerekiyorsa). Sıfıra ölçeklendirme (scale-to-zero) sadece KEDA gibi gelişmiş araçlarla ve belirli tetikleyicilerle güvenli bir şekilde yapılmalıdır.

Son olarak, HPA'nın kararlarını izlemek için kubectl get hpa --watch komutunu kullanın. Bu, canlı trafik altında sistemin nasıl tepki verdiğini görmenizi sağlar ve ölçeklendirme eşiklerinizi optimize etmeniz için gerekli veriyi sağlar.