Konteynerize AI Ağ Uç Noktalarının (Endpoints) Yapılandırılması

Kubernetes kullanan bir uygulamada trafik yükseldiğinde ilk soru genellikle daha fazla Pod açıp açmamak olur, fakat üretim ortamında doğru cevap bundan daha geniştir. Kubernetes Üzerinde Yük Dengeleme ve Otomatik Ölçekleme, isteğin doğru Pod'a ulaşmasından yeni node kapasitesinin hazırlanmasına kadar birbirini tamamlayan birkaç katmanı kapsar. On yıllık altyapı ve uygulama deneyiminde en sık gördüğüm hata, yalnızca HPA tanımlanıp sistemin artık her trafik artışını kendiliğinden yönetebileceğinin düşünülmesidir. Oysa Service, EndpointSlice, readiness probe, Gateway veya Ingress, metrik kaynağı, resource request değerleri ve node kapasitesi aynı tasarımın parçalarıdır. Bu rehberde sistemi yalnızca çalışan YAML dosyaları olarak değil, trafik geldiği andan uygulamanın yanıt verdiği ana kadar bütün bir kontrol döngüsü olarak ele alacağız.

Bu içeriğe ulaşan birçok kişi doğal olarak “Kubernetes üzerinde yük dengeleme ve otomatik ölçekleme nasıl yapılır”, “Kubernetes HPA ile pod otomatik ölçeklendirme nasıl yapılandırılır” veya “Kubernetes Ingress Service LoadBalancer ve HPA birlikte nasıl kullanılır” gibi soruların yanıtını arıyor. Daha ileri aşamada “Kubernetes autoscaling HPA VPA ve Cluster Autoscaler karşılaştırması” önemli hale geliyor, çünkü Pod sayısını artırmak ile Pod kaynaklarını değiştirmek ve yeni node eklemek aynı işlem değildir. Kurumsal Kubernetes load balancing ve autoscaling kurulum hizmeti araştırılırken de yalnızca teknoloji isimlerine değil, ölçüm ve hata senaryolarına bakmak gerekir. Benzer şekilde “Kubernetes yük dengeleme ve DevOps danışmanlığı yakınımda” şeklindeki bir aramanın gerçek ihtiyacı çoğu zaman canlı bir mimarinin nasıl kurulacağı, nasıl test edileceği ve ekip içinde nasıl sürdürüleceğidir. Burada amacımız tam olarak bu bağlantıları görünür hale getirmektir.

Kubernetes'te Yük Dengeleme ve Otomatik Ölçekleme Nedir?

Kubernetes'te yük dengeleme, mevcut uygulama kopyalarına gelen trafiğin uygun hedeflere dağıtılmasını sağlar. Otomatik ölçekleme ise talep veya kaynak kullanımı değiştikçe çalışan Pod sayısını, Pod kaynaklarını ya da cluster kapasitesini değiştiren kontrol mekanizmalarını ifade eder. Bu iki kavram aynı probleme dokunsa da aynı işi yapmaz. Yük dengeleme elinizdeki kapasiteyi kullanırken autoscaling ihtiyaç duyulan kapasiteyi oluşturur veya azaltır. Sağlam bir üretim tasarımında her iki katman birlikte izlenir ve aynı trafik modeli üzerinden test edilir.

Load Balancing Nedir?

Load balancing, gelen bağlantı veya istekleri birden fazla sağlıklı backend arasında dağıtma işlemidir. Kubernetes tarafında bu görev yalnızca tek bir bileşene ait değildir; Service, veri yolu, harici load balancer ve L7 yönlendirme katmanları farklı noktalarda devreye girebilir. Örneğin beş Pod çalışıyorsa Service bu Pod'ları temsil eden endpoint'lere ulaşılabilecek sabit bir erişim noktası sunar. L7 katmanında ise host, path, header veya protokol gibi daha ayrıntılı bilgiler kullanılabilir. İyi bir dağıtım yalnızca eşit sayıda istek göndermek değil, hazır olmayan veya kapanmakta olan hedeflerin doğru zamanda trafikten çıkarılması anlamına da gelir.

Autoscaling Nedir?

Autoscaling, çalışma kapasitesinin ölçülebilir bir sinyale göre otomatik değiştirilmesidir. HPA Pod sayısını yatay olarak artırıp azaltırken VPA Pod'ların CPU ve bellek ihtiyacına yönelik kaynak değerleri üzerinde çalışır. Cluster Autoscaler veya benzer node provisioning çözümleri ise scheduler'ın yerleştiremediği Pod'lar için altyapı kapasitesi ekleyebilir. KEDA gibi event-driven yaklaşımlar kuyruk uzunluğu veya dış sistem metriği üzerinden ölçeklemeyi tetikleyebilir. Bu yüzden “autoscaling kurduk” demek yerine hangi katmanı, hangi sinyalle ve hangi hızda ölçeklediğinizi açıkça tanımlamak daha doğru olur.

Yük Dengeleme ile Ölçekleme Arasındaki Fark

Yük dengeleme mevcut kaynaklar arasında seçim yapar, ölçekleme ise mevcut kaynak sayısını değiştirir. On Pod'unuz varsa load balancer bu on hedef arasında trafik dağıtabilir, ancak on Pod'un tamamı doygunluğa ulaştığında tek başına yeni kapasite oluşturamaz. HPA bu noktada replica sayısını yükseltebilir, fakat yeni Pod'ların schedule edileceği node kapasitesi yoksa onlar Pending durumda kalır. Node autoscaling devreye girip yeni kapasite eklediğinde scheduler yeni Pod'ları yerleştirebilir. Son adımda readiness koşulları sağlanan Pod'lar endpoint olarak görünür ve yük dengeleme katmanı bu yeni kapasiteyi kullanmaya başlar.

İki Mekanizma Neden Birlikte Çalışmalıdır?

Trafik dağıtımı ile kapasite yönetimi birbirinden kopuk olduğunda teoride yeterli görünen sistem pratikte yavaşlayabilir. HPA yeni Pod'lar açsa bile load balancer yeni Pod'lara trafik göndermiyorsa mevcut Pod'lar aşırı yük altında kalmaya devam eder. Tersi durumda load balancer tüm sağlıklı Pod'ları kullanıyor olabilir, fakat talep kapasite sınırını geçtiğinde dağıtacak yeni hedef bulamaz. Bu nedenle scaling metriğinin, readiness davranışının ve trafik katmanının birlikte gözlemlenmesi gerekir. Ben üretim testlerinde yalnızca replica sayısına değil, her Pod'un aldığı RPS değerine ve yeni Pod'un ne kadar sürede gerçek trafik almaya başladığına da bakılmasını öneriyorum.

Trafiği dağıtmak

Trafiği dağıtmak, sağlıklı backend kapasitesinin mümkün olduğunca dengeli kullanılmasını hedefler. Kubernetes Service bunu endpoint kümesi üzerinden yaparken L7 yönlendirme sistemleri daha ayrıntılı kurallar uygulayabilir. Uzun süre açık kalan bağlantılar, session affinity veya zone tercihleri nedeniyle dağılım her zaman matematiksel olarak eşit olmayabilir. Bu nedenle “beş Pod var, her biri yüzde yirmi trafik alır” varsayımı gerçek sistemlerde her zaman geçerli değildir. Pod bazında bağlantı, istek ve gecikme metriklerini izlemek dağılımın gerçekten nasıl gerçekleştiğini anlamanın daha güvenilir yoludur.

Pod sayısını artırmak

Pod sayısını artırmak, uygulamanın yatay kapasitesini büyütmenin en yaygın Kubernetes yöntemidir. HPA bunu CPU, bellek, custom metric veya external metric gibi sinyaller üzerinden gerçekleştirebilir. Ancak replica artışı yalnızca yeni Pod nesnelerinin oluşturulması anlamına gelmemelidir; image çekme, startup süresi, bağımlılık bağlantıları ve cache hazırlığı da toplam ölçekleme gecikmesine dahildir. Yeni Pod Ready olmadan trafik almamalıdır. Bu yüzden hızlı scale-up hedeflenirken uygulamanın başlatılma süresi ve readiness tasarımı da performans çalışmasının bir parçası olmalıdır.

Node kapasitesi eklemek

HPA'nın istediği yeni Pod'lar mevcut node'lara sığmıyorsa cluster seviyesinde kapasite ihtiyacı ortaya çıkar. Node autoscaler scheduler tarafından yerleştirilemeyen iş yüklerinin taleplerini değerlendirerek uygun kapasitenin eklenmesine yardımcı olur. Burada CPU ve bellek kadar node selector, affinity, taint, availability zone ve özel donanım ihtiyaçları da sonucu belirler. GPU isteyen bir Pod için genel amaçlı bir node eklemek problemi çözmez. Dolayısıyla node autoscaling, yalnızca “daha fazla makine açmak” değil, workload gereksinimine uygun kapasiteyi zamanında sağlayabilmek olarak görülmelidir.

Kubernetes'te İstek Bir Pod'a Nasıl Ulaşır?

Bir istemciden çıkan isteğin Pod'a ulaşması çoğu üretim cluster'ında birden fazla ağ katmanından geçer. Harici load balancer trafiği cluster girişine taşır, Gateway veya Ingress L7 kuralını uygular, Service uygun backend kümesini temsil eder ve veri yolu seçilen Pod'a iletimi gerçekleştirir. EndpointSlice nesneleri hangi endpoint'lerin kullanılabilir olduğunu kontrol düzleminde verimli biçimde taşır. Pod Ready hale geldikçe veya kapanmaya başladıkça bu hedef kümesi değişir. Bu akışı anlamadan autoscaling sorunlarını yalnızca HPA ekranına bakarak teşhis etmek oldukça zordur.

Client

Client, isteği başlatan tarayıcı, mobil uygulama, başka bir servis veya harici sistem olabilir. İstemcinin bağlantı davranışı yük dağılımını doğrudan etkileyebilir, çünkü HTTP keep-alive, HTTP/2 veya gRPC gibi protokoller uzun yaşayan bağlantılar oluşturabilir. Çok sayıda isteğin tek bağlantı üzerinden taşınması yeni Pod'ların beklenen oranda trafik alamamasına yol açabilir. Client tarafındaki timeout ve retry ayarları da yüksek yük sırasında toplam trafiği büyütebilir. Bu nedenle gerçekçi load test senaryolarında istemci bağlantı davranışını üretim koşullarına yakın tutmak gerekir.

External Load Balancer

External Load Balancer, cluster dışından gelen trafiğin Kubernetes giriş noktasına ulaşmasını sağlar. `type: LoadBalancer` Service kullanıldığında destekleyen ortamlarda harici veya dahili bir load balancer sağlanabilir. Bu katman çoğu zaman L4 seviyesinde TCP veya UDP trafiğiyle ilgilenir, fakat kullanılan altyapıya göre daha fazla özellik sunulabilir. Sağlık kontrollerinin yanlış hedeflenmesi cluster içinde sağlıklı Pod'lar bulunmasına rağmen dışarıdan erişim sorunu yaratabilir. Autoscaling testinde bu katmanın connection sayısı, backend health durumu ve dağıtım davranışı ayrı izlenmelidir.

Gateway veya Ingress

Gateway veya Ingress, HTTP ve HTTPS trafiğini host veya path gibi kurallara göre farklı Service'lere yönlendirebilir. Ingress uzun süredir yaygın kullanılan modeldir, Gateway API ise rol ayrımı ve daha geniş protokol modellemesi gibi ihtiyaçları daha açık nesnelerle ifade eder. Burada route kuralının backend Service ile doğru eşleşmesi kritik önemdedir. HPA replica eklediğinde route nesnesini değiştirmek gerekmez, çünkü route genellikle Service'i hedefler ve Service arkasındaki endpoint kümesi dinamik olarak güncellenir. Bu soyutlama, trafik yönetimi ile replica yönetiminin birbirine gevşek bağlı çalışmasını sağlar.

Service

Service, dinamik Pod kümesine sabit bir erişim noktası sağlayan temel Kubernetes ağ soyutlamalarından biridir. Selector kullanan bir Service belirli label değerlerine sahip Pod'ları mantıksal backend kümesi olarak temsil eder. Pod IP'leri değişse bile istemciler Service adına veya sanal IP'sine erişmeye devam edebilir. HPA yeni replica oluşturduğunda Pod uygun label'lara ve readiness durumuna ulaştığı anda Service arkasındaki kullanılabilir hedefler arasında yer alabilir. Böylece uygulama ölçeklenirken istemci tarafında sürekli endpoint listesi güncelleme ihtiyacı doğmaz.

EndpointSlice

EndpointSlice, Service arkasındaki ağ endpoint'lerini ölçeklenebilir şekilde temsil eder. Büyük backend kümelerinde tüm endpoint bilgisini tek bir nesneye koymak yerine bilgi birden fazla slice üzerinden taşınabilir. Endpoint durumları Ready, Serving ve Terminating gibi koşullarla tüketicilere daha fazla bağlam sunar. Autoscaling sonucu yeni Pod'lar açıldığında endpoint bilgisi güncellenir ve ağ katmanı yeni hedefleri kullanabilir hale gelir. Bu nedenle EndpointSlice durumuna bakmak, “Pod Ready görünüyor ama neden trafik almıyor?” sorusunu araştırırken değerli bir teşhis adımıdır.

Pod

Pod, isteğin uygulama konteynerine ulaştığı son Kubernetes yürütme birimidir. Bir Pod'un çalışıyor görünmesi onun hemen üretim trafiği almaya hazır olduğu anlamına gelmez. Uygulama veritabanı bağlantısını kuruyor, cache dolduruyor veya model yüklüyor olabilir. Readiness probe bu hazırlık sürecini trafik katmanına yansıtmak için kullanılır. Autoscaling ile hızlı Pod üretmek kadar bu Pod'ların doğru zamanda Ready olması ve kapanırken aktif istekleri düzgün tamamlaması da önemlidir.

Uçtan Uca Trafik Akışı

Uçtan uca akışı tek cümlede düşünürsek client isteği harici giriş noktasına gelir, route kuralı Service'i seçer, Service endpoint kümesini temsil eder ve veri yolu sağlıklı Pod'a iletim yapar. HPA yeni Pod eklediğinde bu zincirin ilk katmanları değişmeden kalabilir. Asıl değişen nokta Service arkasındaki endpoint kapasitesidir. Node kapasitesi yetmiyorsa zincir Pod oluşmadan önce scheduler aşamasında bekler ve gerçek trafik kapasitesi artmaz. Bu yüzden dashboard üzerinde client RPS, gateway RPS, Service backend durumu, Ready replica ve node kapasitesini aynı zaman ekseninde görmek çok faydalıdır.

Kubernetes Service Nedir?

Kubernetes Service, değişken Pod kümesini kararlı bir ağ kimliği arkasında toplar. Deployment yeniden Pod oluşturduğunda IP adresleri değişebilir, fakat Service DNS adı ve çoğu Service türünde sanal erişim noktası korunur. Bu yapı uygulamalar arasında doğrudan Pod IP bağımlılığı oluşmasını önler. Service aynı zamanda readiness durumuna göre kullanılabilir endpoint kümesinin dinamik biçimde değişebilmesini destekler. Autoscaling açısından bakıldığında bu özellik, yeni Pod kapasitesinin istemcilerde yapılandırma değişikliği gerektirmeden devreye alınmasını sağlar.

Pod IP'leri Neden Doğrudan Kullanılmaz?

Pod IP'leri kalıcı servis adresleri olarak tasarlanmamıştır. Pod yeniden oluşturulduğunda başka bir IP alabilir ve yatay ölçekleme sonucunda backend sayısı sürekli değişebilir. İstemcilerin bütün Pod IP'lerini ayrı ayrı takip etmesi servis keşfini ve hata yönetimini gereksiz yere zorlaştırır. Service bu değişken kümeyi sabit bir isim ve erişim modeli arkasında toplar. Bu nedenle uygulamalar arası iletişimde doğrudan Pod IP listeleri yerine Service tabanlı erişim genel olarak daha sürdürülebilir bir yaklaşımdır.

Service Discovery

Service discovery, bir uygulamanın başka bir servisin nerede bulunduğunu dinamik olarak bulabilmesini sağlar. Kubernetes içinde DNS, Service isimlerini kullanarak uygulamaların sabit IP değerlerini kod içine gömmesini engeller. Deployment replica sayısı değişse bile istemci aynı Service adını kullanmaya devam eder. Bu ayrım özellikle autoscaling sırasında değerlidir, çünkü backend sayısı dakikalar içinde birkaç kez değişebilir. Uygulama kodunun altyapıdaki bu değişimlerden haberdar olmak zorunda kalmaması sistemin bakımını kolaylaştırır.

Stable Virtual IP

ClusterIP türündeki bir Service genellikle cluster içinde kararlı bir sanal IP sunar. Bu IP doğrudan belirli bir Pod'a ait değildir, Service'in arkasındaki dinamik endpoint kümesini temsil eder. Pod'lar silinip yeniden oluşturulsa bile Service erişim noktası sabit kalabilir. Veri yolu gelen bağlantıyı mevcut endpoint'lerden birine yönlendirir. Böylece uygulama ekibi replica değişimini ağ istemcilerinden ayırabilir ve autoscaling çok daha doğal bir şekilde çalışır.

Selector

Selector, Service'in hangi Pod grubunu temsil edeceğini label değerleri üzerinden tanımlar. Örneğin `app: api` label'ına sahip Pod'lar aynı Service'in backend'leri olabilir. HPA aynı Deployment'ın replica sayısını artırdığında yeni Pod'lar aynı label setini taşıdığı için Service kapsamına otomatik olarak girebilir. Yanlış selector ise Pod'lar çalışsa bile endpoint oluşmamasına neden olabilir. Trafik problemi araştırırken Service selector ile Pod label değerlerini karşılaştırmak bu yüzden temel kontrollerden biridir.

EndpointSlice

Service'in seçtiği backend'lerin ağ bilgisi EndpointSlice kaynakları üzerinden temsil edilebilir. Bu model çok sayıda endpoint olduğunda kontrol düzlemi ve ağ bileşenlerinin daha verimli çalışmasına yardımcı olur. Yeni Pod eklenmesi, Pod silinmesi veya readiness değişimi ilgili endpoint bilgisinin güncellenmesine yol açar. Service kullanıcı açısından sabit görünürken arkasındaki endpoint kümesi sürekli değişebilir. Autoscaling ile Service'in birlikte çalışabilmesinin önemli parçalarından biri bu dinamik endpoint yönetimidir.

Kubernetes Service Türleri

Kubernetes dört temel Service türü sunar ve doğru seçim trafiğin nereden geleceğine göre yapılmalıdır. ClusterIP cluster içi erişim için temel seçenektir, NodePort node üzerindeki belirli portlardan erişim sunar ve LoadBalancer destekleyen altyapılarda harici veya dahili load balancer entegrasyonu sağlayabilir. ExternalName ise DNS seviyesinde başka bir ada yönlendirme amacı taşır. Service türü seçimi HPA'nın çalışma biçimini değiştirmez, fakat yeni replica kapasitesine trafiğin nasıl ulaşacağını belirler. Bu nedenle ağ erişim modeli ile autoscaling tasarımı aynı mimari görüşmede ele alınmalıdır.

ClusterIP

ClusterIP, Service'in yalnızca cluster içinden erişilebilir olduğu yaygın varsayılan modeldir. Mikroservislerin birbirleriyle konuştuğu senaryolarda çoğu backend için yeterlidir. Service sabit bir sanal erişim noktası sunarken endpoint listesi Pod yaşam döngüsüne göre değişir. HPA replica eklediğinde yeni Ready Pod'lar aynı Service üzerinden kullanılabilir hale gelir. İnternete doğrudan açılması gerekmeyen servislerde ClusterIP kullanmak ağ tasarımını daha kontrollü tutar.

NodePort

NodePort, Service'i cluster node'larının belirli bir portu üzerinden erişilebilir hale getirir. Bu yöntem bazı basit veya özel entegrasyon senaryolarında yararlı olsa da production giriş mimarisinde tek başına her ihtiyacı karşılamaz. Harici load balancer bazı ortamlarda NodePort üzerinden node'lara trafik iletebilir. `externalTrafficPolicy` gibi ayarlar bu akışın node içindeki davranışını etkileyebilir. Autoscaling sırasında node sayısının değişebileceği düşünülerek harici sistemin backend keşif modeli de göz önünde tutulmalıdır.

LoadBalancer

`type: LoadBalancer`, destekleyen altyapılarda Service için dış veya iç load balancer sağlanmasını tetikleyebilir. Bu seçenek özellikle L4 seviyesinde uygulamayı cluster dışına açmanın standart yollarından biridir. Sağlanan load balancer'ın tam özellikleri cloud provider veya kullanılan controller'a bağlıdır. Backend tarafında Service yine Pod endpoint'lerine bağlanan Kubernetes modelinin parçasıdır. HPA replica artırdığında dış IP değişmeden uygulama kapasitesi büyüyebilir, bu da istemciler açısından önemli bir soyutlama sağlar.

ExternalName

ExternalName Service, trafiği Pod selector üzerinden değil DNS adı üzerinden harici bir hedefe bağlamak için kullanılır. Bu Service türü klasik anlamda Kubernetes backend'leri arasında yük dağıtımı yapmaz. Harici bir servisin adını cluster içindeki uygulamalar için daha tutarlı bir isimle sunmak istediğiniz durumlarda kullanılabilir. HPA ile doğrudan bir ilişkisi bulunmaz, çünkü arkasında ölçeklenen Kubernetes Pod kümesi yoktur. Bu nedenle ExternalName ile ClusterIP veya LoadBalancer kullanım amaçlarını birbirine karıştırmamak gerekir.

Hangi Service Türü Ne Zaman Kullanılmalı?

Cluster içi mikroservis iletişiminde ClusterIP çoğu zaman doğru başlangıçtır. Harici L4 erişimi gerekiyorsa LoadBalancer seçeneği değerlendirilebilir, özel altyapı akışlarında NodePort bilinçli şekilde kullanılabilir. ExternalName ise cluster dışındaki DNS hedefleri için farklı bir araçtır. HTTP veya HTTPS uygulamalarında dış erişimi doğrudan her Service için LoadBalancer açarak çözmek yerine ortak bir Gateway veya Ingress katmanı üzerinden ClusterIP backend'lere yönlendirmek sık kullanılan bir tasarımdır. Seçimi yaparken güvenlik, maliyet, gözlemlenebilirlik ve platform standardizasyonunu birlikte değerlendirmek gerekir.

ClusterIP ile İç Yük Dengeleme

ClusterIP, Kubernetes içindeki servis trafiğinin Pod IP değişimlerinden bağımsız yürütülmesini sağlar. İstemci sabit Service adına bağlanırken ağ katmanı Service'in mevcut sağlıklı endpoint'lerinden birine yönlendirme yapar. Bu davranış uygulama replica sayısı değiştikçe otomatik olarak yeni endpoint kümesine uyum sağlar. Trafiğin her Pod'a tam eşit dağılacağı varsayılmamalıdır, çünkü bağlantı süresi ve kullanılan veri yolu etkili olabilir. Bunun yerine amaç kullanılabilir backend'ler arasında güvenilir erişim sağlamaktır.

Service VIP

Service VIP, bir Service'i temsil eden sanal IP'dir ve belirli bir Pod'a bağlı değildir. Bu IP üzerinden gelen trafik Service'in endpoint kümesine yönlendirilebilir. Pod yeniden başlatılsa veya replica sayısı değişse bile VIP sabit kalabilir. Bu kararlılık, istemci konfigürasyonlarının altyapıdaki hızlı değişikliklerden korunmasını sağlar. Autoscaling ile yeni Pod'ların devreye alınmasında istemcilerin yeni IP listesi öğrenmesi gerekmediği için mimari daha esnek hale gelir.

Pod Endpoint'leri

Pod endpoint'leri Service'in gerçek trafik hedeflerini oluşturur. Selector ile eşleşen ve trafik almaya uygun durumda bulunan Pod'ların IP bilgileri endpoint kaynaklarında temsil edilir. HPA yeni replica oluşturduğunda bu liste genişleyebilir, scale-down sırasında ise daralır. Pod yalnızca Running olduğu için değil, readiness koşullarını karşılaması halinde normal trafik hedefi olmalıdır. Bu ayrım startup sırasında hatalı yanıtların ve kapanış sırasında yarım kalan isteklerin azaltılmasına yardımcı olur.

Trafiğin Pod'lara Dağıtılması

Service trafiği veri yolu mekanizması aracılığıyla kullanılabilir endpoint'lere yönlendirir. Kullanılan kube-proxy modu veya eBPF tabanlı çözüm paketlerin hangi kurallarla taşındığını etkiler. Uygulama seviyesindeki uzun bağlantılar nedeniyle dağılım bağlantı başına veya istek başına farklı sonuçlar gösterebilir. Bu yüzden yalnızca toplam Service RPS metriğine bakmak bazı dengesizlikleri gizler. Pod bazında RPS, connection count ve latency değerlerini karşılaştırmak gerçek yük dağılımını daha iyi gösterir.

Ready Olmayan Pod'ların Trafikten Çıkarılması

Readiness probe başarısız olan bir Pod normal Service trafiği için uygun hedef olarak değerlendirilmemelidir. Bu davranış özellikle yeni replica başlatılırken önem kazanır, çünkü Pod prosesi açılmış olsa bile uygulama bağımlılıklarını henüz hazırlamamış olabilir. Yanlış pozitif readiness sonucu erken trafik alan Pod'lar 5xx oranını yükseltebilir. Yanlış negatif readiness ise sağlıklı kapasiteyi gereksiz yere trafikten çıkarabilir. Bu nedenle probe tanımını basit bir process kontrolü yerine uygulamanın gerçekten istek karşılayabilme durumuyla ilişkilendirmek gerekir.

EndpointSlice Nedir?

EndpointSlice, Kubernetes Service backend bilgisini daha ölçeklenebilir ve durum açısından daha zengin biçimde temsil eden API kaynaklarından biridir. Bir Service çok sayıda Pod'a ulaştığında endpoint bilgisinin bölümlere ayrılması kontrol düzleminin gereksiz büyük nesnelerle çalışmasını azaltabilir. Endpoint'lerin `ready`, `serving` ve `terminating` koşulları yaşam döngüsünün farklı yönlerini ifade eder. Autoscaling nedeniyle endpoint kümesinin sık değiştiği cluster'larda bu bilgiler doğrudan önem taşır. Sorun giderme sırasında Service selector, EndpointSlice durumu ve Pod readiness bilgisine birlikte bakmak güçlü bir yöntemdir.

EndpointSlice ile Service İlişkisi

Service kullanıcıların eriştiği sabit ağ soyutlamasını, EndpointSlice ise arka plandaki hedef kümesini temsil eder. Selector tabanlı Service için controller uygun Pod'ları bularak endpoint bilgisini yönetir. Bu iki kaynak sayesinde istemci Pod IP değişikliklerinden etkilenmeden aynı Service'e bağlanabilir. Autoscaling yeni Pod oluşturduğunda Service tanımı değişmeden EndpointSlice içeriği genişleyebilir. Böylece trafik katmanı yeni kapasiteyi dinamik olarak keşfedebilir.

Büyük Sayıda Pod'un Ölçeklenmesi

Yüzlerce veya binlerce endpoint bulunan ortamlarda backend bilgisini ölçeklenebilir biçimde yönetmek önem kazanır. EndpointSlice tasarımı endpoint bilgisini birden fazla nesneye bölerek bu ihtiyaca yanıt verir. Büyük deployment'ların hızlı scale-up yaptığı dönemlerde control plane üzerinde çok sayıda güncelleme oluşabilir. Sadece HPA hızını artırmak bu güncellemelerin ağ ve scheduler tarafında işlenme süresini ortadan kaldırmaz. Yük testi yapılırken replica artışının yanında endpoint propagation süresini de ölçmek bu nedenle değerlidir.

Ready Condition

`ready` condition, endpoint'in yeni trafik almaya uygun olup olmadığı konusunda temel sinyallerden biridir. Pod tabanlı endpoint'lerde bu durum Pod readiness bilgisiyle bağlantılıdır. Yeni Pod startup sürecini tamamladığında Ready hale gelir ve normal trafik için uygun hedef olabilir. Scale-down veya arıza durumunda Ready bilgisinin değişmesi trafik yönlendirmesini etkiler. Probe tasarımında gecikmeli veya hatalı sonuçlar verilmesi yük dengeleme davranışına doğrudan yansır.

Serving Condition

`serving` condition, endpoint'in halen yanıt verebilme durumunu ifade etmek için kullanılır. Özellikle termination sürecinde yalnızca klasik Ready bilgisi her yaşam döngüsü ayrıntısını anlatmayabilir. Serving ve terminating koşullarını birlikte değerlendirebilen bileşenler kapanış senaryolarını daha doğru yönetebilir. Bu durum connection draining ve graceful shutdown tasarımlarında önem kazanır. Uygulamanın kapanış davranışı ile ağ katmanının endpoint durumunu birlikte ele almak scale-down sırasında hata oranını azaltabilir.

Terminating Condition

`terminating` condition, endpoint'in silinme sürecine girdiğini gösterir. Pod deletion timestamp aldığında bu bilgi endpoint tüketicileri açısından anlamlı hale gelir. Normal durumda kapanmakta olan endpoint'lere yeni trafik göndermek istemezsiniz. Ancak devam eden bağlantıların düzgün kapatılması için uygulamaya yeterli süre verilmesi de gerekir. Bu nedenle termination grace süresi, preStop davranışı ve load balancer connection draining birlikte tasarlanmalıdır.

Autoscaling Sonrası Yeni Pod'ların EndpointSlice'a Eklenmesi

HPA replica sayısını artırdığında Deployment yeni Pod'lar oluşturur ve scheduler bunları uygun node'lara yerleştirir. Pod'lar çalışıp readiness koşullarını karşıladığında Service selector ile eşleşen endpoint bilgisi güncellenebilir. EndpointSlice güncellemesi veri yolu tarafından görüldüğünde yeni Pod gerçek trafik kapasitesine katılır. Bu zincirin herhangi bir noktasındaki gecikme scale-up'ın kullanıcıya yansımasını yavaşlatır. Bu yüzden HPA'nın replica artırdığı an ile yeni Pod'un ilk gerçek isteği aldığı an arasındaki süreyi ölçmek iyi bir production metriğidir.

kube-proxy Kubernetes Yük Dengelemede Ne Yapar?

kube-proxy, Kubernetes Service trafiğinin node üzerinde uygun endpoint'lere yönlendirilmesi için gerekli ağ kurallarını yöneten geleneksel bileşendir. Kullanılan moda göre iptables, IPVS veya nftables gibi farklı Linux mekanizmaları devreye girebilir. Bu işlem uygulama seviyesinde bir reverse proxy olmak zorunda değildir, çoğu durumda kernel ağ mekanizmaları üzerinden gerçekleşir. Büyük cluster'larda kural güncelleme maliyeti ve servis sayısı seçilen veri yolu yaklaşımını daha önemli hale getirir. Bazı modern CNI çözümleri kube-proxy işlevlerini eBPF üzerinden üstlenebilir.

kube-proxy Nedir?

kube-proxy her node üzerinde Service ve endpoint değişikliklerini izleyerek trafik yönlendirme kurallarını güncel tutan Kubernetes ağ bileşenidir. Bir Service'in sanal IP'sine gelen paketin gerçek backend Pod'a ulaşabilmesi için gerekli veri yolu davranışını sağlar. Pod replica sayısı değiştikçe endpoint bilgisi de değiştiği için kuralların güncellenmesi gerekir. Bu nedenle autoscaling yalnızca control plane olayı değildir, ağ veri yolunda da yeni hedef bilgisinin kullanılabilir hale gelmesi gerekir. Büyük sistemlerde bu güncellemelerin gecikmesi ölçekleme performansını etkileyebilir.

iptables Modu

iptables modu uzun yıllardır Kubernetes Service yönlendirmesinde yaygın biçimde kullanılmıştır. kube-proxy Service ve endpoint bilgisinden iptables kuralları oluşturarak paketlerin backend hedeflere taşınmasını sağlar. Küçük ve orta ölçekli cluster'larda bu yaklaşım anlaşılır ve olgun bir çalışma modeli sunabilir. Service ve endpoint sayısı çok büyüdüğünde kural setlerinin güncellenme maliyeti daha görünür hale gelir. Bu nedenle büyük cluster tasarımında yalnızca uygulama replica sayısını değil, ağ kuralı ölçeğini de hesaba katmak gerekir.

IPVS Modu

IPVS modu Linux Virtual Server altyapısını kullanarak Service yönlendirmesi sağlar. Tarihsel olarak büyük Service kümelerinde ölçek ve performans amacıyla tercih edilen seçeneklerden biri olmuştur. Bununla birlikte Kubernetes ağ geliştirmeleri nedeniyle yeni cluster kararlarında mevcut sürüm dokümantasyonunu kontrol etmek önemlidir. Operasyon ekibi yalnızca teorik benchmark değerlerine değil, platformun desteklediği ve ekip tarafından gözlemlenebilen veri yoluna odaklanmalıdır. Ağ modunu değiştirmek production cluster'da sıradan bir uygulama ayarı olmadığı için geçiş planı ayrıca test edilmelidir.

nftables Modu

nftables modu, modern Linux sistemlerindeki nftables altyapısından yararlanarak Service proxy kurallarını yönetmeyi hedefler. Özellikle daha büyük Service ve endpoint kümelerinde kural programlama davranışı nedeniyle ilgi görür. Kullanılabilirlik ve özellik durumu Kubernetes sürümüne bağlı olduğundan cluster sürümüyle resmi dokümantasyonun birlikte kontrol edilmesi gerekir. Migration öncesinde CNI, kernel ve platform uyumluluğu test edilmelidir. Yeni bir veri yolu moduna geçiş yalnızca throughput değil, failure recovery ve gözlemlenebilirlik açısından da doğrulanmalıdır.

Büyük Cluster'larda nftables

Büyük cluster'larda Service ve endpoint sayısı arttıkça veri yolu kural yönetiminin ölçeği daha önemli hale gelir. nftables yaklaşımı bu tür ortamlarda daha verimli kural işleme hedefleriyle değerlendirilebilir. Ancak yalnızca cluster büyük diye ağ modunu değiştirmek doğru değildir. Gerçek servis sayısı, endpoint churn oranı, node işletim sistemi ve platform desteği ölçülmelidir. Karar, kontrollü test ortamında gerçekleştirilen latency, CPU ve rule update ölçümleri üzerinden verilmelidir.

kube-proxy'siz eBPF Veri Yolu

Bazı eBPF tabanlı CNI çözümleri Service load balancing işlevlerini kube-proxy kullanmadan gerçekleştirebilir. Bu model kernel içindeki programlanabilir hook noktalarından yararlanarak paketleri daha doğrudan işleyebilir. Ağ hop sayısı, gözlemlenebilirlik ve policy entegrasyonu açısından farklı avantajlar sunabilir. Buna karşılık veri yolu değişiminin hata ayıklama yöntemleri ve ekip bilgisi üzerinde etkisi vardır. Bu nedenle kube-proxy replacement kararı performans kadar operasyon ekibinin teşhis becerileri ve platform standardı açısından değerlendirilmelidir.

eBPF Tabanlı Kubernetes Load Balancing

eBPF, Linux kernel içinde doğrulanmış programların belirli olay noktalarında çalıştırılmasına imkân veren bir teknolojidir. Kubernetes ağında Service yönlendirmesi, network policy ve gözlemlenebilirlik gibi işlevler için kullanılabilir. eBPF tabanlı veri yolu, geleneksel kural zincirlerinden farklı bir çalışma modeli sunduğu için büyük cluster'larda performans ve görünürlük açısından avantaj sağlayabilir. Bununla birlikte her cluster için otomatik olarak daha iyi olduğu varsayılmamalıdır. Ekip yetkinliği, kernel desteği, CNI seçimi ve troubleshooting süreçleri kararın önemli parçalarıdır.

eBPF Nedir?

eBPF, Linux kernel içinde güvenli sınırlar içinde küçük programlar çalıştırmaya yarayan bir mekanizmadır. Ağ paketleri, socket olayları ve sistem davranışları üzerinde yüksek performanslı gözlem veya işlem yapılmasına olanak tanır. Kubernetes bağlamında bu yetenek Service load balancing ve network policy gibi alanlarda kullanılabilir. Uygulama Pod'larının kaynak kodunu değiştirmeden ağ görünürlüğü elde etmek önemli bir avantajdır. Yine de eBPF kullanımı kernel ve CNI seviyesinde daha güçlü uzmanlık gerektirebilir.

Cilium Service Load Balancing

Cilium, eBPF kullanarak Kubernetes ağ işlevlerini uygulayabilen açık kaynaklı projelerden biridir. Service load balancing işlevleri eBPF veri yolu üzerinden gerçekleştirilebilir ve bazı kurulumlarda kube-proxy işlevleri tamamen devralınabilir. Bu yaklaşım Service ile endpoint arasındaki paket akışını kernel seviyesinde yönetir. Autoscaling sırasında yeni endpoint bilgisi veri yoluna yansıtılmaya devam eder. Cilium tercihinde performans kadar upgrade, observability ve ekip tarafından hata ayıklanabilirlik kriterleri de dikkate alınmalıdır.

kube-proxy Replacement

kube-proxy replacement, Service yönlendirme sorumluluğunun başka bir veri yolu tarafından üstlenilmesi anlamına gelir. eBPF tabanlı çözümler bu işlevi kernel içinde programlanabilir kurallar aracılığıyla gerçekleştirebilir. Böyle bir geçiş ağ katmanında önemli bir mimari karardır ve test ortamında doğrulanmadan uygulanmamalıdır. Service türleri, NodePort, external traffic davranışı ve load balancer entegrasyonları ayrı ayrı test edilmelidir. Production geçişinden önce rollback yaklaşımının belirlenmesi de operasyon açısından önem taşır.

Network Hop Sayısını Azaltma

Ağ yolundaki gereksiz hop'lar latency ve network maliyetini artırabilir. eBPF tabanlı bazı yaklaşımlar paketin daha erken noktada doğru backend'e yönlendirilmesini sağlayarak veri yolunu sadeleştirebilir. Ancak gerçek kazanç cluster topolojisine ve trafik türüne bağlıdır. Aynı node, aynı zone veya farklı zone arasındaki trafik maliyetleri aynı değildir. Bu yüzden hop sayısını teorik olarak saymak yerine distributed tracing ve ağ metrikleriyle gerçek request yolunu ölçmek gerekir.

Gözlemlenebilirlik

eBPF'nin güçlü kullanım alanlarından biri kernel seviyesindeki ağ olaylarını uygulamaya dokunmadan gözlemleyebilmektir. Service'ten Pod'a giden trafik, bağlantı durumu ve policy kararları daha ayrıntılı incelenebilir. Load imbalance araştırırken hangi Pod'un kaç bağlantı aldığını görmek HPA metriklerini yorumlamayı kolaylaştırır. Böylece yüksek CPU'nun gerçek talep artışından mı, dengesiz bağlantı dağılımından mı kaynaklandığı daha iyi anlaşılabilir. Gözlemlenebilirlik, veri yolu seçiminin performans kadar önemli bir değerlendirme kriteridir.

Hangi Cluster'larda Mantıklıdır?

eBPF tabanlı veri yolu özellikle yüksek servis sayısı, gelişmiş network policy ihtiyacı ve ayrıntılı ağ gözlemlenebilirliği olan cluster'larda güçlü bir seçenek olabilir. Bununla birlikte küçük bir ekip için yeni teşhis araçları ve kernel davranışları ek operasyon yükü oluşturabilir. Platform ekibinin Linux networking bilgisinin seviyesi kararda önemlidir. Mevcut CNI sorunsuz çalışıyorsa sırf popüler olduğu için değiştirmek yerine ölçülebilir bir hedef belirlenmelidir. Geçişin latency, CPU, operasyon süresi veya güvenlik görünürlüğü gibi somut bir faydaya bağlanması daha sağlıklıdır.

Kubernetes'te External Load Balancer Nasıl Çalışır?

External load balancer cluster dışındaki istemciler ile Kubernetes Service veya gateway katmanı arasında giriş noktası oluşturur. Cloud ortamlarında `type: LoadBalancer` Service oluşturulduğunda ilgili controller altyapı sağlayıcısından load balancer talep edebilir. Kurulumun ayrıntıları platforma göre değişir ve public veya internal erişim seçenekleri bulunabilir. L4 load balancer bağlantı seviyesinde çalışırken L7 sistemler HTTP özelliklerine göre karar verebilir. HPA backend kapasitesini artırdığında dış load balancer adresinin değişmemesi uygulama tarafında önemli bir süreklilik sağlar.

type: LoadBalancer

`type: LoadBalancer`, Kubernetes Service'in harici veya dahili bir load balancer ile yayınlanmasını istemenin standart yollarından biridir. Destekleyen platform controller'ı gerekli altyapı kaynağını oluşturur ve Service status alanına erişim bilgisini yansıtabilir. Bu model özellikle TCP veya UDP servislerini açmak için pratiktir. HTTP uygulamalarında ise merkezi Gateway katmanı maliyet ve route yönetimi açısından daha uygun olabilir. Her Service için ayrı load balancer açmanın maliyet etkisi mimari karar öncesinde değerlendirilmelidir.

Cloud Controller

Cloud controller, Kubernetes kaynakları ile cloud altyapısındaki gerçek kaynaklar arasında entegrasyon sağlayabilir. LoadBalancer Service oluşturulduğunda dış load balancer provisioning süreci bu entegrasyon üzerinden yürüyebilir. Provisioning anlık olmayabilir ve bazı ortamlarda birkaç kontrol döngüsü gerekebilir. Bu yüzden rollout veya autoscaling testlerinde load balancer oluşturma süresi ile Pod scaling süresini birbirine karıştırmamak gerekir. Altyapı event'leri ve Service status alanı provisioning sorunlarını araştırmak için birlikte incelenmelidir.

Public Load Balancer

Public load balancer internete açık bir erişim noktası sağlar. Bu modelde güvenlik grupları, firewall kuralları, TLS ve rate limiting gibi katmanlar önemli hale gelir. Uygulama autoscale olsa bile public giriş kapasitesi sabit bir darboğaz haline gelebilir. Bu nedenle load test sırasında yalnızca Pod CPU değerine bakmak yeterli değildir. Load balancer connection limiti, paket oranı ve backend health metrikleri de aynı yük altında kontrol edilmelidir.

Internal Load Balancer

Internal load balancer yalnızca özel ağ içinden erişilecek servisler için kullanılabilir. Kurumsal mikroservis entegrasyonları veya private API uçları bu modele uygun olabilir. Public IP ihtiyacı olmadığı için saldırı yüzeyi ve ağ erişim politikası daha kontrollü tutulabilir. Bununla birlikte internal load balancer trafiği de zone'lar arasında ağ maliyeti oluşturabilir. Autoscaling sonucu Pod dağılımı değiştiğinde backend ve zone dengesi izlenmelidir.

L4 Load Balancer

L4 load balancer TCP veya UDP bağlantı bilgilerine dayanarak trafik dağıtır. HTTP path veya header gibi uygulama katmanı ayrıntılarını yorumlamak zorunda değildir. Bu nedenle genel TCP servisleri, veritabanı proxy katmanları veya özel protokoller için uygundur. Kubernetes LoadBalancer Service sık olarak bu katmana karşılık gelen bir model sunar. Trafik dağılımı bağlantı bazlı olduğunda uzun yaşayan bağlantıların Pod'lar arasında eşitsiz yük oluşturabileceği unutulmamalıdır.

L7 Load Balancer

L7 load balancer HTTP veya HTTPS isteğinin host, path, header ve benzeri uygulama katmanı özelliklerine göre yönlendirme yapabilir. Gateway API ve Ingress bu tür kuralları Kubernetes API kaynaklarıyla ifade etmeyi sağlar. Tek bir giriş noktası üzerinden birden fazla Service yayınlanabilir. Canary veya weighted routing gibi rollout desenleri de L7 katmanında uygulanabilir. HPA ile birlikte kullanıldığında L7 route Service'i hedefler, Service arkasındaki Pod kapasitesi ise bağımsız olarak ölçeklenebilir.

L4 ve L7 Yük Dengeleme Arasındaki Fark

L4 yük dengeleme bağlantı seviyesindeki IP, port ve transport protokolü bilgilerine odaklanır. L7 yük dengeleme ise HTTP veya gRPC gibi uygulama protokollerini anlayarak daha ayrıntılı route kararları verebilir. L4 daha genel protokol desteği sunarken L7 path, host, header, TLS termination ve traffic splitting gibi özellikleri mümkün kılar. Performans ve özellik ihtiyacı arasında seçim yapılır. Üretim mimarisinde bazı trafik akışlarının L4, bazılarının L7 üzerinden yönetilmesi oldukça normaldir.

TCP/UDP Tabanlı L4

L4 yaklaşımında yönlendirme TCP veya UDP seviyesinde gerçekleşir. Load balancer uygulama içeriğini okumadan bağlantıyı uygun backend'e iletebilir. Bu model HTTP dışındaki protokoller için özellikle önemlidir. Uzun TCP bağlantılarında yük dağılımı yeni bağlantıların hangi backend'e gittiğine göre şekillenir. HPA yeni replica eklese bile eski bağlantılar otomatik olarak yeni Pod'lara taşınmadığı için connection age yönetimi gerekebilir.

HTTP/HTTPS Tabanlı L7

L7 yönlendirme HTTP veya HTTPS isteklerinin anlamını kullanabilir. Host adı, URL yolu, header veya metod gibi bilgiler route seçimini etkileyebilir. Aynı load balancer arkasında birçok mikroservisin yayınlanması bu sayede kolaylaşır. Gateway veya Ingress katmanı Service backend'lerine yönlendirirken HPA her backend uygulamasını bağımsız ölçekleyebilir. Böylece `/orders` ile `/search` trafiği farklı uygulamalara ve farklı scaling politikalarına bağlanabilir.

Host-Based Routing

Host-based routing, istek içindeki host adına göre farklı backend seçilmesini sağlar. Örneğin API ve yönetim arayüzü farklı Service'lere yönlendirilebilir. Bu yöntem tek giriş IP'si altında birden fazla uygulamayı düzenli biçimde yayınlamaya yardımcı olur. Her backend Service kendi Deployment ve HPA politikasına sahip olabilir. Böylece daha yoğun trafik alan host daha fazla replica kullanırken diğerleri gereksiz kapasite tüketmez.

Path-Based Routing

Path-based routing, aynı host altında farklı URL yollarını farklı backend'lere göndermeyi sağlar. `/api`, `/media` ve `/admin` gibi yollar ayrı Service'lere bağlanabilir. Bu yaklaşım servisleri kullanım profiline göre bağımsız ölçeklemeyi kolaylaştırır. Örneğin medya servisi bandwidth ağırlıklı, API servisi CPU veya RPS ağırlıklı ölçekleme politikasına sahip olabilir. Route tasarımı yapılırken path çakışmaları ve rewrite davranışı açık biçimde test edilmelidir.

TLS Termination

TLS termination, şifreli HTTPS bağlantısının gateway veya load balancer katmanında sonlandırılmasıdır. Sertifika yönetimi bu katmanda merkezi hale getirilebilir. Backend'e trafik yeniden TLS ile veya cluster içi güvenlik politikasına göre farklı biçimde taşınabilir. TLS handshake maliyeti giriş katmanında kapasite planlamasının parçasıdır. Çok yüksek trafik altında yalnızca Pod autoscaling yapıp gateway kapasitesini sabit bırakmak yeni bir darboğaz yaratabilir.

Kullanım Senaryosuna Göre Seçim

Genel TCP veya UDP servisinde L4 yeterli olabilirken HTTP uygulamalarında L7 routing özellikleri büyük kolaylık sağlar. Seçimi yalnızca performansa göre yapmak yerine routing gereksinimi, TLS, gözlemlenebilirlik ve operasyon modeli birlikte değerlendirilmelidir. Tek bir cluster içinde iki yaklaşımın birlikte kullanılması mümkündür. Örneğin web API Gateway üzerinden, özel TCP servisi LoadBalancer Service üzerinden yayınlanabilir. Önemli olan her trafik yolunun ölçekleme ve hata senaryolarının ayrı ayrı anlaşılmasıdır.

Ingress Nedir?

Ingress, HTTP ve HTTPS trafiğinin cluster içindeki Service'lere yönlendirilmesini tanımlayan Kubernetes API kaynağıdır. Tek başına Ingress nesnesi paket taşımaz; onu uygulayan bir Ingress controller gerekir. Host ve path tabanlı routing ile TLS termination gibi yaygın ihtiyaçlar modellenebilir. Uzun süredir kullanılan bir yaklaşım olduğu için birçok production ortamında yerleşik durumdadır. Yeni tasarımlarda Gateway API'nin sunduğu daha geniş rol ve protokol modeli de ayrıca değerlendirilmelidir.

Ingress Resource

Ingress resource, isteklerin hangi host veya path koşulunda hangi Service'e gönderileceğini declarative olarak tanımlar. Bu nesne uygulama ekibinin ağ yönlendirme isteğini Kubernetes API üzerinden ifade etmesini sağlar. Backend Service replica sayısı değişse bile Ingress kuralı genellikle değişmez. HPA yeni Pod'ları Service arkasına ekler ve route aynı Service'i hedeflemeye devam eder. Bu ayrım autoscaling ile routing yönetimini birbirinden bağımsız tutar.

Ingress Controller

Ingress controller, Ingress kaynaklarını izleyerek gerçek reverse proxy veya load balancer konfigürasyonunu uygulayan bileşendir. Controller bulunmadan yalnızca Ingress YAML oluşturmak trafiğin yönlenmesi için yeterli değildir. Her controller'ın annotation ve ek özellik desteği farklı olabilir. Bu durum farklı platformlar arasında taşınabilirliği azaltabilir. Yeni özellik ihtiyacı arttıkça controller'a özel ayarların sayısını kontrol altında tutmak bakım açısından önemlidir.

Host-Based Routing

Ingress host-based routing ile farklı domain adlarını farklı Kubernetes Service'lerine gönderebilir. Böylece tek giriş altyapısı üzerinden birçok uygulama yayınlanabilir. Her Service kendi replica setine ve HPA politikasına sahip olabilir. Trafik profili host bazında ayrıldığı için metriklerin de uygulama bazında toplanması faydalıdır. Aynı gateway kapasitesini paylaşan uygulamaların toplam yükünün giriş katmanını doyurup doyurmadığı ayrıca izlenmelidir.

Path-Based Routing

Ingress path kuralları aynı host içindeki URL yollarını farklı backend Service'lere bağlayabilir. Bu yapı monolitten mikroservis mimarisine geçişte veya API bölümlendirmesinde sık kullanılır. Her path arkasındaki uygulama farklı kaynak talebine sahip olabilir. HPA metric seçimi uygulamanın gerçek darboğazına göre yapılmalıdır. Route kurallarının sırası ve path eşleşme davranışı production öncesinde gerçek isteklerle doğrulanmalıdır.

TLS Termination

Ingress controller HTTPS bağlantısını sonlandırarak sertifika ve TLS ayarlarını merkezi biçimde yönetebilir. Bu, her uygulama Pod'unun ayrı public sertifika yönetmesini gereksiz hale getirebilir. TLS termination yapılan katmanın kendi CPU ve connection kapasitesi de ölçülmelidir. Trafik artışında backend Pod'lar ölçeklenirken Ingress controller sabit kaldığında giriş katmanı darboğaza dönüşebilir. Bu nedenle controller replica sayısı ve kendi autoscaling politikası da production mimarisinde değerlendirilmelidir.

Ingress'in Sınırlamaları

Ingress temel HTTP routing ihtiyaçlarında etkili olsa da gelişmiş kullanım durumları çoğu zaman controller'a özel annotation'lara dayanabilir. Rol ayrımı, cross-namespace backend yönetimi ve farklı protokol route'ları konusunda API modeli sınırlıdır. Bu durum platform ekibi ile uygulama ekiplerinin sorumluluklarını net ayırmayı zorlaştırabilir. Gateway API bu alanlarda daha kapsamlı bir kaynak modeli sunar. Mevcut Ingress sistemini hemen değiştirmek yerine yeni gereksinimleri ve migration maliyetini karşılaştırmak daha doğru olur.

Gateway API Nedir?

Gateway API, Kubernetes üzerinde ağ trafiğini daha açık rol ayrımı ve genişletilebilir kaynak modeliyle tanımlamak için geliştirilen API ailesidir. GatewayClass altyapı tipini, Gateway gerçek giriş noktasını ve Route nesneleri uygulama yönlendirme kurallarını ifade eder. HTTPRoute ve GRPCRoute gibi kaynaklar farklı protokollerin gereksinimlerini daha açık biçimde modelleyebilir. BackendRefs ile bir veya daha fazla backend tanımlanabilir ve desteklenen route türlerinde ağırlıklı trafik dağılımı yapılabilir. Bu yapı platform ve uygulama ekiplerinin aynı ağ altyapısını daha kontrollü paylaşmasına yardımcı olur.

GatewayClass

GatewayClass, cluster içindeki Gateway kaynaklarının hangi controller veya altyapı sınıfı tarafından yönetileceğini tanımlar. Bunu storage tarafındaki sınıf kavramına benzer bir platform seçimi olarak düşünebilirsiniz. Platform ekibi bir veya daha fazla GatewayClass sağlayabilir. Uygulama ekipleri doğrudan load balancer sağlayıcısına özgü ayrıntıları yönetmek zorunda kalmadan uygun sınıfı kullanabilir. Bu ayrım büyük organizasyonlarda ağ standardizasyonunu kolaylaştırır.

Gateway

Gateway, belirli bir GatewayClass üzerinden oluşturulan gerçek trafik giriş noktasını temsil eder. Listener tanımları hangi port ve protokollerin kabul edileceğini belirtir. Route kaynakları `parentRefs` kullanarak bu Gateway'e bağlanabilir. Aynı Gateway birden fazla uygulama ekibi tarafından kontrollü biçimde paylaşılabilir. Böylece altyapı sahipliği ile route sahipliği tek YAML dosyasında karışmak zorunda kalmaz.

HTTPRoute

HTTPRoute, HTTP ve HTTPS trafiği için host, path, header ve benzeri eşleşmeleri tanımlayabilir. Kurallar bir veya daha fazla backendRef üzerinden Service'lere yönlendirilebilir. Backend weight alanı canary gibi trafik bölme desenlerinde kullanılabilir. HTTPRoute artık Gateway API'nin temel ve olgun kaynaklarından biridir. HPA ile birlikte kullanıldığında route Service seviyesinde sabit kalırken her backend uygulama kendi metrikleriyle yatay olarak ölçeklenebilir.

GRPCRoute

GRPCRoute, gRPC servis ve metod bilgisini doğrudan modellemek için tasarlanmıştır. Basit gRPC yönlendirmesi HTTPRoute ile de mümkün olabilse de GRPCRoute gRPC niyetini daha açık ifade eder. gRPC durum kodlarına duyarlı politika ve gözlemlenebilirlik için uygulamaya daha uygun bir temel sunabilir. Ağırlıklı backend kullanımı gRPC rollout senaryolarında da değerlidir. Uzun yaşayan HTTP/2 bağlantılarının gerçek trafik dağılımını etkileyebileceği unutulmamalıdır.

TCPRoute

TCPRoute, TCP stream'lerini Gateway listener'dan backend hedeflere yönlendirmek için kullanılır. HTTP seviyesinde host veya path incelemesi yapılmaz. Özel TCP protokolleri için Gateway API modelini kullanmak isteyen platformlarda yararlı olabilir. Uygulama Pod'ları yatay olarak ölçekleniyorsa yeni bağlantıların backend seçimi önem kazanır. Uzun bağlantılar nedeniyle replica artışı anında eşit trafik dağılımı üretmeyebilir.

UDPRoute

UDPRoute, UDP paketlerinin Gateway üzerinden backend'lere yönlendirilmesini modellemek için kullanılır. UDP bağlantısız bir protokol olduğu için davranışı HTTP veya TCP akışlarından farklıdır. Sağlık kontrolü, state ve paket dağılımı kullanılan implementation'a bağlı ayrıntılar içerebilir. Autoscaling metriği seçilirken paket oranı veya uygulama kuyruğu CPU'dan daha erken sinyal verebilir. Production testleri gerçek paket boyutu ve burst davranışıyla yapılmalıdır.

BackendRefs

BackendRefs, bir Route kuralının trafiği göndereceği backend nesnelerini tanımlar. Kubernetes Service bu amaçla en yaygın backend türüdür. Birden fazla backend tanımlandığında desteklenen Route türlerinde ağırlık verilerek trafik bölünebilir. Bu özellik canary rollout ve progressive delivery gibi desenleri sadeleştirir. Backend Service'lerin her biri ayrı HPA politikası kullanabildiği için trafik ağırlığı ile kapasite oranının birlikte düşünülmesi gerekir.

Gateway API'nin Rol Tabanlı Tasarımı

Gateway API'nin önemli özelliklerinden biri altyapı sahipliği ile uygulama routing sahipliğini ayrı kaynaklarda ifade edebilmesidir. Platform ekibi GatewayClass ve Gateway kaynaklarını yönetirken uygulama ekibi uygun Route kaynakları üzerinde çalışabilir. Bu ayrım güvenlik ve organizasyonel sınırların API seviyesinde daha açık kurulmasını sağlar. Cross-namespace erişimlerde izin modeli ayrıca kontrol edilebilir. Büyük ekiplerde bu yapı ağ değişikliklerinin review sürecini daha anlaşılır hale getirebilir.

Ingress mi Gateway API mi?

Ingress halen birçok production ortamında geçerli ve yaygın bir çözümdür, bu nedenle çalışan bir sistemi yalnızca yeni API bulunduğu için değiştirmek gerekmez. Gateway API ise daha gelişmiş rol ayrımı, route türleri ve trafik yönetimi için daha güçlü bir standartlaşma yönü sunar. Yeni projelerde ihtiyaçlar HTTP routing'in ötesine geçiyorsa Gateway API'yi değerlendirmek mantıklıdır. Migration kararında kullanılan controller'ın Gateway API desteği ve conformance seviyesi kontrol edilmelidir. En doğru seçim ekip deneyimi, protokol ihtiyacı ve mevcut platform yatırımı üzerinden yapılır.

API Geliştirme Durumu

Ingress API olgun ve stabil bir kullanım modeline sahiptir. Gateway API'nin HTTPRoute ve GRPCRoute gibi önemli kaynakları da standart kanalda olgunlaşmıştır, ancak bazı gelişmiş özellikler implementation veya release channel seviyesinde farklılık gösterebilir. Bu nedenle yalnızca kaynak adını görmek yeterli değildir. Kullanılan Gateway controller'ın hangi özellikleri Core, Extended veya implementation-specific olarak desteklediği incelenmelidir. Production manifestleri platformun gerçekten desteklediği conformance profiline göre hazırlanmalıdır.

Portability

Portability, manifestlerin farklı implementation'lar arasında ne kadar az değişiklikle taşınabildiğini ifade eder. Ingress dünyasında controller-specific annotation kullanımı arttıkça taşınabilirlik azalabilir. Gateway API ortak davranışları standardize etmeye çalışarak bu sorunu azaltmayı hedefler. Yine de tüm Extended özelliklerin her controller tarafından aynı anda desteklenmesi beklenmemelidir. Platform seçerken yalnızca YAML uyumluluğu değil, davranış uyumluluğu da test edilmelidir.

Traffic Splitting

Gateway API HTTPRoute backend weight alanı ile ağırlıklı trafik bölme modelini doğrudan ifade edebilir. Örneğin eski versiyona 90, yeni versiyona 10 ağırlık verilerek kontrollü canary trafiği oluşturulabilir. Ingress tarafında benzer işlevler çoğu zaman controller'a özel ayarlara bağlıdır. Trafik splitting yapılırken iki versiyonun replica kapasitesi oranı da düşünülmelidir. Yeni versiyona yüzde on trafik gönderirken yalnızca tek Pod kullanılması ve uzun istekler oluşması canary sonucunu yanıltabilir.

Cross-Namespace Routing

Gateway API farklı namespace'lerdeki route ve backend ilişkilerini açık izin mekanizmalarıyla yönetmeye yönelik bir model sunar. Bu özellik platform ekibinin ortak Gateway altyapısı sağlamasını kolaylaştırır. Uygulama ekipleri kendi namespace'lerinde route sahibi olabilirken backend referansları kontrollü tutulabilir. Güvenlik nedeniyle cross-namespace ilişki varsayılan olarak sınırsız bırakılmamalıdır. GitOps review sürecinde route sahipliği ve referans izinleri birlikte incelenmelidir.

HTTP ve gRPC

HTTPRoute genel HTTP trafik yönetimi için güçlü bir kaynak modelidir. gRPC için GRPCRoute servis ve metod seviyesinde daha anlaşılır eşleşmeler sunabilir. Bu ayrım protokol niyetini YAML içinde daha açık hale getirir. HPA açısından iki route türü de backend Service'lerin replica kapasitesinden bağımsız çalışabilir. gRPC'nin uzun yaşayan HTTP/2 bağlantıları nedeniyle autoscaling sonrası trafik yeniden dağılımı ayrıca test edilmelidir.

TCP ve UDP

Gateway API HTTP dışındaki trafik için TCPRoute ve UDPRoute gibi kaynaklar tanımlar. Bu özellik Ingress'in temel HTTP odaklı modelinden daha geniş bir protokol kapsamı sunar. Her implementation'ın bu route türlerini desteklediği varsayılmamalıdır. Production planında conformance dokümantasyonu kontrol edilmelidir. TCP veya UDP backend autoscaling tasarımında bağlantı ve paket davranışına uygun metrik seçmek CPU'ya körü körüne güvenmekten daha doğru sonuç verebilir.

Yeni Projelerde Hangisi Tercih Edilmeli?

Yeni bir platform kuruyorsanız ve controller desteğiniz yeterliyse Gateway API güçlü bir başlangıç noktasıdır. Daha açık ekip rolleri, HTTP ve gRPC route kaynakları ve ağırlıklı backend desteği uzun vadeli platform tasarımında avantaj sağlar. Ancak mevcut organizasyon yalnızca basit HTTP routing kullanıyor ve Ingress standardı oturmuşsa geçişin değeri ayrıca ölçülmelidir. Teknoloji seçimini sadece yenilik üzerinden yapmak yerine bakım maliyeti ve ekip öğrenme süresi hesaba katılmalıdır. Ben yeni production platformlarında karar vermeden önce küçük bir Gateway API pilotu yapıp gözlemlenebilirlik ve operasyon süreçlerini gerçek yükle test etmeyi tercih ederim.

Gateway API ile Weighted Load Balancing

Gateway API, HTTPRoute gibi kaynaklarda birden fazla backend için ağırlık tanımlayarak trafiği oranlı şekilde dağıtabilir. Bu mekanizma yeni versiyonu küçük kullanıcı yüzdesiyle açmak veya iki backend arasında kontrollü geçiş yapmak için kullanışlıdır. Ağırlık değerleri mutlak yüzde olmak zorunda değildir, birbirlerine göre oranı ifade eder. 90 ve 10 değerleri pratikte 90/10 hedef dağılımını ifade eder. Autoscaling tasarımında her backend'in aldığı trafik miktarıyla uyumlu minimum ve maksimum replica sınırları belirlenmelidir.

Backend Weight

Backend weight, aynı route kuralında bulunan backend'lerin göreli trafik payını belirtir. İki backend'e 9 ve 1 vermek ile 90 ve 10 vermek aynı temel oranı ifade eder. Bu özellik deployment rollout sürecini uygulama kodundan bağımsız yönetmeye yardımcı olur. Trafik oranı değiştikçe backend uygulamaların HPA metrikleri de değişir. Canary backend'in çok düşük trafik nedeniyle yeterli gözlem üretmemesi ihtimali rollout planında dikkate alınmalıdır.

90/10 Trafik Dağılımı

90/10 modeli trafiğin büyük kısmını kararlı sürümde tutup küçük bir bölümünü yeni sürüme gönderir. Bu yöntem hata oranı, latency ve business metric farklarını düşük riskle ölçmek için kullanılabilir. Ancak yüzde on trafik uygulamanın gerçek davranışını görmek için yeterli hacim üretmeyebilir. HPA yeni backend için minimum replica sayısını çok düşük tuttuğunda tek Pod üzerinde burst oluşabilir. Bu nedenle trafik ağırlığı, minimum replica ve gözlem penceresi birlikte tasarlanmalıdır.

Canary Deployment

Canary deployment yeni sürümün sınırlı trafikle doğrulanmasını sağlar. Gateway API ağırlıklı backend yönlendirmesi canary oranını açık bir Route tanımıyla ifade edebilir. İzlenecek metrikler yalnızca 5xx değil, p95 latency, retry oranı ve iş sonucu metriklerini de içermelidir. Canary Pod'ları farklı image sürümü kullandığı için ayrı Deployment ve ayrı HPA tanımlamak çoğu senaryoda daha kontrollüdür. Başarılı sonuç alındıkça trafik ağırlığı kademeli olarak artırılabilir.

Blue-Green Deployment

Blue-green deployment iki tam ortam veya backend sürümünü aynı anda hazır tutarak geçiş riskini azaltmayı amaçlar. Gateway route ağırlığı veya backend değişimi trafik geçişini yönetebilir. Bu model canary'ye göre daha fazla geçici kapasite gerektirebilir. Autoscaling kullanılıyorsa green ortamın trafik almadan önce yeterli minimum kapasiteye sahip olması gerekir. Bir anda yüzde yüz geçiş yapılacaksa cold start riskini ortadan kaldırmak için pre-warming uygulanmalıdır.

Progressive Delivery

Progressive delivery, yeni sürüme giden trafiğin ölçümlere göre adım adım artırılması yaklaşımıdır. Gateway API traffic splitting bu sürecin ağ katmanındaki temel araçlarından biri olabilir. Her adımda error rate, latency ve iş metriği kontrol edilmelidir. HPA davranışı da rollout sırasında gözlenmelidir, çünkü yeni sürüm aynı trafiği daha fazla CPU ile işliyorsa replica ihtiyacı değişebilir. Deployment başarısını sadece route seviyesinde değil kapasite verimliliği açısından da değerlendirmek gerekir.

Session Affinity Nedir?

Session affinity, belirli istemciden gelen trafik veya bağlantıların aynı backend'e yönlendirilmesini sağlamaya çalışan yaklaşımdır. Bazı stateful uygulamalar bunu gerektirebilir, ancak yatay ölçekleme açısından yük dengesizliği yaratma riski vardır. Stateless uygulamalarda kullanıcı oturum bilgisini harici store'a taşımak backend seçimini daha serbest hale getirir. ClientIP tabanlı affinity özellikle NAT arkasındaki çok sayıda kullanıcıyı aynı Pod'a yığabilir. Bu nedenle affinity kullanılacaksa Pod bazında trafik dağılımı mutlaka izlenmelidir.

Stateless Uygulamalarda Varsayılan Yaklaşım

Stateless uygulama her isteği mümkün olduğunca herhangi bir sağlıklı Pod üzerinde işleyebilmelidir. Kullanıcı oturumu, sepet veya geçici durum yalnızca Pod belleğine bağlı tutulmaz. Böylece load balancer yeni replica'ları hemen kullanabilir ve Pod silinmesi kullanıcı oturumunu bozmaz. HPA ile yatay ölçekleme daha tahmin edilebilir hale gelir. Production API'lerinde stateless tasarım mümkünse session affinity ihtiyacını azaltmak genellikle daha sağlıklı bir yaklaşımdır.

ClientIP Session Affinity

ClientIP session affinity aynı kaynak IP'den gelen bağlantıları belirli backend'e yönlendirmeye çalışır. Bu yöntem basit görünse de gerçek kullanıcı sayısı ile görünen kaynak IP sayısı aynı olmayabilir. Büyük kurumsal ağlar veya NAT katmanları yüzlerce kullanıcıyı tek IP altında gösterebilir. Sonuçta bir Pod diğerlerinden çok daha fazla yük alabilir. HPA ortalama CPU üzerinden karar veriyorsa aşırı yüklenen tek Pod'un problemi replica artışıyla hemen çözülmeyebilir.

Sticky Session

Sticky session, kullanıcının belirli backend'e bağlı kalmasını sağlayan daha genel bir kavramdır. Cookie veya istemci bilgisi gibi farklı yöntemlerle uygulanabilir. Uygulama içindeki local session state nedeniyle gerekli görülebilir. Ancak Pod kaybı veya scale-down sırasında kullanıcı deneyimini etkileyebilir. Mümkün olan sistemlerde oturum state'ini harici ve paylaşılan bir store'a taşımak load balancing esnekliğini artırır.

Session Affinity Autoscaling'i Nasıl Etkiler?

Autoscaling yeni Pod eklediğinde mevcut sticky kullanıcılar otomatik olarak yeni Pod'a taşınmayabilir. Böylece toplam replica sayısı artsa bile eski Pod'lar yüksek yükte kalabilir ve yeni Pod'lar düşük kullanım gösterebilir. HPA ortalama metriğe baktığında bu dengesizlik görünmez hale gelebilir. Uzun yaşayan kullanıcı oturumlarında problem daha belirgindir. Autoscaling testi sırasında replica artışından sonra Pod bazında RPS dağılımını incelemek bu yüzden önemlidir.

Stateful Session'ları Harici Store'a Taşımak

Oturum bilgisini Pod belleği yerine paylaşılan bir store'da tutmak stateless backend tasarımını kolaylaştırır. Böylece herhangi bir Pod aynı kullanıcı isteğini işleyebilir. Load balancer daha serbest dağıtım yapar ve HPA'nın eklediği yeni Pod'lar hızlı biçimde kullanılabilir. Harici store'un da yüksek erişilebilirlik ve latency gereksinimleri ayrı tasarlanmalıdır. Bir darboğazı Pod'lardan kaldırıp session store'a taşımamak için load test bu bağımlılığı da kapsamalıdır.

externalTrafficPolicy Nedir?

`externalTrafficPolicy`, Kubernetes Service'e dışarıdan gelen trafiğin cluster node'ları arasında nasıl yönlendirileceğini etkileyen ayardır. `Cluster` ve `Local` seçenekleri farklı client IP ve network hop davranışları sunar. `Local` istemci IP'sini koruma ve node-local endpoint kullanma açısından avantaj sağlayabilir, ancak endpoint dağılımı eşit değilse node'lar arasında yük dengesizliği oluşabilir. HPA yeni Pod'ları farklı node'lara dağıttığında bu denge değişir. Bu nedenle external traffic policy kararı topology spread ve node kapasitesiyle birlikte düşünülmelidir.

Cluster

`Cluster` politikası node'a gelen dış trafiğin cluster içindeki uygun endpoint'lere yönlendirilebilmesini sağlar. Bu yaklaşım node üzerinde local Pod olmasa bile Service'in diğer node'lardaki backend'lerini kullanabilir. Sonuç olarak endpoint kapasitesi daha geniş biçimde paylaşılır. Buna karşılık ek network hop oluşabilir ve bazı topolojilerde gerçek client IP'nin korunma davranışı farklılaşabilir. Performans ve ağ maliyeti açısından production trafiğiyle ölçüm yapmak gerekir.

Local

`Local` politikası trafiğin yalnızca paketin ulaştığı node üzerindeki local endpoint'lere gönderilmesini hedefler. Bu yaklaşım kaynak IP koruma ve hop azaltma açısından faydalı olabilir. Ancak belirli node'da endpoint yoksa veya çok azsa kapasite dağılımı sorunları oluşabilir. HPA yeni replica açtığında scheduler'ın Pod'ları hangi node'lara yerleştirdiği doğrudan trafik kapasitesini etkiler. Topology spread kullanmadan Local politikaya geçmek bazı node'ları aşırı yükleyebilir.

Client IP Preservation

Gerçek istemci IP bilgisinin backend uygulamaya ulaşması güvenlik logları, rate limiting ve analitik için önemli olabilir. `externalTrafficPolicy: Local` bu ihtiyacı destekleyen yaygın seçeneklerden biridir. Ancak client IP korunurken trafik dağılımının node-local endpoint'lerle sınırlanması kapasite dengesini değiştirebilir. Rate limiting'i yalnızca IP üzerinden yapan uygulamalarda NAT etkileri ayrıca düşünülmelidir. Client IP gereksinimi ile yük dengesi arasında bilinçli seçim yapılmalıdır.

Ek Network Hop

Cluster politikası trafiği giriş yaptığı node'dan başka node'daki Pod'a yönlendirebilir. Bu durum ek network hop ve bazı cloud ortamlarında zone'lar arası maliyet oluşturabilir. Tek istek için küçük görünen fark yüksek RPS seviyesinde ciddi toplam trafik hacmine dönüşebilir. Same-zone tercihleri ve topology-aware routing bu maliyeti azaltmak için değerlendirilebilir. Yine de performans optimizasyonu yaparken availability davranışını zayıflatmamak gerekir.

Load Imbalance Riski

Local trafik politikası endpoint sayısı node'lar arasında eşit değilse yük dengesizliği oluşturabilir. Dış load balancer node'lara eşit bağlantı gönderirken bir node üzerinde bir Pod, başka node üzerinde dört Pod bulunabilir. İlk node'daki tek Pod daha fazla yük taşır. HPA toplam ortalama metric üzerinden yeni replica açsa bile scheduler yeni Pod'u başka node'a koyarsa sorun devam edebilir. Topology spread ve Pod bazlı trafik ölçümü bu riski azaltmak için önemlidir.

HPA ile Etkileşimi

HPA replica sayısını artırır, ancak Pod'ların hangi node'a yerleşeceğini doğrudan belirlemez. `externalTrafficPolicy: Local` kullanıldığında bu yerleşim gerçek trafik kapasitesinin node bazında nasıl dağıldığını etkiler. Yeni replica yanlış node'a yerleşirse yoğun node'un local kapasitesi artmayabilir. Bu nedenle HPA ile birlikte topology spread constraints veya uygun affinity stratejileri kullanılabilir. Scale testinde replica sayısı kadar node başına Ready Pod sayısı da izlenmelidir.

internalTrafficPolicy Nedir?

`internalTrafficPolicy`, cluster içinden Service'e gelen trafiğin node-local endpoint tercihinin zorunlu olup olmayacağını belirler. `Cluster` seçeneği tüm uygun endpoint'leri kullanabilirken `Local` yalnızca aynı node'daki endpoint'lerle çalışır. Node-local trafik latency ve network maliyeti açısından avantaj sağlayabilir. Buna karşılık local endpoint bulunmadığında Service erişimi başarısız olabilir. Bu yüzden Local seçeneği ancak uygulama topolojisi ve availability beklentisi bunu karşılıyorsa kullanılmalıdır.

Cluster

`Cluster` internal traffic policy, cluster içindeki istemcinin Service'in tüm uygun endpoint'lerine erişebilmesini sağlar. İstemci ve backend aynı node'da olmak zorunda değildir. Bu model kapasiteyi cluster genelinde paylaşmayı kolaylaştırır. Cross-node veya cross-zone trafik maliyeti oluşabilir. Yüksek iç trafik hacmine sahip sistemlerde topoloji tercihleriyle birlikte değerlendirilmesi yararlı olur.

Local

`Local` iç trafik politikasında yalnızca istemciyle aynı node üzerindeki endpoint'ler kullanılabilir. Bu yöntem sidecar dışı node-local servisler veya belirli latency ihtiyaçları için değerlendirilebilir. Ancak node üzerinde uygun endpoint yoksa trafik başka node'a otomatik geçmeyebilir. HPA replica sayısını artırsa bile her node'da backend bulunacağı garanti değildir. Bu nedenle DaemonSet benzeri dağılım desenleri dışında dikkatli kullanılmalıdır.

Node-Local Trafik

Node-local trafik paketlerin cluster ağı üzerinde başka node'a gitmesini engelleyebilir. Bu durum latency ve network bandwidth tüketimini azaltabilir. Özellikle çok yoğun servisler için fayda anlamlı olabilir. Buna rağmen availability üzerindeki etkisi ölçülmeden yalnızca performans amacıyla zorunlu local routing yapmak risklidir. Tercih tabanlı `trafficDistribution` seçenekleri bazı kullanım durumlarında daha dengeli bir çözüm sağlayabilir.

Latency ve Network Maliyeti

Cross-node ve özellikle cross-zone trafik bazı cloud ortamlarında hem latency hem maliyet oluşturur. Node-local routing bu iki maliyeti azaltabilir. Ancak lokal kapasite yetersiz olduğunda istek başarısızlığı daha pahalı bir sonuç olabilir. Bu nedenle SLO hedefleri ağ tasarımının önünde yer almalıdır. Optimizasyon yapılırken başarılı istek başına toplam maliyet ölçmek yalnızca network faturası karşılaştırmaktan daha anlamlıdır.

Local Endpoint Bulunmadığında Ne Olur?

`internalTrafficPolicy: Local` kullanıldığında istemci node'unda uygun endpoint bulunmaması Service trafiğinin kullanılamamasına yol açabilir. Bu davranış policy'nin bilinçli biçimde katı olmasından kaynaklanır. Yani sistem başka node'daki endpoint'i yalnızca kapasite var diye kullanmak zorunda değildir. Bu özellik deployment topology'sini yanlış yapılandırdığınızda beklenmedik hata üretebilir. Local policy production öncesinde node boşaltma ve Pod yeniden zamanlama senaryolarıyla test edilmelidir.

Kubernetes trafficDistribution Nedir?

`trafficDistribution`, Service endpoint seçiminde topology açısından daha yakın hedefleri tercih etmeyi ifade eden bir alandır. Katı traffic policy'lerden farklı olarak burada amaç erişim kuralını zorunlu kılmaktan çok tercih bildirmektir. Güncel Kubernetes sürümlerinde aynı zone veya aynı node tercihlerini ifade eden değerler bulunabilir ve özellik durumu sürüme göre kontrol edilmelidir. Bu mekanizma cross-zone trafiği azaltarak latency ve cloud network maliyetine katkı sağlayabilir. Ancak kapasite dengesizliği oluştuğunda tercihlerin availability davranışıyla birlikte değerlendirilmesi gerekir.

Trafik Tercihi ve Zorunlu Trafik Politikası Farkı

Traffic policy, belirli endpoint kapsamını zorunlu hale getirebilirken traffic distribution daha çok tercih bildirir. Bu fark failure durumunda önem kazanır. Katı local policy uygun endpoint olmadığında trafiği başka yerdeki backend'e göndermeyebilir. Tercih tabanlı yaklaşım ise uygulamaya ve veri yolu implementation'ına göre daha esnek davranabilir. Bu yüzden latency optimizasyonu istenirken availability kaybı istemiyorsanız iki mekanizmayı aynı şey olarak düşünmemelisiniz.

PreferSameZone

`PreferSameZone`, istemciyle aynı availability zone içindeki endpoint'lere öncelik verilmesini ifade eder. Aynı zone trafik gecikmesini ve cross-zone network maliyetini azaltabilir. Ancak zone içindeki Pod kapasitesi yetersiz olduğunda yük dağılımı dengesizleşebilir. HPA Pod eklediğinde topology spread ile replica'ların zone'lara dengeli dağılması bu tercihin daha sağlıklı çalışmasına yardımcı olur. Cluster sürümünüzde alanın ve değerin özellik durumunu deployment öncesinde doğrulamak gerekir.

PreferSameNode

`PreferSameNode`, mümkün olduğunda istemciyle aynı node üzerindeki endpoint'e öncelik verilmesini amaçlar. Yoğun iç servis trafiğinde network hop sayısını azaltabilir. Bununla birlikte aynı node'daki Pod'a aşırı yönlenme riski uygulama yapısına bağlıdır. Pod bazında RPS ve CPU dağılımı bu tercihin etkisini görmek için izlenmelidir. Node arızasında davranışın SLO hedefleriyle uyumlu olduğu chaos testleriyle doğrulanmalıdır.

Cross-Zone Trafik Azaltma

Cross-zone trafik yüksek hacimli mikroservis mimarilerinde önemli bir maliyet kalemi olabilir. Aynı zone endpoint'lerini tercih etmek hem network ücretlerini hem bağlantı gecikmesini azaltabilir. Ancak her zone'da yeterli replica bulunmadığında bu optimizasyon dengesiz kapasite kullanımına yol açabilir. Topology spread constraints ile HPA'nın eklediği Pod'ları zone'lara daha dengeli dağıtmak faydalıdır. Network maliyet analizi için https://www.diyarbakiryazilim.com.tr/posts/bulut-maliyet-yonetimi-ve-finops-stratejileri içeriği de maliyet yönetimi bakışını tamamlayabilir.

Latency ve Cloud Maliyeti

Topology-aware trafik tercihleri aynı anda hem latency hem cloud network harcamasını etkileyebilir. Fakat en düşük network maliyeti her zaman en iyi sistem davranışı değildir. Zone içinde kapasite tükenirken başka zone'da boş kapasite varsa aşırı local tercih kullanıcı latency'sini yükseltebilir. Bu nedenle optimizasyon kararını SLO, kapasite ve maliyet üçlüsü üzerinden vermek gerekir. Production dashboard'unda zone bazlı RPS ve zone'lar arası network hacmi birlikte izlenmelidir.

Topology-Aware Routing

Topology-aware routing, trafik hedefi seçilirken node veya availability zone gibi fiziksel yerleşim bilgisinin kullanılmasını ifade eder. Amaç çoğu zaman yakın backend'i tercih ederek latency ve cross-zone trafik maliyetini azaltmaktır. EndpointSlice hints ve Service traffic distribution mekanizmaları bu alanla ilişkilidir. Bunun sağlıklı çalışabilmesi için Pod'ların zone'lara dengeli dağıtılması gerekir. HPA yalnızca replica sayısını artırdığı için topology dengesini scheduler politikalarıyla tamamlamak önemlidir.

Availability Zone Bilgisi

Kubernetes node label'ları node'un hangi availability zone içinde bulunduğunu gösterebilir. Scheduler topology spread ve affinity kararlarında bu bilgiyi kullanabilir. Ağ katmanı da topology-aware trafik davranışında zone bilgisinden yararlanabilir. Multi-AZ cluster'da her zone'da benzer Pod kapasitesi bulundurmak local routing tercihlerini daha etkili yapar. Node autoscaler yeni node eklerken zone kapasite kısıtları bu dengeyi değiştirebilir.

EndpointSlice Hints

EndpointSlice hints, endpoint'lerin belirli topolojiler için tercih edilmesine yardımcı olabilecek bilgiler taşıyabilir. Bu yaklaşım aynı zone routing gibi optimizasyonların uygulanmasına katkı sağlar. Hints katı bir güvenlik sınırı olarak görülmemelidir. Trafik tercihleri gerçek kapasite ve endpoint durumuyla birlikte yorumlanır. Production'da bu özelliklerin cluster sürümü ve kullanılan veri yolu tarafından nasıl desteklendiği kontrol edilmelidir.

Same-Zone Routing

Same-zone routing, istemci trafiğinin öncelikle aynı availability zone'daki backend'lere gitmesini hedefler. Cross-zone latency ve ağ ücretini azaltabilir. HPA bir zone'da yeterli yeni Pod üretemezse aynı-zone kapasite sınırı daha hızlı görünür hale gelir. Scheduler ve node autoscaler'ın zone dağılımı bu nedenle kritik önemdedir. Zone bazında minimum replica garantisi gerektiren sistemlerde topology spread constraints ve kapasite rezervi birlikte tasarlanmalıdır.

Multi-Zone Cluster

Multi-zone cluster, node'ların birden fazla availability zone'a dağıtılmasıyla tek zone arızasına karşı daha yüksek dayanıklılık sağlamayı amaçlar. Uygulama Pod'ları da bu zone'lara dengeli biçimde yayılmalıdır. Yalnızca node'ları multi-zone yapmak, tüm replica'lar tek zone'da kalıyorsa beklenen korumayı sağlamaz. HPA scale-up sırasında yeni Pod'ların dağılımı topology spread ve mevcut kapasiteye bağlıdır. Failure testinde bir zone tamamen kullanılamaz hale getirildiğinde kalan zone'ların trafiği taşıyıp taşıyamadığı ölçülmelidir.

Topology Routing ile HPA'nın Etkileşimi

HPA yalnızca kaç replica gerektiğini hesaplar, replica'ların hangi zone'da çalışacağını scheduler belirler. Topology-aware routing aynı-zone endpoint'leri tercih ediyorsa zone başına replica dağılımı kullanıcı trafiğini doğrudan etkiler. HPA toplam CPU ortalamasına baktığında tek zone'daki hotspot gizlenebilir. Zone etiketli metriklerle trafik ve CPU dağılımını ayrı görmek daha doğru teşhis sağlar. Gerekirse scaling metric tasarımı global ortalama yerine bölgesel doygunluğu da hesaba katmalıdır.

Kubernetes Autoscaling Türleri

Kubernetes autoscaling tek bir controller'dan ibaret değildir. HPA replica sayısını, VPA Pod kaynak önerilerini veya güncellemelerini, Cluster Autoscaler node gruplarının kapasitesini ve KEDA event-driven iş yüklerini yönetmek için farklı katmanlarda çalışır. Karpenter gibi dinamik provisioning araçları workload gereksinimine göre uygun node kapasitesi sağlayabilir. Bu araçların her biri farklı bir soruyu yanıtlar. Production mimarisinde hangisinin neyi ölçeklediğini netleştirmek çakışan veya eksik kontrol döngülerini önler.

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler bir workload'un replica sayısını ölçülen metriğe göre artırıp azaltır. CPU ve bellek gibi resource metrics yanında custom ve external metrics de kullanılabilir. HPA yeni Pod oluşturmaz, hedef Deployment veya benzeri kaynağın replica değerini kontrol döngüsü üzerinden ayarlar. Gerçek Pod oluşturma işlemini ilgili workload controller yürütür. Sağlıklı HPA tasarımı doğru request değerleri, anlamlı metric ve kontrollü scale-down davranışı gerektirir.

Vertical Pod Autoscaler

Vertical Pod Autoscaler, Pod'ların CPU ve bellek kaynak ihtiyacına yönelik öneriler üretir ve belirli modlarda bu değerlerin uygulanmasına yardımcı olabilir. Temel amacı replica sayısını artırmak değil, Pod başına kaynak boyutlandırmasını iyileştirmektir. Yanlış request değerleri scheduler verimliliğini ve HPA hesaplarını etkileyebildiği için VPA önerileri faydalı olabilir. CPU utilization bazlı HPA ile VPA aynı request değerini sürekli değiştirdiğinde iki kontrol döngüsü arasında istenmeyen etkileşim oluşabilir. Bu nedenle beraber kullanım senaryosu dikkatle tasarlanmalıdır.

Cluster Autoscaler

Cluster Autoscaler, node group kapasitesini scheduler'ın yerleştiremediği Pod'lara göre artırabilen ve kullanılmayan node'ları belirli koşullarda azaltabilen bir bileşendir. HPA'nın açtığı Pod mevcut node'lara sığmadığında Pending durumda kalabilir. Cluster Autoscaler uygun node group'u büyüttüğünde scheduler Pod'u yeni node'a yerleştirir. Scale-down sırasında Pod evictions, PDB ve workload kısıtları dikkate alınır. Bu nedenle node autoscaling hızını yalnızca VM açılma süresine indirgemek doğru değildir.

Karpenter

Karpenter, özellikle desteklenen cloud ortamlarında workload gereksinimlerine göre dinamik node provisioning yaklaşımı sunar. Önceden sabit birkaç node group tanımlamak yerine instance seçimini Pod taleplerine göre daha esnek yapabilir. NodePool tanımları hangi kapasite türlerinin ve sınırların kullanılabileceğini belirler. Consolidation ile düşük kullanılan kapasitenin daha verimli node düzenine taşınması hedeflenebilir. Spot ve on-demand kombinasyonları kullanıldığında availability ve interruption senaryoları ayrıca test edilmelidir.

KEDA

KEDA, event-driven workload'ların dış olay kaynaklarına göre ölçeklenmesini kolaylaştırır. Kafka lag, queue length, Prometheus sorgusu veya cron gibi trigger'lar kullanılabilir. ScaledObject hedef workload için HPA ile birlikte çalışırken sıfırdan bire geçişi KEDA yönetebilir. Uygun trigger'larda `minReplicaCount: 0` ile scale-to-zero mümkündür. Queue consumer ve batch sistemlerinde CPU'dan daha erken sinyal sağlayan event metriği kullanmak önemli bir avantajdır.

Hangi Katmanda Neyi Ölçeklerler?

HPA Pod sayısını, VPA Pod başına kaynak değerini, Cluster Autoscaler ve Karpenter node kapasitesini yönetir. KEDA ise dış event sinyallerini replica yönetimine bağlar ve çoğu ScaledObject senaryosunda HPA mekanizmasını kullanır. Bu katmanlar birbirinin doğrudan alternatifi değildir. Örneğin yoğun queue trafiğinde KEDA replica sayısını artırabilir, yeni Pod'lar sığmazsa node autoscaler ek kapasite oluşturabilir. Başarılı production mimarisi bu kontrol döngülerinin hangi sırada devreye girdiğini açıkça gösterir.

Horizontal Pod Autoscaler (HPA) Nedir?

HPA, Kubernetes workload replica sayısını metriklere göre otomatik değiştiren kontrol mekanizmasıdır. Controller belirli aralıklarla metriği toplar, mevcut değer ile hedef değer arasındaki oranı hesaplar ve gerekli replica sayısını belirler. `minReplicas` güvenli alt sınırı, `maxReplicas` ise kapasite veya maliyet açısından üst sınırı belirler. `autoscaling/v2` birden fazla metric ve ayrıntılı behavior ayarları için kullanılabilir. HPA'yı doğru kullanmak yalnızca YAML oluşturmak değil, doğru metric, doğru request ve doğru stabilization politikasını birlikte tasarlamaktır.

HPA Nasıl Çalışır?

HPA controller hedef workload'u ve tanımlı metrikleri periyodik olarak kontrol eder. Resource metric kullanılıyorsa gerekli veriler resource metrics API üzerinden alınabilir. Mevcut değer hedefin üzerindeyse daha fazla replica, altındaysa uygun koşullarda daha az replica önerilebilir. Birden fazla metric varsa her biri için hesap yapılır ve genel olarak en yüksek replica ihtiyacı tercih edilir. Scale-down kararında stabilization ve eksik metric gibi durumlar ani kapasite kaybını önlemek için davranışı etkiler.

Desired Replica Hesabı

Temel HPA mantığı mevcut replica sayısını gözlenen metriğin hedef metriğe oranıyla çarparak yeni replica ihtiyacını tahmin eder. Sonuç tam sayıya yukarı yuvarlanır. Örneğin dört Pod yüzde seksen CPU kullanırken hedef yüzde kırksa yaklaşık iki kat replica ihtiyacı ortaya çıkabilir. Gerçek controller hesaplarında hazır olmayan Pod'lar, eksik metric ve tolerance gibi ayrıntılar da devreye girer. Bu nedenle basit formül modeli anlamak için yararlıdır, fakat her production kararını birebir açıklamayabilir.

minReplicas

`minReplicas`, HPA'nın workload'u indirebileceği minimum replica sayısını belirler. Kritik web uygulamalarında sıfıra yakın kapasite yerine birkaç sıcak Pod tutmak cold start ve ani trafik riskini azaltır. Minimum değer availability zone sayısıyla da ilişkilendirilebilir. Üç zone kullanılan bir sistemde yalnızca iki replica tutmak zone dağılımı açısından istenmeyen sonuç yaratabilir. Maliyet optimizasyonu yapılırken minimum replica yalnızca ortalama trafik üzerinden değil, failure ve burst senaryoları üzerinden belirlenmelidir.

maxReplicas

`maxReplicas`, HPA'nın çıkabileceği replica sayısının üst sınırını belirler. Bu değer maliyet kontrolü sağlasa da gerçek peak kapasitenin altında seçilirse HPA doğru çalıştığı halde uygulama doygunluğa ulaşabilir. Üst sınır ayrıca node kapasitesi ve downstream bağımlılıkların kaldırabileceği connection sayısıyla uyumlu olmalıdır. Veritabanı yalnızca iki yüz bağlantı kaldırıyorsa yüzlerce Pod açmak problemi büyütebilir. Max replica belirlerken load test ve bağımlılık limitleri birlikte incelenmelidir.

Metrics

HPA CPU, memory, custom metrics ve external metrics gibi farklı kaynaklarla çalışabilir. Metric seçimi uygulamanın doygunluğunu en erken ve güvenilir biçimde haber veren sinyale dayanmalıdır. CPU bazı hesap ağırlıklı servislerde iyi çalışırken queue consumer için lag metriği daha anlamlı olabilir. Web API'de RPS veya concurrency kullanıcı talebini CPU'dan daha erken gösterebilir. Metric kolay ölçülüyor diye seçilmemeli, kapasite ihtiyacıyla gerçek nedensel ilişkisi test edilmelidir.

Scaling Behavior

HPA behavior alanı scale-up ve scale-down hızını ayrı ayrı yönetmeye olanak verir. Hızlı trafik artışında scale-up politikasının yeterince agresif olması gerekir. Buna karşılık scale-down genellikle daha kontrollü tutulur, çünkü kısa süreli metric düşüşlerinde kapasiteyi hemen azaltmak thrashing yaratabilir. Stabilization window geçmiş önerileri dikkate alarak düşüşü yumuşatır. İyi behavior ayarı load test sırasında spike, sustained load ve recovery senaryolarıyla bulunur.

Metrics Server Nedir?

Metrics Server, Kubernetes resource metrics API için Pod ve node CPU ile bellek kullanım verilerini sağlayan yaygın cluster bileşenidir. HPA resource metric kullanıyorsa bu API'nin erişilebilir olması gerekir. `kubectl top` komutları da bu verilerden yararlanabilir. Metrics Server uzun dönemli monitoring veritabanı olarak tasarlanmamıştır. Geçmiş trend ve ayrıntılı dashboard için Prometheus benzeri ayrı gözlemlenebilirlik sistemi kullanmak daha uygundur.

CPU Metric

CPU metric, container veya Pod CPU tüketimini ölçerek HPA için kaynak kullanım sinyali sağlayabilir. Utilization hedefi kullanıldığında CPU request değeri hesaplamanın paydasında yer alır. Yanlış request bu yüzden HPA'nın kararını doğrudan bozar. CPU-bound uygulamalarda metric talep ile iyi korelasyon gösterebilir. I/O bekleyen veya queue ağırlıklı sistemlerde ise CPU yükselmeden kullanıcı gecikmesi artabileceği için tek başına yeterli olmayabilir.

Memory Metric

Memory metric Pod veya container bellek kullanımını izler. HPA ile bellek bazlı ölçekleme yapılabilir, ancak bellek CPU gibi yük düştüğünde hızla serbest kalmayabilir. Cache ve garbage collection davranışı metriği uzun süre yüksek tutabilir. Memory leak bulunan uygulamada daha fazla Pod açmak problemi geçici olarak yayabilir. Bu nedenle memory metriğini kullanmadan önce uygulamanın bellek yaşam döngüsünü anlamak gerekir.

Metrics API

`metrics.k8s.io` resource metrics API, HPA'nın CPU ve memory gibi temel kaynak metriklerine ulaşmasını sağlar. Bu API genellikle Metrics Server tarafından sağlanır. Custom ve external metrics için farklı API yüzeyleri ve adapter bileşenleri kullanılabilir. HPA `unknown` metric gösteriyorsa APIService durumu ve metric endpoint erişimi kontrol edilmelidir. Autoscaling sorununun uygulamadan mı metrik pipeline'ından mı kaynaklandığını ayırmak için bu katmanı test etmek gerekir.

kubectl top

`kubectl top pods` ve `kubectl top nodes`, Metrics Server üzerinden anlık kaynak kullanım görünümü sunar. HPA sorununda metric pipeline'ın çalışıp çalışmadığını hızlı kontrol etmek için yararlıdır. Ancak kısa örnekleme penceresi ve geçmiş veri eksikliği nedeniyle production analizi için tek başına yeterli değildir. Pod bazında trend görmek için zaman serisi sistemi kullanılmalıdır. `kubectl top` bir ilk teşhis aracı olarak düşünüldüğünde oldukça faydalıdır.

Metrics Server Olmadan HPA Çalışır mı?

HPA'nın CPU veya memory resource metric kullanması için resource metrics API sağlayıcısına ihtiyaç vardır ve Metrics Server bu iş için en yaygın çözümdür. Ancak HPA yalnızca resource metrics ile sınırlı değildir. Custom metrics veya external metrics uygun adapter ve API ile sağlanıyorsa farklı metric türleri üzerinden ölçekleme yapılabilir. Yani “Metrics Server yoksa hiçbir HPA çalışmaz” demek doğru değildir. Kullanılan metric türünün hangi API'den geldiği açık biçimde anlaşılmalıdır.

Resource Requests HPA İçin Neden Kritiktir?

CPU utilization tabanlı HPA hesaplarında resource request değeri temel referanstır. Bir Pod 500m CPU request ile 250m tüketiyorsa yaklaşık yüzde elli utilization görülür, fakat aynı tüketim 100m request ile yüzde iki yüz elli olarak algılanır. Bu nedenle request değerleri yalnızca scheduler için değil autoscaling davranışı için de belirleyicidir. Çok düşük request aşırı ölçekleme, çok yüksek request ise geç scale-up oluşturabilir. Right-sizing çalışması yapılmadan HPA ayarlamak güvenilir sonuç üretmez.

CPU Request

CPU request, scheduler'ın Pod için ayırması gereken temel CPU ihtiyacını ifade eder. HPA utilization metriği bu değeri referans alır. Gerçek uygulama baz yükü 300m iken request 50m seçilirse normal trafik bile çok yüksek utilization gibi görünür. Sonuçta gereksiz replica artışı yaşanabilir. Load test ile farklı concurrency seviyelerinde Pod başına CPU tüketimini ölçmek daha gerçekçi request belirlemeye yardımcı olur.

Memory Request

Memory request scheduler'ın Pod yerleşimi için kullandığı temel bellek talebidir. Memory utilization tabanlı HPA kullanıldığında bu değer scaling hesabını da etkileyebilir. Request çok düşükse normal cache kullanımı sürekli yüksek utilization üretebilir. Çok yüksek request ise node packing verimliliğini düşürür ve daha erken node autoscaling gerektirebilir. Bu nedenle bellek request kararı hem Pod hem node maliyetini etkileyen bir ayardır.

Utilization Nasıl Hesaplanır?

Utilization, kullanılan kaynak miktarının request değerine oranlanmasıyla değerlendirilir. Örneğin 400m CPU request tanımlı Pod 200m tüketiyorsa yaklaşık yüzde elli CPU utilization oluşur. HPA hedefi yüzde altmış ise scale-up ihtiyacı henüz doğmayabilir. Request değerini değiştirmek aynı gerçek kullanım altında görünen utilization oranını değiştirir. Bu nedenle VPA'nın request önerileri ile CPU HPA birlikte kullanıldığında denominator etkisi dikkatle ele alınmalıdır.

Çok Düşük Request'in Etkisi

Request gerçeğin çok altındaysa scheduler node'lara gereğinden fazla Pod yerleştirebilir. Aynı zamanda CPU utilization yüzdesi hızlı yükseldiği için HPA gereksiz replica açabilir. Bu yeni Pod'lar node kapasitesini daha da zorlar ve node autoscaler daha fazla makine sağlayabilir. Sonuçta küçük bir request hatası tüm autoscaling zincirinde maliyet artışına dönüşebilir. Request değerleri load test ve production telemetrisiyle düzenli gözden geçirilmelidir.

Çok Yüksek Request'in Etkisi

Request gereğinden çok yüksek olduğunda scheduler Pod başına fazla kapasite ayırır ve node utilization düşük görünür. CPU utilization tabanlı HPA gerçek kullanım request'e oranlandığı için scale-up gecikebilir. Daha az Pod node'a sığacağı için node maliyeti de artabilir. Uygulama ortalama 200m kullanırken 2 CPU request verilmesi çoğu web servisi için verimsiz olabilir. Yine de başlangıç burst'leri ve latency hedefleri göz önünde tutularak güvenli pay bırakılmalıdır.

Hatalı Right-Sizing'in Autoscaling'e Etkisi

Yanlış right-sizing Pod, HPA ve node autoscaler davranışını aynı anda etkiler. Çok düşük değer gereksiz Pod ve node artışına, çok yüksek değer ise kapasite kullanımının düşmesine ve geç scale-up'a yol açabilir. VPA recommendation modu gerçek kullanım trendini anlamak için yardımcı olabilir. Ancak üretim kararları yalnızca ortalamaya göre verilmemelidir. Peak trafik, startup burst ve SLO hedefleri request belirleme sürecine dahil edilmelidir.

CPU-Based Autoscaling

CPU tabanlı autoscaling Kubernetes'te en kolay başlayan HPA modellerinden biridir. Metric pipeline basittir ve compute-bound uygulamalarda talep artışıyla güçlü korelasyon gösterebilir. Ancak CPU her workload için kullanıcı talebinin en erken sinyali değildir. I/O ağırlıklı API, queue consumer veya uzun bağlantılı servislerde latency ve queue metriği daha anlamlı olabilir. CPU seçimi yapılmadan önce yük testinde talep artışı ile CPU artışı arasındaki zaman ilişkisi incelenmelidir.

CPU Kullanımına Göre Replica Artırma

HPA mevcut CPU utilization değerini hedefle karşılaştırarak replica ihtiyacı hesaplayabilir. Hedef yüzde altmışsa ve mevcut ortalama uzun süre bunun üzerindeyse scale-up beklenir. Yeni Pod açıldığında toplam iş yükü daha fazla replica'ya bölünür. Ancak yeni Pod'un Ready olması zaman alıyorsa ilk Pod'lar scale-up tamamlanana kadar yüksek yük altında kalabilir. Scale-up behavior ve warm-up süresi bu geçişi güvenli hale getirecek şekilde ayarlanmalıdır.

Hangi Uygulamalar İçin Uygundur?

CPU talep ile yakın ilişki gösteren stateless web servisleri ve hesaplama ağırlıklı uygulamalar için iyi bir metric olabilir. Her ek istek doğrudan belirgin CPU tüketimi oluşturuyorsa HPA erken ve anlaşılır tepki verir. Pod'ların benzer CPU profiline sahip olması ortalama metric kullanımını da kolaylaştırır. Uzun request süreleri veya yoğun blocking I/O olduğunda korelasyon zayıflayabilir. Karar üretim öncesi load test grafikleriyle doğrulanmalıdır.

CPU'nun Kötü Bir Scaling Metric Olduğu Durumlar

Queue büyürken consumer CPU düşük kalabiliyorsa CPU metric geç sinyal verir. Benzer şekilde dış API veya veritabanı bekleyen servisler concurrency sınırına ulaşırken CPU kullanımı düşük olabilir. gRPC connection sayısı arttığında memory veya active request sayısı daha erken doygunluk gösterebilir. Bu senaryolarda yalnızca CPU ile scale etmek kullanıcı latency'si bozulduktan sonra reaksiyon verilmesine yol açar. Queue age, RPS, concurrency veya business KPI gibi metrikler değerlendirilmelidir.

Memory-Based Autoscaling

Bellek tabanlı autoscaling uygulamanın memory utilization değerine göre replica sayısını değiştirebilir. Ancak bellek kullanımının trafik düştüğünde hemen azalacağı varsayılmamalıdır. Runtime heap yönetimi, cache ve garbage collector davranışı belleği yüksek tutabilir. Bu nedenle memory HPA bazı uygulamalarda scale-down sinyalini geç üretir. CPU ile birlikte kullanıldığında HPA her metric için gereken replica sayısını hesaplayıp en yüksek ihtiyacı dikkate alabilir.

Memory Utilization

Memory utilization Pod'un bellek kullanımını request değerine göre değerlendirebilir. Request doğru ayarlanmamışsa scaling davranışı yanıltıcı olur. Cache kullanan uygulamalar kapasite boş olsa bile belleği serbest bırakmayabilir. Böyle bir durumda HPA sürekli yüksek replica sayısını koruyabilir. Bellek metric seçimi yapılırken working set davranışı ve runtime heap modeli gözlemlenmelidir.

Memory Leak Problemi

Memory leak bulunan uygulama zaman içinde sürekli daha fazla bellek tüketir. HPA bu artışı trafik kapasitesi ihtiyacı sanarak replica açabilir. Yeni Pod'lar da aynı leak davranışına sahipse problem yatay olarak çoğalır. Bu nedenle sürekli büyüyen memory trendi autoscaling ile gizlenmemelidir. Heap analizi, restart pattern ve uygulama düzeltmesi asıl çözüm olmalıdır.

Garbage Collection

Garbage collected runtime'larda heap boyutu ile aktif veri miktarı aynı olmayabilir. Runtime kullanılmayan belleği işletim sistemine hemen geri vermeyebilir. Bu durum HPA memory metriğini yüksek tutabilir. JVM veya benzeri runtime kullanan uygulamalarda GC pause ve heap occupancy ayrı izlenmelidir. Scaling kararını yalnızca tek bir memory yüzdesine bağlamak yerine kullanıcı yüküyle korelasyon kontrol edilmelidir.

CPU + Memory Kombinasyonu

HPA birden fazla metric tanımlandığında her metric için ayrı replica ihtiyacı hesaplayabilir. CPU dört replica, memory altı replica istiyorsa daha yüksek sayı olan altı tercih edilebilir. Bu yöntem iki farklı doygunluk riskini aynı politikada kapsar. Ancak memory sürekli yüksek kalıyorsa scale-down beklenenden daha geç olabilir. Metric kombinasyonları load test sırasında ayrı ayrı tetiklenerek davranış doğrulanmalıdır.

Custom Metrics ile HPA

Custom metrics, uygulamanın gerçek talep veya doygunluk sinyalini CPU ve bellek dışındaki verilerle ifade etmesini sağlar. Requests per second, active connections, queue depth, Kafka lag veya p95 latency gibi metrikler bu amaçla kullanılabilir. `autoscaling/v2` HPA bu tür metriklerle çalışabilir, fakat uygun metrics adapter altyapısı gerekir. Metric tanımı teknik olarak erişilebilir olduğu için değil, replica ihtiyacını erken tahmin ettiği için seçilmelidir. İyi custom metric kullanıcı deneyimi bozulmadan kapasite artışını başlatabilir.

CPU ve Memory Neden Her Zaman Yeterli Değildir?

CPU ve memory sistem kaynağı kullanımını ölçer, fakat kullanıcı talebini her zaman doğrudan ifade etmez. Bir servis dış veritabanını beklerken concurrency sınırına ulaşabilir ve CPU düşük kalabilir. Queue consumer mesaj birikmesine rağmen I/O beklediği için düşük CPU kullanabilir. Kullanıcı gecikmesi artmış olsa bile kaynak metriği scale-up eşiğine ulaşmayabilir. Bu yüzden talebe daha yakın metrikler bazı sistemlerde daha iyi scaling sinyali sağlar.

Requests Per Second

RPS, web servisinde gelen talebin doğrudan ölçüsüdür. Pod başına güvenli RPS kapasitesi load test ile biliniyorsa replica ihtiyacı daha tahmin edilebilir hale gelir. Örneğin bir Pod SLO sınırında 100 RPS taşıyorsa 900 RPS için yeterli güvenlik payıyla replica hesabı yapılabilir. CPU'nun yükselmesini beklemek yerine trafik gelir gelmez scale-up başlatılabilir. Ancak request maliyetleri birbirinden çok farklıysa tek başına toplam RPS yetersiz olabilir.

Active Connections

Active connection metriği WebSocket, gRPC veya uzun yaşayan TCP servislerinde değerli olabilir. Her Pod'un aynı anda güvenle taşıyabileceği bağlantı sayısı biliniyorsa kapasite metriğine dönüştürülebilir. HPA yeni Pod açtığında mevcut bağlantılar taşınmasa bile yeni bağlantılar yeni kapasiteye yönlenebilir. Bu yüzden bağlantı churn oranı sonucu etkiler. Connection count ile CPU ve memory doygunluğunu birlikte izlemek daha güvenli limit belirlemeye yardımcı olur.

Queue Depth

Queue depth işlenmeyi bekleyen iş miktarını gösterir ve event-driven workload'lar için güçlü bir sinyaldir. Queue büyümeye başladığında consumer CPU henüz yükselmemiş olabilir. Bu nedenle replica artışı daha erken tetiklenebilir. Ancak yalnızca mesaj sayısı değil, mesaj işleme süresi de önemlidir. On bin küçük mesaj ile on bin ağır iş aynı replica ihtiyacını oluşturmayabilir.

Kafka Consumer Lag

Kafka consumer lag, producer'ın ilerlediği offset ile consumer grubunun işlediği offset arasındaki farkı ifade eder. Lag büyüyorsa consumer kapasitesi gelen veri hızının gerisinde kalıyor olabilir. KEDA veya custom metric pipeline ile bu değer scaling sinyali olarak kullanılabilir. Replica sayısının partition sayısını aşması her zaman ek throughput sağlamaz. Bu nedenle maksimum faydalı replica sınırı Kafka partition topolojisiyle birlikte belirlenmelidir.

p95 Latency

p95 latency kullanıcıların büyük bölümünün deneyimini temsil eden önemli bir performans metriğidir. Yükselmeye başladığında sistem doygunluğunun doğrudan göstergesi olabilir. Ancak latency sonuç metriğidir ve scale-up başlatmak için bazen talep sinyallerinden daha geç gelir. HPA'yı doğrudan latency ile sürmek feedback loop açısından dikkatli test gerektirir. RPS veya concurrency ile birlikte SLO kontrol metriği olarak kullanmak çoğu durumda daha dengeli sonuç verir.

Business Metrics

Business metric sistem yükünü teknik kaynaklardan ziyade iş hacmi üzerinden ifade eder. Aktif sipariş sayısı, render kuyruğu veya eşzamanlı kullanıcı işlemi gibi metrikler kapasite ihtiyacına yakın olabilir. Teknik kaynak tüketimi işlem türüne göre değişiyorsa business metric daha anlamlı sinyal sağlayabilir. Metric pipeline'ın gecikmesi düşük ve güvenilir olmalıdır. Aksi halde autoscaling yanlış veya geç veri üzerinden karar verir.

Prometheus ile Kubernetes Autoscaling

Prometheus uygulama ve altyapı metriklerini zaman serisi olarak toplamak için Kubernetes ekosisteminde yaygın kullanılan açık kaynaklı çözümlerden biridir. Prometheus Adapter gibi bileşenlerle belirli sorgu sonuçları Kubernetes custom metrics API üzerinden HPA'ya sunulabilir. Böylece RPS, queue veya uygulamaya özgü metric ile scaling yapılabilir. KEDA da Prometheus sorgularını trigger olarak kullanabilir. Metric tanımında scrape aralığı, query window ve label cardinality gibi ayrıntılar scaling tepki süresini etkiler.

Prometheus

Prometheus servislerden metrik toplayıp zaman serisi olarak saklar ve PromQL ile sorgulanmasını sağlar. Uygulama RPS, latency, queue depth ve error rate gibi sinyalleri burada üretilebilir. Autoscaling için kullanılacak metric mümkün olduğunca düşük gecikmeli ve kararlı olmalıdır. Çok uzun query window ani trafik artışını yumuşatıp scale-up'ı geciktirebilir. Çok kısa pencere ise gürültülü veri nedeniyle gereksiz scaling hareketi oluşturabilir.

Prometheus Adapter

Prometheus Adapter, Prometheus'taki metrikleri Kubernetes custom veya external metrics API üzerinden HPA'nın erişebileceği biçimde sunabilir. Adapter kuralı metric isimlerini ve PromQL sorgularını Kubernetes API modeline eşler. Yanlış label mapping HPA'nın hedef workload için metric bulamamasına neden olabilir. `HPA unknown metric` sorununda adapter logları ve custom metrics API çıktısı kontrol edilmelidir. Metric pipeline'ın her katmanı ayrı doğrulanmalıdır.

Custom Metrics API

Custom Metrics API Kubernetes nesneleriyle ilişkili uygulama metriklerini HPA'ya sunmak için kullanılır. HPA bu API üzerinden Pod veya object metric değerlerini alabilir. API aggregation ve adapter kurulumu doğru yapılmadıysa metric erişimi başarısız olur. Bu durumda HPA replica artırmayabilir veya status alanında unknown değer gösterebilir. Monitoring sistemi metric görüyor diye HPA'nın da otomatik görebileceği varsayılmamalıdır.

PromQL

PromQL, Prometheus metriklerinden scaling sinyali üretmek için güçlü sorgular yazmayı sağlar. RPS için rate hesapları, queue metriği için toplam veya ortalama değerler kullanılabilir. Query'de yanlış aggregation yapmak tüm cluster trafiğini tek Deployment'a aitmiş gibi gösterebilir. Label filtreleri namespace ve workload seviyesinde açık tanımlanmalıdır. Scaling sorgusu dashboard sorgusundan daha kritik olduğu için değişiklikleri load test ile doğrulamak gerekir.

RPS Bazlı Scaling

RPS bazlı scaling gelen talebe doğrudan tepki vermeyi amaçlar. Pod başına güvenli request kapasitesi biliniyorsa hedef RPS değeri oluşturulabilir. Ani trafik spike'ında CPU yükselmeden replica artışı başlayabilir. Ancak yeni Pod warm-up süresi uzunsa metric erken olsa bile kapasite yetişmeyebilir. Pre-scaling veya minimum warm capacity bu durumda RPS metriğini tamamlayan araçlardır.

Latency Bazlı Scaling

Latency bazlı scaling kullanıcı deneyimini doğrudan göz önüne alır. p95 veya p99 yükseldiğinde replica artışı tetiklenebilir. Fakat latency yalnızca CPU doygunluğundan değil veritabanı, network veya downstream yavaşlığından da kaynaklanabilir. Böyle durumda daha fazla Pod açmak bağımlılığı daha fazla yükleyerek problemi artırabilir. Latency metric kullanılacaksa root cause ayrımı ve maksimum replica korumaları test edilmelidir.

Hangi Metric ile Scale Edilmeli?

Doğru scaling metriği, kapasite ihtiyacını kullanıcı etkisi oluşmadan önce haber veren ve replica artışıyla gerçekten iyileşen sinyaldir. CPU kolay erişilebilir olduğu için başlangıç noktası olabilir, fakat her sistemin cevabı değildir. RPS, concurrency, queue length ve queue age birçok workload'da talebe daha doğrudan bağlanır. Latency ve error rate SLO açısından güçlü doğrulama metrikleridir. Metric seçimi load test, production telemetrisi ve uygulamanın gerçek darboğazı üzerinden yapılmalıdır.

CPU

CPU hesaplama ağırlıklı uygulamalarda iyi bir scaling metriğidir. Pod başına CPU tüketimi trafikle düzenli artıyorsa HPA davranışı anlaşılır olur. Resource request değerlerinin gerçekçi olması gerekir. Blocking I/O veya dış servis bekleme yoğunluğu arttıkça CPU talep sinyali olarak zayıflar. Bu yüzden CPU metric seçimi korelasyon grafikleriyle doğrulanmalıdır.

Memory

Memory uygulamanın çalışma seti trafikle artıyorsa faydalı bir sinyal olabilir. Ancak cache ve runtime heap davranışı scale-down'ı geciktirebilir. Memory leak bulunan sistemde HPA problemi gizleyebilir. Request değeri yanlışsa utilization yüzdesi de yanlış yorumlanır. Bellek metriğini tek başına kullanmak yerine memory pressure ve uygulama davranışını birlikte incelemek gerekir.

RPS

RPS web servisindeki gelen iş hacmini doğrudan gösterir. Pod başına kapasite iyi biliniyorsa replica ihtiyacıyla güçlü ilişki kurulabilir. Farklı endpoint'lerin işlem maliyeti çok değişiyorsa ağırlıklı request metriği daha doğru olabilir. RPS spike'ı Pod CPU'sundan önce görüldüğü için hızlı scale-up sağlar. Yeni Pod hazırlık süresi yine de toplam tepki süresini belirler.

Concurrency

Concurrency aynı anda işlenen request veya task sayısını gösterir. Worker pool veya connection limiti olan servislerde doygunluğu CPU'dan daha iyi yansıtabilir. Pod başına güvenli concurrency sınırı load test ile bulunabilir. HPA yeni Pod eklediğinde yeni talepler daha fazla worker kapasitesine dağıtılır. Uzun request'lerde concurrency metriği özellikle değerlidir.

Queue Length

Queue length bekleyen iş miktarını gösterir. Consumer kapasitesi yetersiz olduğunda kuyruk büyür ve erken scale-up sinyali verir. Mesaj boyutu ve işlem süresi değişkense yalnızca toplam mesaj sayısı yeterli olmayabilir. Kuyruk metriği KEDA gibi event-driven araçlarla doğal biçimde kullanılabilir. Maximum replica değeri downstream sistemlerin kaldırabileceği tüketim hızıyla sınırlanmalıdır.

Queue Age

Queue age en eski bekleyen işin ne kadar süredir tamamlanmadığını ölçebilir. Bu metrik kullanıcı veya iş SLO'suna queue length'ten daha yakın olabilir. Kuyruk kısa olsa bile tek ağır mesaj uzun süre bekliyorsa age yükselir. Scaling kararında queue length ile birlikte kullanıldığında daha güçlü bir resim sunar. Batch ve asynchronous iş sistemlerinde özellikle yararlıdır.

Latency

Latency kullanıcı deneyiminin en doğrudan ölçülerinden biridir. p95 veya p99 değerleri tail latency sorunlarını görünür hale getirir. Ancak gecikme birçok bağımlılıktan etkilenebildiği için her yükseliş daha fazla replica gerektirmez. Veritabanı doygunsa Pod eklemek latency'yi daha da artırabilir. Bu nedenle latency çoğu zaman scaling metriği yanında koruyucu SLO metriği olarak kullanılır.

Business KPI

Business KPI uygulama kapasitesini gerçek iş hacmiyle ilişkilendirebilir. İşlenen sipariş, render işi veya aktif oturum gibi değerler teknik metriklerden daha anlaşılır olabilir. Ancak bu KPI'nın replica artışıyla nedensel ilişkisinin olması gerekir. Gelir düşüşü gibi çok dolaylı bir metric autoscaling için uygun değildir. En iyi business scaling sinyali kısa sürede ölçülebilen ve kapasite ihtiyacını doğrudan gösteren metriktir.

En Erken Talep Sinyalini Seçmek

Autoscaling reaktif bir kontrol döngüsü olduğu için sinyal ne kadar erken gelirse yeni kapasiteyi hazırlamak için o kadar fazla zaman kazanılır. CPU kullanıcı yükünden birkaç saniye sonra yükseliyorsa RPS daha erken sinyal olabilir. Queue consumer'da lag, kullanıcı gecikmesinden önce artabilir. Ancak erken metric gürültülü veya tahmin edilemezse gereksiz scale-up oluşturur. Amaç en erken görünen değil, kapasite ihtiyacını en erken ve güvenilir biçimde temsil eden metriği seçmektir.

HPA Multiple Metrics Nasıl Çalışır?

HPA `autoscaling/v2` ile birden fazla metric üzerinden aynı workload'u değerlendirebilir. Controller her metric için ayrı desired replica hesabı yapar. Ardından genel olarak en yüksek replica ihtiyacı seçilir, böylece farklı doygunluk türlerinden biri kapasite artışı isteyebilir. Bu model CPU ile RPS veya CPU ile memory gibi kombinasyonları mümkün kılar. Metric pipeline'lardan biri hata verdiğinde scale-down davranışı güvenlik amacıyla sınırlanabileceği için status ve event'ler izlenmelidir.

CPU + Memory

CPU ve memory birlikte kullanıldığında iki kaynak doygunluğu aynı HPA içinde izlenebilir. CPU daha fazla replica isterse CPU hesabı, memory daha fazla isterse memory hesabı belirleyici olabilir. Bu yaklaşım memory yoğun bazı trafik örüntülerini yakalayabilir. Bununla birlikte memory yüksekliği cache nedeniyle kalıcıysa scale-down gecikebilir. Her iki metric için request değerlerinin doğru olması kritik önemdedir.

CPU + RPS

CPU ile RPS birlikte kullanmak hem sistem kaynağı hem talep sinyalini kapsar. RPS ani trafik artışını erken görürken CPU beklenenden daha pahalı request türlerinde ek güvenlik sağlayabilir. HPA daha yüksek replica ihtiyacını seçtiği için iki metric birbirini koruyabilir. RPS metriğinin adapter pipeline'ı güvenilir olmalıdır. Load testte yalnızca yüksek RPS değil, düşük RPS altında CPU-heavy request senaryosu da denenmelidir.

Birden Fazla Metric İçin Replica Hesabı

Her metric kendi hedefiyle karşılaştırılarak replica ihtiyacı hesaplanır. CPU beş, RPS sekiz ve memory altı replica öneriyorsa sistem en yüksek ihtiyacı dikkate alabilir. Bu davranış kapasite yetersizliğini farklı sinyallerden herhangi birinin tetiklemesine izin verir. Ancak çok gürültülü tek metric sürekli gereksiz replica artışı oluşturabilir. Metric kalitesi bu yüzden sayı arttıkça daha da önemli hale gelir.

En Yüksek Replica İhtiyacının Seçilmesi

En yüksek replica ihtiyacının seçilmesi availability açısından koruyucu bir yaklaşımdır. Bir metric uygulamanın doygunluğunu gösterirken diğerleri normal olsa bile kapasite artırılabilir. Scale-down ise metric hataları veya stabilization nedeniyle daha ihtiyatlı gerçekleşebilir. Bu davranış kısa süreli fazla kapasite pahasına kullanıcı etkisini azaltmaya yardımcı olur. Maliyet hassas sistemlerde gürültülü metric'ler ayıklanmalı ve her metriğin gerçek faydası düzenli gözden geçirilmelidir.

HPA Scaling Behavior Nasıl Ayarlanır?

HPA behavior alanı replica artış ve azalış hızını kontrol etmenizi sağlar. Ani talepte hızlı scale-up, kısa süreli düşüşte ise daha yavaş scale-down çoğu web servisi için güvenli başlangıçtır. Policy değerleri sabit Pod sayısı veya yüzde değişim üzerinden tanımlanabilir. Stabilization window önceki önerileri belirli süre dikkate alarak dalgalanmayı azaltır. En iyi değerler tahminle değil, gerçek startup süresi ve load test sonuçlarıyla bulunmalıdır.

Scale-Up Policy

Scale-up policy belirli zaman penceresinde replica sayısının ne kadar artırılabileceğini sınırlar. Trafik spike'ı çok hızlıysa aşırı muhafazakâr değer kullanıcı latency'sini yükseltebilir. Çok agresif artış ise aynı anda çok sayıda Pod'un image çekmesine ve bağımlılıklara yük bindirmesine neden olabilir. Node kapasitesi de replica artış hızını karşılayabilmelidir. Scale-up politikası uygulama warm-up süresi ve node provisioning süresiyle uyumlu tasarlanmalıdır.

Scale-Down Policy

Scale-down policy kapasitenin hangi hızda azaltılacağını belirler. Talep kısa süreli düştüğünde hemen çok sayıda Pod kapatmak trafik geri döndüğünde yeni cold start oluşturur. Ayrıca çok hızlı termination aktif bağlantılarda hata riskini artırabilir. Bu nedenle scale-down çoğu production servisinde scale-up'tan daha yavaş tutulur. Maliyet ile warm capacity arasında uygulama SLO'suna uygun denge kurulmalıdır.

Stabilization Window

Stabilization window, geçmiş scale önerilerini belirli süre boyunca dikkate alarak ani karar değişikliklerini yumuşatır. HPA scale-down için varsayılan olarak koruyucu bir pencere kullanabilir. Metric birkaç örnek boyunca düşüp tekrar yükseliyorsa kapasitenin hemen azaltılması engellenebilir. Bu yaklaşım thrashing riskini azaltır. Pencere çok uzun olursa gereksiz maliyet, çok kısa olursa sık replica değişimi oluşabilir.

Replica Artış Hızı

Replica artış hızı uygulamanın yeni kapasiteyi ne kadar hızlı hazırlayabildiğiyle bağlantılıdır. Pod 30 saniyede hazır oluyorsa her kontrol döngüsünde az miktarda artış yoğun spike'a yetişmeyebilir. Buna karşılık yüzlerce Pod'u aynı anda başlatmak registry ve scheduler üzerinde yüksek yük oluşturabilir. En doğru hız load testte farklı spike profilleriyle ölçülür. Ready replica eğrisi desired replica eğrisiyle birlikte incelenmelidir.

Replica Azalış Hızı

Replica azalış hızı trafik düşüşünden sonra ne kadar warm kapasite tutulacağını belirler. Çok hızlı azalma dalgalı trafikte sürekli yeniden scale-up oluşturabilir. Bu durum hem latency hem image pull ve node churn maliyetini artırır. Çok yavaş azalma ise düşük trafik dönemlerinde gereksiz kaynak tüketir. İş yükünün trafik periyodu ve Pod startup süresi bu karar için temel girdilerdir.

Scaling Thrashing Nedir?

Scaling thrashing, sistemin kısa aralıklarla tekrar tekrar scale-up ve scale-down yapmasıdır. Metric hedef çevresinde dalgalandığında veya stabilization yetersiz olduğunda görülebilir. Pod açma ve kapatma işlemleri uygulama ve cluster üzerinde ek yük oluşturur. Node autoscaler da aynı dalgalanmayı takip ederse altyapı churn'ü büyüyebilir. Tolerance, stabilization window ve daha kararlı metric seçimi bu problemi azaltmak için birlikte kullanılabilir.

Sürekli Scale-Up ve Scale-Down

Replica sayısının birkaç dakikada bir artıp azalması normal trafik değişiminden daha hızlıysa thrashing ihtimali vardır. Bu davranış dashboard'da testere dişi görünüm oluşturabilir. Her scale-up yeni Pod warm-up maliyeti getirir ve her scale-down aktif bağlantıları taşımak zorunda bırakır. Node seviyesine yansıdığında cloud kaynakları sürekli açılıp kapanabilir. Böyle bir durumda metric, target ve behavior parametreleri birlikte incelenmelidir.

Metric Dalgalanması

Çok kısa örnekleme pencereli veya düşük trafik hacmindeki metrikler hızlı dalgalanabilir. HPA hedefi tam bu dalgalanmanın ortasındaysa her kontrol döngüsü farklı karar üretebilir. Metric smoothing veya daha anlamlı aggregation kullanmak faydalı olabilir. Ancak aşırı smoothing de gerçek spike'ı gizleyebilir. Amaç metric'i düzleştirmek değil, kapasite ihtiyacını kararlı şekilde temsil etmektir.

Stabilization Window

Stabilization window özellikle scale-down kararlarının çok hızlı uygulanmasını önler. Trafik birkaç dakika içinde tekrar yükselecekse yüksek replica önerisini bir süre korumak faydalıdır. Bu yaklaşım Pod churn'ünü azaltır. Uygulama startup süresi uzadıkça daha uzun warm kapasite penceresi anlamlı olabilir. Pencere ayarı trafik örüntüsüne göre düzenli değerlendirilmelidir.

Tolerance

Tolerance, metric hedef değerine çok yakınken küçük farkların scaling tetiklemesini engelleyen bir ölü bölge gibi düşünülebilir. Böylece yüzde altmış hedef çevresindeki küçük ölçüm değişiklikleri sürekli replica değişimi oluşturmaz. Uygun tolerance gürültülü metric'lerde faydalıdır. Çok geniş tolerance gerçek kapasite ihtiyacına geç yanıt verilmesine neden olabilir. Değer seçimi metric değişkenliği ve SLO hassasiyetiyle uyumlu olmalıdır.

Hysteresis

Hysteresis, scale-up ve scale-down kararları arasında bilinçli bir fark veya gecikme oluşturarak kontrol döngüsünü kararlı hale getirmeyi amaçlar. HPA behavior ve stabilization ayarları bu amaca hizmet edebilir. Trafik yükseldiğinde hızlı reaksiyon, düştüğünde daha sabırlı davranış yaygın bir modeldir. Bu asimetri kısa süreli fazla kapasite tutar, fakat kullanıcı latency'sini koruyabilir. Maliyet hesabında bu warm kapasitenin değeri SLO ihlali maliyetiyle karşılaştırılmalıdır.

Thrashing'in Maliyet ve Availability Etkisi

Thrashing yalnızca gereksiz cloud maliyeti oluşturmaz, aynı zamanda availability riskini artırır. Sık Pod termination aktif bağlantıların kesilmesine ve cache'in sürekli yeniden ısınmasına yol açabilir. Node churn image pull ve scheduler baskısını artırabilir. Sistem normal trafikte bile sürekli geçiş durumunda kalır. Bu nedenle replica değişim frekansı gözlemlenebilirlik dashboard'unda temel operasyon metriği olarak izlenmelidir.

Pod Warm-Up Autoscaling'i Nasıl Etkiler?

Pod warm-up süresi HPA'nın yeni replica istemesi ile gerçek kapasitenin hizmete girmesi arasındaki gecikmeyi belirler. JVM başlatma, cache doldurma, model yükleme ve bağlantı havuzu oluşturma bu süreyi uzatabilir. HPA çok hızlı replica açsa bile Pod'lar uzun süre Ready değilse kullanıcı kapasitesi artmaz. Readiness probe yeni Pod'un erken trafik almasını engellerken startup probe yavaş başlayan uygulamalarda sağlık kontrolünü daha doğru yönetebilir. Bu yüzden autoscaling SLA hesabına Pod creation değil Ready ve ilk başarılı request zamanı dahil edilmelidir.

Startup Süresi

Startup süresi container'ın başlatılmasından uygulamanın gerçek trafik almaya hazır hale gelmesine kadar geçen zamanı ifade eder. On saniyelik startup ile iki dakikalık startup aynı HPA behavior ayarını gerektirmez. Ani spike'ta uzun startup süresi reactive autoscaling'in yetişmesini zorlaştırır. Minimum replica veya scheduled pre-scaling kullanmak bu açığı kapatabilir. Startup süresi her release'te performans regression metriği olarak ölçülmelidir.

JVM Warm-Up

JVM tabanlı uygulamalarda process başladıktan sonra JIT compilation, class loading ve connection initialization devam edebilir. Pod Ready işareti bu işlemler tamamlanmadan verilirse ilk kullanıcılar daha yüksek latency görebilir. Startup veya readiness probe gerçek hizmet kalitesine yakın sinyal vermelidir. HPA CPU hesaplarında yeni ve henüz hazır olmayan Pod'ların davranışı ayrıca dikkate alınabilir. JVM servislerinde scale test yalnızca steady-state değil cold start performansını da ölçmelidir.

Cache Warm-Up

Yeni Pod'un local cache'i boş olduğunda ilk request'ler daha fazla veritabanı veya downstream çağrısı oluşturabilir. HPA aynı anda çok sayıda Pod açarsa cache miss oranı sistem genelinde sıçrayabilir. Bu durum backend veritabanının aniden daha fazla yük almasına neden olur. Kademeli scale-up veya kontrollü pre-warming bazı sistemlerde daha güvenlidir. Cache warm-up metriği application dashboard'unda ayrı izlenirse bu etki daha kolay görülür.

Model Loading

AI inference workload'larında model dosyasının diskten veya object store'dan yüklenmesi dakikalar sürebilir. GPU belleğine model aktarımı da startup süresini uzatır. HPA veya KEDA replica istediğinde bu gecikme sırasında gerçek inference kapasitesi artmaz. Büyük model servislerinde pre-warmed replica ve node kapasitesi bu yüzden önemlidir. Scale-to-zero maliyet avantajı sunabilir, fakat ilk isteğin kabul edilebilir latency sınırını aşmasına yol açabilir.

Yeni Pod'un Erken Trafik Alması

Pod process'i açılır açılmaz trafik alırsa henüz hazır olmayan bağımlılıklar 5xx veya timeout üretebilir. Readiness probe bu problemi önlemek için kullanılır. Probe yalnızca process alive kontrolü yapıyorsa gerçek hazırlık durumu gözden kaçabilir. Uygulama cache, bağlantı havuzu veya kritik config hazırlığını tamamladıktan sonra Ready olmalıdır. Yine de probe içine yavaş harici bağımlılık kontrollerini aşırı eklemek yanlış negatif sonuçlar oluşturabileceği için tasarım dengeli olmalıdır.

Startup Probe ve Readiness Probe

Startup probe yavaş başlayan uygulamanın başlangıç sürecini liveness kontrollerinden ayırmaya yardımcı olur. Readiness probe ise Pod'un trafik almaya hazır olup olmadığını bildirir. Bu iki probe farklı problemlere hizmet eder ve birbirinin yerine kullanılmamalıdır. Autoscaling sırasında yeni Pod'ların doğru zamanda endpoint olması için readiness davranışı özellikle kritiktir. Probe timeout, threshold ve period değerleri gerçek startup ölçümleri üzerinden ayarlanmalıdır.

Readiness Probe ile Load Balancing Arasındaki İlişki

Readiness probe uygulamanın trafik almaya uygun olup olmadığını load balancing katmanına yansıtan temel Kubernetes mekanizmalarından biridir. Ready olmayan Pod normal Service endpoint akışında yeni istekler için kullanılmamalıdır. HPA replica açtığında Pod sayısı artmış görünse bile readiness tamamlanmadan gerçek kapasite artmayabilir. Yanlış probe değerleri hem fazla hata hem eksik kapasite oluşturabilir. Bu nedenle HPA dashboard'unda desired replicas ile Ready replicas ayrı izlenmelidir.

Pod Ne Zaman Endpoint Olur?

Service selector ile eşleşen Pod backend kümesine dahil edilir, ancak readiness durumu trafiğe uygunluk açısından belirleyicidir. Pod çalışıyor görünse bile Ready değilse normal Service trafiği için kullanılmaması beklenir. Bu ayrım yeni rollout ve autoscaling sırasında önemlidir. EndpointSlice koşulları Pod'un yaşam döngüsü bilgisini ağ bileşenlerine taşır. Scale-up performansını ölçerken Ready olma zamanını temel kilometre taşı olarak kullanmak gerekir.

Hazır Olmayan Pod'a Trafik Gönderilmesini Önleme

Readiness probe gerçek uygulama hazırlığını kontrol ederek erken trafik riskini azaltır. Örneğin API process'i dinleme portunu açmış olsa bile gerekli config yüklenmemiş olabilir. Probe ancak başarılı istek karşılanabilecek durumda başarılı olmalıdır. Bununla birlikte tek bir yavaş downstream çağrısını doğrudan readiness'e bağlamak zincirleme kapasite kaybı yaratabilir. Probe tasarımı dependency failure davranışını iyi anlamayı gerektirir.

Yanlış Readiness Probe'un Autoscaling'e Etkisi

Readiness sürekli başarısız olursa HPA replica artırmasına rağmen yeni Pod'lar trafik alamaz. Mevcut Pod'ların yükü yüksek kalır ve HPA daha fazla replica isteyebilir. Sonuçta çok sayıda Running fakat Unready Pod görülebilir. Tersi durumda probe erken başarılı olursa cold Pod'lar kullanıcı isteği alıp hata üretebilir. Autoscaling troubleshooting sırasında probe event'leri ve uygulama logları bu yüzden birlikte incelenmelidir.

Graceful Shutdown ve Connection Draining

Scale-down sırasında Pod'u hemen öldürmek aktif isteklerin yarıda kesilmesine yol açabilir. Graceful shutdown uygulamanın termination sinyalini alıp yeni iş kabulünü azaltmasını ve mevcut işleri tamamlamasını sağlar. Kubernetes termination grace süresi bu kapanış için zaman tanır. Endpoint'in trafikten çıkarılması ile process'in kapanması arasında doğru sıra oluşturulmalıdır. Özellikle uzun request veya WebSocket bağlantısı olan uygulamalarda bu tasarım 5xx oranını doğrudan etkiler.

SIGTERM

Kubernetes container kapatma sürecinde uygulamaya SIGTERM gönderebilir. Uygulama bu sinyali yakalayıp yeni request kabulünü durdurmalı ve aktif işleri tamamlamaya çalışmalıdır. SIGTERM'i yok sayan process grace süresi sonunda zorla kapatılabilir. Bu durumda aktif kullanıcı bağlantıları kesilebilir. Uygulama framework'ünün graceful shutdown desteği production öncesinde gerçek termination testiyle doğrulanmalıdır.

terminationGracePeriodSeconds

`terminationGracePeriodSeconds`, Pod'un zorla kapatılmadan önce graceful shutdown için sahip olduğu süreyi belirler. Değer uygulamanın en uzun kabul edilebilir request süresiyle uyumlu olmalıdır. Çok kısa süre uzun işlemleri yarıda keser. Çok uzun süre ise rollout ve node drain işlemlerini gereksiz uzatabilir. Gerçek request duration dağılımı ve shutdown metriği bu değeri belirlemek için kullanılmalıdır.

PreStop Hook

PreStop hook termination sırasında uygulamadan önce belirli bir işlem çalıştırmak için kullanılabilir. Bazı sistemlerde trafiğin upstream katmanlarda azalması için kısa gecikme veya uygulamaya özel drain komutu burada uygulanır. Ancak rastgele sleep eklemek problemi anlamadan gecikme yaratabilir. Endpoint propagation süresi ölçülerek ihtiyaç doğrulanmalıdır. Uygulamanın kendi SIGTERM handling'i çoğu zaman ana graceful shutdown mekanizması olmalıdır.

Endpoint'in Trafikten Çıkarılması

Pod termination başladığında endpoint durumunun ağ katmanına yansıması gerekir. Yeni isteklerin kapanmakta olan Pod'a gönderilmesi azaltılırken mevcut bağlantıların bitmesine fırsat tanınır. Bu değişiklik tüm proxy ve load balancer katmanlarına anında ulaşmayabilir. Kısa propagation penceresi production'da 5xx üretebilir. Scale-down testinde termination zamanı ile son yeni request zamanı arasındaki fark ölçülmelidir.

Uzun Süren Request'ler

Uzun inference, export veya rapor request'leri graceful shutdown süresini artırabilir. Pod termination başladığında bu request'lerin tamamlanması için yeterli grace period gerekir. Aksi halde kullanıcı timeout veya bağlantı kesilmesi görür. Çok uzun request'leri synchronous tutmak yerine job veya queue modeline taşımak bazı sistemlerde daha güvenlidir. Autoscaling tasarımı request yaşam süresiyle birlikte değerlendirilmelidir.

Scale-Down Sırasında 5xx Hatalarını Önlemek

Scale-down kaynaklı 5xx hatalarını azaltmak için readiness, endpoint removal ve graceful shutdown sıralamasını birlikte test etmek gerekir. Uygulama önce yeni trafik kabulünü durdurmalı, mevcut istekleri tamamlamalı ve grace süresi içinde kapanmalıdır. Gateway veya load balancer connection draining ayarları da bu süreçle uyumlu olmalıdır. PDB node drain sırasında kullanılabilir replica sayısının aşırı düşmesini engellemeye yardımcı olabilir. Load testte aktif trafik varken manuel Pod silme senaryosu uygulanması gerçek sorunları erken gösterir.

Long-Lived Connection'larda Load Balancing

WebSocket, HTTP/2 ve gRPC gibi uzun yaşayan bağlantılarda load balancing klasik kısa HTTP request'lerinden farklı davranır. Load balancer çoğu zaman bağlantı kurulurken backend seçer ve aynı bağlantı üzerindeki sonraki trafik aynı Pod'a gitmeye devam eder. HPA yeni Pod eklediğinde mevcut bağlantılar otomatik olarak yeniden dağıtılmaz. Böylece yeni Pod'lar düşük yükte kalırken eski Pod'lar yoğun olabilir. Connection age, client reconnect davranışı ve Pod bazlı active connection metriği bu workload'larda temel tasarım girdileridir.

WebSocket

WebSocket bağlantıları dakikalar veya saatler boyunca açık kalabilir. Bağlantı kurulduktan sonra istemci genellikle aynı backend ile iletişime devam eder. Yeni replica açılması mevcut socket'leri yeni Pod'a taşımaz. Bu yüzden HPA yalnızca CPU ile çalıştığında eski Pod'ların yükü dengelenmeyebilir. Active connection veya connection age metrikleri capacity planning için daha anlamlı olabilir.

HTTP/2

HTTP/2 tek TCP bağlantısı üzerinde çok sayıda stream taşıyabilir. Bu özellik bağlantı sayısını azaltırken backend load balancing davranışını daha bağlantı odaklı hale getirebilir. Bir client veya proxy uzun süre aynı backend connection'ını kullanırsa yeni Pod'lar düşük trafik alabilir. Gateway connection pool davranışı bu nedenle önemlidir. Scale testte sadece toplam RPS değil backend başına HTTP/2 connection dağılımı da incelenmelidir.

gRPC

gRPC sıklıkla HTTP/2 üzerinde uzun yaşayan channel'lar kullanır. Client bir connection açıp çok sayıda RPC'yi aynı backend'e gönderebilir. Yeni replica geldiğinde mevcut channel otomatik olarak yeniden dengelenmeyebilir. gRPC client-side load balancing veya proxy connection yönetimi bu sorunu etkiler. HPA tasarımında active RPC ve connection metriği CPU'nun yanında değerli olabilir.

Connection-Level Load Balancing

Connection-level load balancing backend seçimini yeni bağlantı kurulurken yapar. Bir bağlantı üzerinde binlerce request taşınırsa request dağılımı ile connection dağılımı aynı olmayabilir. Bu yüzden eşit connection sayısı eşit CPU anlamına gelmez. Uzun yaşayan ve farklı trafik hacmi taşıyan bağlantılar büyük dengesizlik oluşturabilir. Pod bazında request throughput ile active connection metriğini birlikte izlemek gerekir.

Yeni Pod'ların Trafik Alamaması Problemi

HPA yeni replica oluşturduğunda Service endpoint listesi güncellenebilir, fakat mevcut client connection'ları aynı backend'lerde kalabilir. Sonuç olarak yeni Pod Ready olmasına rağmen çok az gerçek trafik görür. Bu durum “HPA çalıştı ama performans düzelmedi” şeklinde algılanabilir. Connection churn düşükse ölçekleme etkisinin görünmesi uzun sürebilir. Gateway veya client connection lifetime ayarları kontrollü rebalancing için değerlendirilebilir.

Connection Age ve Rebalancing

Maximum connection age bazı sistemlerde bağlantıların belirli sürede yenilenmesini sağlayarak yeni backend'lerin trafiğe katılmasını kolaylaştırır. Çok kısa süre ise gereksiz handshake ve reconnect yükü oluşturabilir. TLS ve authentication maliyeti bu kararı etkiler. gRPC ve WebSocket sistemlerinde graceful reconnect davranışı uygulama açısından test edilmelidir. Amaç sürekli bağlantı kesmek değil, autoscaling kapasitesinin zaman içinde kullanılmasını sağlayacak makul churn oluşturmaktır.

Vertical Pod Autoscaler (VPA) Nedir?

VPA, workload'ların CPU ve bellek ihtiyaçlarını gözlemleyerek daha uygun resource request değerleri konusunda öneri üreten Kubernetes autoscaling yaklaşımıdır. Yapı genellikle Recommender, Updater ve Admission Controller bileşenleri etrafında düşünülür. Recommendation modunda Pod'ları değiştirmeden yalnızca tavsiye değerleri izlenebilir. Otomatik güncelleme modlarında Pod yeniden oluşturma etkisi oluşabileceği için availability planı önemlidir. VPA özellikle right-sizing çalışmasında güçlüdür, ancak CPU utilization HPA ile aynı resource request değerleri üzerinde kontrol çatışması oluşmamasına dikkat edilmelidir.

VPA Recommender

Recommender geçmiş ve mevcut kaynak kullanımını değerlendirerek CPU ile memory request önerileri üretir. Bu öneriler gerçek uygulama davranışını anlamak için değerli bir veri kaynağıdır. Recommendation-only kullanım production'da düşük riskli bir başlangıç sunar. Öneri değerleri peak trafik ve startup davranışıyla birlikte incelenmelidir. Sadece uzun dönem ortalamasına göre request düşürmek yoğun saatlerde performans kaybı oluşturabilir.

Updater

Updater mevcut Pod'ların önerilen kaynak değerlerine geçmesi gerektiğinde eviction sürecine katkı sağlayabilir. Resource request çalışan Pod üzerinde her durumda doğrudan değiştirilemediği için yeniden oluşturma gerekebilir. Bu işlem rollout etkisi yaratır. PDB ve minimum replica değerleri availability açısından önem kazanır. Kritik workload'larda update davranışı production öncesinde kontrollü ortamda test edilmelidir.

Admission Controller

VPA Admission Controller yeni oluşturulan Pod'lara önerilen resource değerlerini uygulama sürecinde rol alabilir. Böylece workload manifestindeki statik değerler yerine hesaplanan öneriler Pod creation aşamasında kullanılabilir. Bu davranış scheduler'ın placement kararını doğrudan etkiler. Resource değerinin beklenmedik büyümesi Pod'u Pending bırakabilir. VPA limit ve policy ayarları bu nedenle node kapasitesiyle birlikte tasarlanmalıdır.

CPU/Memory Right-Sizing

Right-sizing Pod'un güvenli performans için gerçekten ihtiyaç duyduğu CPU ve memory request değerlerini bulma sürecidir. Gereğinden yüksek request node kapasitesini boşa harcar, düşük request ise throttling veya OOM riskini artırabilir. HPA utilization hesabı da CPU request değerinden etkilenir. VPA önerileri başlangıç verisi sağlayabilir. Nihai değerler load test, SLO ve production peak telemetrisiyle doğrulanmalıdır.

Recommendation Mode

Recommendation mode workload üzerinde otomatik resource değişikliği yapmadan önerileri gözlemlemeyi sağlar. Production'a VPA eklemek için güvenli bir ilk aşamadır. Birkaç günlük veya haftalık trafik profili sonunda öneri trendleri incelenebilir. Hafta sonu veya düşük trafik verisine göre karar verilmemelidir. Kampanya ve peak dönemleri kapsayan yeterli gözlem penceresi kullanılmalıdır.

Automatic Update

Automatic update VPA önerilerinin Pod kaynaklarına uygulanmasını otomatik hale getirebilir. Bu süreç Pod recreation veya eviction etkisi oluşturabileceği için availability planına dahil edilmelidir. HPA ile aynı CPU request sinyali üzerinde çalışıyorsa beklenmeyen feedback loop oluşabilir. Stateful workload'larda restart maliyeti ayrıca daha yüksektir. Otomatik mod kullanılmadan önce recommendation davranışını gözlemek ve güvenli sınırlar tanımlamak daha doğru olur.

HPA ve VPA Birlikte Kullanılır mı?

HPA ile VPA birlikte kullanılabilir, ancak aynı resource metriğini birbirini etkileyen şekilde yönetmek risklidir. CPU utilization HPA, request değerini payda olarak kullanırken VPA bu request değerini değiştirirse HPA'nın gördüğü utilization oranı da değişir. Bu durum iki kontrol döngüsünün birbirine tepki vermesine neden olabilir. Daha güvenli modellerden biri VPA'yı recommendation modunda kullanmak veya HPA'yı RPS gibi custom metric üzerinden çalıştırmaktır. Production tasarımında hangi controller'ın hangi değişkeni yönettiği açıkça tanımlanmalıdır.

CPU/Memory Metric Çakışması

HPA CPU utilization ile replica sayısını değiştirirken VPA aynı Pod'ların CPU request değerini değiştirirse iki mekanizma aynı ölçüm alanını etkiler. Request yükseldiğinde aynı gerçek CPU kullanımı daha düşük utilization olarak görünür. HPA replica azaltabilir ve VPA daha sonra tekrar farklı öneri verebilir. Bu feedback davranışı kararsız sonuçlar doğurabilir. Aynı resource metriğinde iki otomatik controller kullanmadan önce resmi kullanım önerileri ve test sonuçları dikkate alınmalıdır.

HPA Denominator Problemi

CPU utilization hesaplanırken kullanılan CPU request değeri denominator görevindedir. VPA request değerini iki katına çıkarırsa gerçek CPU tüketimi aynı kalsa bile utilization oranı yarıya düşer. HPA bunu kapasite fazlası gibi yorumlayabilir. Bu matematiksel etkileşim HPA ve VPA tasarımında temel noktadır. Replica scaling metriğini RPS veya external metric'e taşımak denominator bağımlılığını azaltabilir.

VPA Recommendation + HPA

VPA'yı yalnızca recommendation amacıyla kullanmak HPA ile güvenli bir birlikte kullanım desenidir. VPA resource önerileri otomatik uygulanmaz, ekip belirli aralıklarla değerlendirme yapar. HPA mevcut request değerleri üzerinden kararlı biçimde çalışmaya devam eder. Request değişikliği planlı rollout ile yapılabilir ve HPA davranışı load testte yeniden doğrulanır. Bu model kontrolü ekipte tutarken VPA gözlemlerinden yararlanmayı sağlar.

Custom Metric HPA + VPA

HPA RPS, queue length veya başka custom metric üzerinden çalışırken VPA CPU ve memory right-sizing yapabilir. Bu durumda HPA replica kararının paydası VPA'nın değiştirdiği request değeri olmayabilir. Dolayısıyla iki controller arasındaki doğrudan feedback riski azalır. Yine de resource değişimi Pod başına throughput'u etkileyebilir. VPA güncellemesinden sonra HPA custom metric hedefinin hâlâ doğru olduğu yeniden test edilmelidir.

Güvenli Kombinasyonlar

En güvenli kombinasyonlardan biri HPA'yı talep metriğiyle, VPA'yı resource recommendation veya kontrollü right-sizing amacıyla kullanmaktır. Kritik iş yüklerinde automatic resource update yerine planlı rollout tercih edilebilir. CPU HPA kullanılacaksa VPA'nın aynı CPU request değerini otomatik değiştirmemesi daha öngörülebilir davranış sağlar. Her iki controller'ın event ve status bilgisi aynı dashboard'da izlenmelidir. Değişikliklerden sonra load test tekrar edilmelidir.

KEDA Nedir?

KEDA, Kubernetes iş yüklerini dış olay kaynaklarına göre ölçeklemeyi kolaylaştıran event-driven autoscaling projesidir. Queue, stream, Prometheus metric veya cron gibi trigger kaynakları üzerinden replica ihtiyacını belirleyebilir. ScaledObject tipik olarak Deployment benzeri workload'ları, ScaledJob ise iş bazlı paralel job modelini yönetmek için kullanılır. KEDA dış metric ile sıfırdan bir replica'ya geçişi yönetebilir ve daha yüksek replica aralığında HPA mekanizmasıyla çalışabilir. Event sinyalinin CPU'dan daha erken geldiği consumer sistemlerinde önemli avantaj sağlar.

Event-Driven Autoscaling

Event-driven autoscaling sistem kaynağı kullanımından ziyade bekleyen iş veya dış olay sinyaline tepki verir. Queue consumer örneğinde mesajlar birikmeye başladığında CPU yükselmesini beklemeden yeni replica açılabilir. Bu yaklaşım asynchronous iş yüklerinde latency ve backlog kontrolünü kolaylaştırır. Trigger threshold değerinin işleme kapasitesiyle uyumlu olması gerekir. Çok düşük eşik gereksiz replica churn, çok yüksek eşik uzun queue wait süresi oluşturabilir.

ScaledObject

ScaledObject, KEDA'nın Deployment veya benzeri ölçeklenebilir bir hedefi event trigger'larla ilişkilendiren kaynağıdır. `scaleTargetRef` hedef workload'u belirtir. `minReplicaCount` ve `maxReplicaCount` kapasite sınırlarını belirler. Trigger tanımları queue, Prometheus veya başka dış sistemlerden metric alır. Scale-to-zero kullanıldığında polling ve cooldown süreleri kullanıcı latency'si açısından dikkatle ayarlanmalıdır.

ScaledJob

ScaledJob, her iş veya iş grubu için Kubernetes Job oluşturmanın uygun olduğu batch senaryolarında kullanılabilir. Queue'daki bekleyen iş sayısına göre paralel job kapasitesi artırılabilir. İş tamamlandığında job sona erdiği için uzun yaşayan worker replica modeli zorunlu değildir. Node autoscaler burst sırasında gerekli kapasiteyi sağlayabilir. Çok sayıda Job açmanın scheduler ve API server üzerinde oluşturduğu yük test edilmelidir.

External Event Source

External event source Kubernetes dışındaki iş yükü sinyalini autoscaling'e taşır. Kafka lag, message queue depth veya Prometheus sorgusu buna örnek olabilir. Metric pipeline gecikmesi scale-up reaksiyon süresinin bir parçasıdır. Kaynağa erişim kesilirse fallback veya minimum replica stratejisi önem kazanır. Kritik consumer sistemlerinde metric kaynağının availability'si de uygulama SLO tasarımına dahil edilmelidir.

Scale-to-Zero

Scale-to-zero, trafik veya event yokken replica sayısını sıfıra indirerek boş kapasite maliyetini azaltabilir. KEDA bunu destekleyen external trigger senaryolarında doğal biçimde sunar. Ancak sıfırdan ilk Pod'un Ready hale gelmesi cold start gecikmesi oluşturur. Kullanıcıya doğrudan yanıt veren düşük latency servislerinde minimum bir replica tutmak daha doğru olabilir. Batch ve seyrek event sistemlerinde scale-to-zero daha güçlü maliyet avantajı sağlar.

KEDA Hangi Kaynaklarla Çalışır?

KEDA çok sayıda event source için scaler desteği sunar ve seçim workload'un gerçek talep kaynağına göre yapılmalıdır. Kafka, RabbitMQ, SQS, Azure Queue, Prometheus, Redis ve cron yaygın örnekler arasındadır. Her scaler'ın authentication, threshold ve metric semantics ayrıntısı farklı olabilir. Trigger yalnızca kurulabildiği için değil, kapasite ihtiyacını doğru temsil ettiği için seçilmelidir. Production'a almadan önce metric source kesintisi ve fallback davranışı da test edilmelidir.

Kafka

Kafka scaler consumer lag gibi sinyaller üzerinden workload replica sayısını artırabilir. Lag büyümeden kapasiteyi artırmak kullanıcı veya veri işleme gecikmesini sınırlar. Partition sayısı aynı anda yararlı olabilecek consumer replica sayısını sınırlandırabilir. On partition bulunan bir topic için yüz consumer replica genellikle beklenen throughput artışını sağlamaz. KEDA threshold ve max replica değeri Kafka topolojisiyle uyumlu ayarlanmalıdır.

RabbitMQ

RabbitMQ queue length veya ilgili message metrikleri consumer scaling için kullanılabilir. Bekleyen mesaj sayısı iş hacminin doğrudan göstergesi olabilir. Mesaj işleme süreleri çok değişiyorsa yalnızca queue length yeterli olmayabilir. Queue age veya processing duration gibi ek metrikler SLO takibini güçlendirir. Consumer replica artışının broker üzerinde connection yükü oluşturacağı da kapasite planına dahil edilmelidir.

SQS

SQS tabanlı workload'larda queue depth KEDA scaler için event sinyali olarak kullanılabilir. Mesaj biriktiğinde consumer replica sayısı artırılır ve iş tamamlandığında kapasite düşürülebilir. Visibility timeout ve message processing time scaling davranışıyla uyumlu olmalıdır. Çok hızlı replica artışı downstream servislere burst yük gönderebilir. Concurrency limit ve backpressure politikaları autoscaling ile birlikte tasarlanmalıdır.

Azure Queue

Azure Queue benzeri queue servisleri bekleyen mesaj sayısını event-driven scaling sinyali olarak sağlayabilir. KEDA scaler uygun authentication ile queue metriğini izleyebilir. Threshold değeri Pod başına işleme kapasitesine göre belirlenmelidir. Mesajlar ağır işlemler içeriyorsa yalnızca sayı üzerinden lineer replica hesabı yanıltıcı olabilir. Production telemetry işleme süresini ve queue age değerini de içermelidir.

Prometheus

KEDA Prometheus sorgu sonucunu external scaling trigger olarak kullanabilir. Bu özellik uygulamaya özgü herhangi bir güvenilir metriği scaling kararına bağlamayı mümkün kılar. RPS, queue veya özel business metric PromQL ile hesaplanabilir. Query'nin hızlı ve doğru label filtreli olması önemlidir. Prometheus kesintisinin autoscaling davranışına etkisi için minimum replica veya fallback yaklaşımı düşünülmelidir.

Redis

Redis tabanlı queue veya list yapıları event-driven workload'larda scaling sinyali sağlayabilir. Bekleyen öğe sayısı worker ihtiyacını gösterebilir. Redis aynı zamanda kritik uygulama bağımlılığıysa scaler sorgularının ek yükü göz önüne alınmalıdır. Çok kısa polling interval gereksiz sorgu trafiği oluşturabilir. Queue uzunluğu ile worker processing rate birlikte ölçülerek threshold belirlenmelidir.

Cron

Cron scaler bilinen zaman pencerelerinde önceden belirli replica kapasitesine çıkmak için kullanılabilir. Her gün belirli saatte başlayan trafik artışı için reactive metric'i beklemek yerine pre-scaling yapılabilir. Bu yöntem kampanya, raporlama veya çalışma saatleri gibi tahmin edilebilir örüntülerde yararlıdır. Timezone ayarı yanlış yapılırsa beklenen kapasite yanlış zamanda açılır. Scheduled scaling her zaman gerçek metric ile izlenmeli ve beklenmeyen spike'lar için ek koruma bulunmalıdır.

HPA ile KEDA Arasındaki Fark

HPA Kubernetes'in genel replica autoscaling controller'ıdır, KEDA ise dış event kaynaklarını bu modele bağlayan ve scale-to-zero gibi event-driven kullanım desenlerini kolaylaştıran projedir. CPU ve memory gibi resource metrics için doğrudan HPA yeterli olabilir. Queue, Kafka lag veya dış trigger kullanan workload'larda KEDA daha doğal bir operasyon modeli sunabilir. ScaledObject çoğu durumda HPA oluşturarak birden N'e ölçekleme sürecinden yararlanır. Dolayısıyla KEDA ile HPA tamamen ayrı dünyalar değil, birbirini tamamlayabilen katmanlardır.

Resource Metric

HPA CPU ve memory gibi resource metrics ile doğrudan çalışabilir. Bu metrikler Kubernetes metrics API üzerinden sağlanır. Compute-bound stateless servislerde ek event altyapısı kurmadan yeterli olabilir. KEDA da bazı resource metric senaryolarını desteklese de asıl gücü dış trigger çeşitliliğidir. Metric seçimi kullanılan araçtan önce gelmelidir.

External Metric

External metric Kubernetes dışındaki sistemden gelen talep sinyalidir. Queue depth, Kafka lag veya harici Prometheus sorgusu buna örnek olabilir. HPA external metrics API üzerinden bu değerlerle çalışabilir. KEDA scaler katalogları ve authentication modelleri bu entegrasyonu kolaylaştırır. Ekip hangi yaklaşımı kullanırsa kullansın metric pipeline failure davranışını test etmelidir.

Event-Driven Workloads

Event-driven workload trafik yerine event geldikçe çalışır. Queue consumer, stream processor ve background worker bu modele örnektir. CPU metriği event birikmesini geç fark edebilir. KEDA doğrudan event source'a bakarak daha erken replica artışı sağlayabilir. Event işleme süresi ve queue age gerçek kapasite hedefini belirlemek için birlikte kullanılmalıdır.

Queue Consumers

Queue consumer'larda temel sorun kullanıcı request'ini hemen yanıtlamak değil, backlog'un kabul edilebilir sürede eritilmesidir. Queue length veya age bu amacı CPU'dan daha iyi temsil edebilir. KEDA scaler üzerinden bu metrikler replica yönetimine bağlanabilir. Maksimum replica downstream sistemin kapasitesiyle sınırlandırılmalıdır. Aksi halde queue hızlı boşalırken veritabanı veya API doygunluğa ulaşabilir.

Scale-to-Zero

KEDA dış event trigger'larıyla kullanılmadığı zaman replica sayısını sıfıra indirme senaryolarını kolaylaştırır. HPA'nın standart kullanımında minimum replica çoğu resource metric senaryosunda sıfır değildir. Event geldiğinde KEDA sıfırdan çalışma kapasitesini tekrar başlatabilir. Cold start bu modelin temel bedelidir. Kullanıcıya dönük uygulamalarda minimum warm replica daha uygun olabilir.

Hangi Senaryoda Hangisi?

CPU veya memory ile ölçeklenen klasik stateless API için HPA sade ve yeterli olabilir. Queue, Kafka veya dış event source olan workload'larda KEDA entegrasyon yükünü azaltabilir. Her iki durumda da node kapasitesi ayrı bir problemdir ve gerektiğinde node autoscaler kullanılmalıdır. HPA ile KEDA seçimi “hangi araç daha iyi” sorusundan çok “hangi metric gerçek talebi gösteriyor” sorusuna dayanmalıdır. En doğru karar küçük load testlerle doğrulanabilir.

Scale-to-Zero Kullanılmalı mı?

Scale-to-zero boşta kalan uygulamalar için maliyet avantajı sağlar, ancak ilk event veya request geldiğinde cold start süresi oluşur. Batch worker ve seyrek kullanılan iç servislerde bu bedel kabul edilebilir olabilir. Kullanıcıya doğrudan yanıt veren düşük latency API'de birkaç saniyelik startup bile kötü deneyim oluşturabilir. Uygulamanın minimum replica değeri SLO hedeflerine göre seçilmelidir. Kritik workload'larda tam sıfır yerine küçük warm capacity genellikle daha güvenli olur.

Maliyet Avantajı

Gece veya uzun süre kullanılmayan worker replica'larını sıfıra indirmek compute maliyetini azaltabilir. Çok sayıda düşük kullanım oranlı servis bulunan cluster'larda toplam tasarruf anlamlı hale gelir. Node autoscaler boşalan node'ları da kaldırabiliyorsa altyapı maliyeti daha fazla düşebilir. Ancak tekrar scale-up sırasında node provisioning gerekirse cold start süresi uzar. Tasarruf hesabı kullanıcı latency bedeliyle birlikte yapılmalıdır.

Cold Start

Cold start sıfır replica durumundan ilk kullanıma hazır Pod'un oluşmasına kadar geçen süredir. Image pull, scheduling, app startup, cache warm-up ve readiness bu süreye dahildir. Node kapasitesi yoksa node provisioning de eklenir. Birkaç saniyelik teorik Pod startup süresi gerçek production zincirinde daha uzun olabilir. Scale-to-zero kararı gerçek ilk-request testiyle verilmelidir.

İlk Request Latency

İlk request scale-to-zero sisteminde kapasite oluşmasını beklemek zorunda kalabilir. Queue tabanlı sistemde request doğrudan kullanıcıya bağlı olmadığı için bu gecikme daha kabul edilebilir olabilir. Web API'de ise kullanıcı timeout yaşayabilir. Request'i queue'ya alıp asenkron yanıt modeli kullanmak bazı workload'larda problemi azaltır. SLO içinde izin verilen ilk yanıt süresi tasarımın ana kriteridir.

Minimum Replica

Minimum replica sayısını bir veya daha fazla tutmak cold start riskini azaltır. Bir Pod hazır olduğunda ani trafiğin ilk bölümünü karşılayabilir ve HPA geri kalan kapasiteyi ekler. Ancak tek Pod'un failure durumunda downtime yaratmaması için availability hedefi değerlendirilmelidir. Multi-zone sistemlerde minimum değer zone sayısına göre seçilebilir. Maliyet optimizasyonu için yalnızca ortalama trafik değil failure kapasitesi de hesaba katılmalıdır.

Kritik Uygulamalarda Warm Capacity

Kritik uygulamalarda belli miktarda boş kapasite aslında hata toleransı ve burst koruması sağlar. Sürekli yüzde yüz utilization hedeflemek node veya Pod arızasında anında doygunluk yaratabilir. Warm capacity HPA'nın yeni replica hazırladığı süre boyunca trafiği taşır. Bu kapasite maliyetlidir, fakat SLO ihlalinden daha ucuz olabilir. Minimum Pod ve node rezervi iş etkisine göre belirlenmelidir.

Scheduled ve Predictive Scaling

Reactive autoscaling metric değiştikten sonra tepki verir, ancak bazı trafik zirveleri önceden bilinir. Günlük iş başlangıcı, kampanya saati veya planlı etkinlik için kapasite önceden hazırlanabilir. Cron-based pre-scaling bu durumda cold start etkisini azaltır. Predictive yaklaşım geçmiş trafik verilerinden tahmin üretmeyi amaçlayabilir, fakat tahmin hatası için reactive güvenlik ağı yine gerekir. En iyi sistem bilinen zirveyi önceden karşılar ve beklenmeyen artışlara HPA veya KEDA ile tepki verir.

Cron-Based Pre-Scaling

Cron-based pre-scaling belirli saatlerde replica sayısını önceden artırır. Her sabah dokuzda trafik yükseliyorsa sekiz ellide warm kapasite açılabilir. KEDA cron scaler gibi araçlar bu deseni uygulamayı kolaylaştırır. Timezone ve daylight saving davranışları kullanılan bölgeye göre kontrol edilmelidir. Pre-scaling yalnızca replica değil gerekiyorsa node kapasitesini de zamanında hazır hale getirmelidir.

Bilinen Trafik Zirveleri

E-ticaret kampanyası, raporlama batch'i veya günlük giriş saati gibi trafik zirveleri önceden tahmin edilebilir. Reactive HPA bu trafiği gördükten sonra Pod açacağı için warm-up gecikmesi yaşar. Önceden kapasite artırmak ilk kullanıcıların latency'sini korur. Zirve bittikten sonra scale-down stabilization ile kapasite kontrollü azaltılabilir. Geçmiş trafik grafikleri scheduled scaling saatini belirlemek için iyi bir kaynaktır.

Kampanya ve Etkinlik Öncesi Kapasite

Planlı kampanya öncesinde yalnızca Pod sayısını artırmak yeterli değildir. Node, database connection, cache, gateway ve downstream kapasitesi de beklenen peak için hazırlanmalıdır. Load test kampanya trafiğinin request dağılımına benzer olmalıdır. Gateway weighted routing kullanılıyorsa yeni sürüm trafik oranı da peak kapasite planına dahil edilmelidir. Etkinlik başladıktan sonra manuel müdahaleye bağımlılığı azaltmak için alarm ve rollback planı önceden hazırlanmalıdır.

Reactive vs Predictive Scaling

Reactive scaling gerçek metric değişimine dayanır ve yanlış tahmin riskini azaltır. Predictive scaling gelecekteki talebi tahmin ederek kapasiteyi daha erken açmaya çalışır. Tahmin doğru olduğunda cold start etkisi önemli ölçüde azalabilir. Beklenmedik trafik desenlerinde prediction tek başına yeterli değildir. Bu yüzden predictive kapasite planı HPA veya KEDA gibi reactive mekanizmayla birlikte kullanılmalıdır.

Pre-Warming

Pre-warming yalnızca replica nesnesini erken oluşturmak değil, Pod'un gerçek production performansına hazır hale gelmesini sağlamaktır. Cache doldurma, connection pool oluşturma ve model yükleme bu sürecin parçasıdır. Yeni Pod Ready olduktan sonra bile ilk request latency'si yüksek olabiliyorsa warm-up testi geliştirilmelidir. Trafiği kademeli vermek bazı uygulamalarda daha güvenlidir. Gateway weighted routing yeni kapasiteyi kontrollü devreye almak için kullanılabilir.

Cluster Autoscaler Nedir?

Cluster Autoscaler scheduler'ın mevcut node kapasitesine yerleştiremediği Pod'ları değerlendirerek node group kapasitesini artırabilen bir node autoscaling mekanizmasıdır. Ayrıca uygun koşullarda düşük kullanılan node'ların kaldırılmasına yardımcı olabilir. HPA'nın ürettiği yeni Pod'lar mevcut node'lara sığmıyorsa bu katman devreye girer. Node ekleme süresi Pod startup süresine eklendiği için toplam scale-up gecikmesi büyür. Resource request, affinity ve PDB ayarları Cluster Autoscaler davranışını doğrudan etkiler.

Pending Pod

Pending Pod henüz uygun node'a schedule edilememiş veya başlatma aşamasını tamamlamamış olabilir. Autoscaling bağlamında en önemli durum scheduler'ın kapasite veya constraint nedeniyle Pod için yer bulamamasıdır. HPA desired replica sayısını artırmış olsa bile Pending Pod kullanıcı kapasitesine katkı sağlamaz. `kubectl describe pod` içindeki scheduling event'leri sebebi gösterir. CPU veya memory yetersizliği ile affinity veya taint sorunu birbirinden ayrılmalıdır.

Unschedulable Pod

Unschedulable Pod mevcut node'ların hiçbirinin scheduling koşullarını karşılamadığı Pod'dur. Resource request fazla olabilir veya node selector uygun node bırakmayabilir. Cluster Autoscaler bu Pod için uygun node group büyütülebiliyorsa yeni kapasite ekleyebilir. Ancak cloud quota veya uygun instance type yoksa node açılması mümkün olmayabilir. Bu nedenle autoscaling alarm sistemi yalnızca Pending Pod sayısını değil unschedulable reason bilgisini de izlemelidir.

Node Group

Node group benzer yapıdaki node kapasitesinin yönetildiği gruptur. Cluster Autoscaler hangi grubun unschedulable Pod'u çalıştırabileceğini değerlendirir. Farklı CPU, memory, GPU veya zone özelliklerine sahip gruplar bulunabilir. Min ve max group sınırları kapasite artışını sınırlayabilir. Workload gereksinimleri node group tasarımıyla eşleşmiyorsa HPA ne kadar replica isterse istesin Pod'lar Pending kalır.

Scale-Up

Scale-up unschedulable Pod için node group kapasitesinin artırılmasıdır. Yeni node'un cloud tarafından oluşturulması, işletim sisteminin açılması ve cluster'a Ready olarak katılması zaman alır. Ardından scheduler Pod'u node'a yerleştirir. Image pull ve application warm-up ile gerçek kapasite daha da sonra oluşabilir. Bu toplam süre peak trafik tasarımında ölçülmeli ve gerekirse warm node kapasitesi tutulmalıdır.

Scale-Down

Scale-down düşük kullanılan ve üzerindeki Pod'ları güvenle başka node'lara taşıyabilecek kapasiteyi azaltmayı amaçlar. Node silinmeden önce Pod'ların evict edilmesi gerekir. PDB, local storage veya scheduling constraints node'un boşaltılmasını engelleyebilir. Bu nedenle düşük CPU görünen node'un hemen kaldırılmaması normal olabilir. Maliyet optimizasyonunda scale-down blocker nedenleri düzenli raporlanmalıdır.

Node Drain

Node drain Pod'ların node üzerinden güvenli biçimde çıkarılmasını sağlar. Autoscaler scale-down sırasında benzer eviction süreçlerine ihtiyaç duyabilir. PDB minimum availability değerini korumaya yardımcı olur. Pod başka node'a schedule edilemiyorsa node silinemez. Graceful shutdown süresi uzun iş yüklerinde drain işleminin tamamlanma süresi de uzayabilir.

HPA ile Cluster Autoscaler Nasıl Birlikte Çalışır?

HPA ve Cluster Autoscaler farklı katmanlarda çalışır ve production scaling zincirinin iki tamamlayıcı parçasıdır. Trafik yükseldiğinde HPA replica sayısını artırır. Scheduler yeni Pod'ları mevcut node'lara sığdıramazsa Pod'lar unschedulable olur. Cluster Autoscaler uygun node group kapasitesini artırır ve yeni node Ready olduğunda scheduler Pod'ları yerleştirir. Son olarak readiness tamamlanan Pod'lar Service endpoint kümesine katılarak gerçek trafiği taşımaya başlar.

Trafik Artar

Scaling zinciri çoğu zaman gelen trafik veya event artışıyla başlar. RPS, CPU, queue veya başka metric hedef değeri aşmaya başlar. HPA veya KEDA bu sinyali gözlemler. Tepki süresi metric scrape ve controller interval değerlerinden etkilenir. Ani spike'ta warm kapasite yoksa kullanıcı latency'si scaling tamamlanmadan önce yükselebilir.

HPA Yeni Pod İster

HPA metric oranına göre desired replica sayısını yükseltir. Deployment controller eksik replica sayısı kadar yeni Pod oluşturmaya başlar. Bu aşamada Pod nesnesi oluşmuş olması gerçek kapasite geldiği anlamına gelmez. Scheduler'ın uygun node bulması gerekir. Desired replicas ile Ready replicas arasındaki fark bu geçişi dashboard'da gösterir.

Cluster'da Kapasite Yetmez

Mevcut node'larda Pod resource request'lerini karşılayacak boş CPU veya memory bulunmayabilir. GPU gibi özel kaynaklarda sorun daha belirgin olabilir. Scheduler uygun node bulamaz ve Pod placement gerçekleşmez. Bu durum HPA'nın hatası değildir. Node autoscaler'ın kapasite ekleyebileceği doğru node class veya group bulunmalıdır.

Pod Pending Kalır

Pod Pending olduğunda Service trafiği için Ready endpoint oluşturmaz. HPA replica sayısı kağıt üzerinde artmış görünse bile kullanıcı kapasitesi aynı kalır. Pending reason `Insufficient cpu`, affinity mismatch veya taint gibi ayrıntılar verebilir. Alert sistemi uzun süre Pending kalan autoscaled Pod'ları bildirmelidir. Bu sorun yük altında gecikme ve 5xx artışıyla birlikte görünür hale gelir.

Cluster Autoscaler Node Ekler

Cluster Autoscaler unschedulable Pod'un gereksinimlerini karşılayabilecek node group'u büyütür. Cloud ortamı yeni compute instance oluşturur. Node cluster'a katılıp Ready olana kadar belirli süre geçer. Bu süre yoğun trafik altında kritik olabilir. Hızlı Pod autoscaling'in node provisioning gecikmesini ortadan kaldırmadığı unutulmamalıdır.

Scheduler Pod'u Yerleştirir

Yeni node Ready olduğunda scheduler Pending Pod için tekrar uygun placement bulabilir. Resource request, affinity ve topology constraint koşulları sağlanırsa Pod node'a atanır. Ardından container image çekilir ve application startup başlar. Node eklenmesi bu yüzden son adım değildir. Ready Pod süresi ayrı bir SLO olarak ölçülmelidir.

Service Yeni Pod'a Trafik Dağıtır

Pod readiness koşullarını sağladığında backend endpoint bilgisine katılabilir. Service veri yolu yeni endpoint'e trafik göndermeye başlar. Uzun bağlantılı uygulamalarda mevcut connection'lar yeni Pod'a taşınmayabilir. Bu nedenle yeni replica'nın hemen eşit trafik alması beklenmemelidir. Scale-up tamamlandı ölçütü olarak yalnızca Ready değil gerçek RPS alan replica sayısını da izlemek faydalıdır.

HPA Çalışıyor Ama Pod'lar Neden Pending Kalıyor?

HPA desired replica sayısını artırdığı halde yeni Pod'ların Pending kalması çoğu zaman scheduler veya altyapı kapasitesi problemidir. Node CPU veya memory yetersiz olabilir, fakat tek neden bu değildir. Node selector, affinity, taint, availability zone kısıtı, cloud quota veya uygun instance type bulunamaması da aynı sonucu üretir. `kubectl describe pod` scheduling event'leri problemi hızlı biçimde daraltır. Node autoscaler logları ve cloud provisioning event'leri ikinci kontrol noktasıdır.

Node Kapasitesi Yetmiyor

En yaygın Pending nedeni mevcut node'larda yeterli request kapasitesi bulunmamasıdır. CPU veya memory toplamı node allocatable sınırını aşabilir. HPA daha fazla replica açtıkça Pending Pod sayısı büyür. Cluster Autoscaler uygun node ekleyebiliyorsa sorun çözülür. Max node group sınırı veya cloud quota doluysa manuel kapasite planı gerekir.

Resource Requests Çok Büyük

Tek bir Pod'un request'i mevcut node instance type'ının verebileceğinden büyük olabilir. Böyle durumda toplam cluster'da boş kaynak bulunsa bile Pod hiçbir node'a sığmaz. Autoscaler aynı küçük instance type'tan daha fazla node açarsa sorun devam eder. Daha büyük node class veya workload right-sizing gerekir. `Insufficient cpu` mesajını yalnızca “daha fazla node lazım” şeklinde yorumlamamak önemlidir.

Node Selector

Node selector Pod'un yalnızca belirli label'a sahip node'larda çalışmasına izin verir. Uygun label taşıyan node sayısı yetersizse yeni replica Pending kalabilir. Cluster'da boş kapasite bulunması bu problemi çözmez. Node autoscaler selector ile uyumlu group'u büyütebilmelidir. Selector değişiklikleri production öncesinde kapasite senaryolarıyla test edilmelidir.

Affinity

Node affinity veya Pod affinity kuralları scheduler seçeneklerini daraltabilir. Çok katı kurallar HPA scale-up sırasında uygun placement kalmamasına neden olabilir. Preferred kurallar mümkün olduğunda daha esnek davranış sağlayabilir. Required constraint gerçekten iş gereksinimi değilse gereksiz availability riski oluşturur. Pending event'lerinde affinity mismatch mesajları bu durumu gösterir.

Taint ve Toleration

Taint node üzerinde hangi Pod'ların çalışabileceğini sınırlamak için kullanılır. Pod gerekli toleration'a sahip değilse node'da boş kapasite olsa bile schedule edilemez. Özel GPU veya sistem node pool'larında bu yaklaşım yaygındır. HPA yeni replica açarken manifest aynı toleration değerlerini taşıdığı için mevcut sorun büyüyebilir. Node pool ve workload toleration standardı GitOps review sırasında kontrol edilmelidir.

Availability Zone Kısıtı

Persistent volume veya affinity kuralı Pod'u belirli availability zone'a bağlayabilir. O zone'da node kapasitesi yoksa başka zone'daki boş node işe yaramaz. Node autoscaler ilgili zone'da yeni node açabilmelidir. Cloud tarafında zone kapasite sorunu varsa provisioning başarısız olabilir. Multi-AZ tasarımında tek zone'a bağlı storage kararlarının autoscaling etkisi özellikle değerlendirilmelidir.

Cloud Quota

Cloud hesabındaki vCPU, instance veya IP quota sınırı yeni node oluşturulmasını engelleyebilir. Cluster Autoscaler doğru karar verse bile altyapı sağlayıcısı isteği reddedebilir. Bu durum production peak sırasında ciddi kapasite problemi yaratır. Quota kullanımı deployment öncesinde izlenmeli ve alarm tanımlanmalıdır. Kampanya döneminden önce limitlerin yeterli olduğu doğrulanmalıdır.

Uygun Instance Type Bulunamaması

Belirli instance type veya availability zone'da kapasite bulunmayabilir. Autoscaler yalnızca dar bir node seçeneğine izin veriyorsa provisioning takılabilir. Birden fazla uyumlu instance type tanımlamak esnekliği artırabilir. GPU kapasitesinde bu sorun daha sık görülür. Karpenter gibi dinamik provisioning yaklaşımında izin verilen instance ailelerini geniş tutarken workload gereksinimlerini korumak faydalıdır.

Karpenter Nedir?

Karpenter workload gereksinimlerine göre dinamik node kapasitesi sağlayan açık kaynaklı provisioning yaklaşımıdır. NodePool gibi kaynaklarla hangi instance kategorilerinin, zone'ların ve kapasite türlerinin kullanılabileceği tanımlanabilir. Scheduler'ın yerleştiremediği Pod'ların resource ve topology ihtiyaçları üzerinden uygun compute seçilebilir. Consolidation düşük kullanılan kapasitenin daha verimli node düzenine taşınmasına yardımcı olabilir. Dinamik seçim güçlüdür, fakat cloud limitleri ve disruption politikaları iyi tasarlanmalıdır.

Dynamic Node Provisioning

Dynamic node provisioning önceden sabit boyutlu node group'lara bağlı kalmadan workload talebine uygun compute seçmeyi hedefler. Pod 8 CPU ve yüksek memory istiyorsa buna uygun instance seçenekleri değerlendirilebilir. Bu yaklaşım farklı workload profillerinin aynı cluster'da daha verimli çalışmasını sağlayabilir. Çok dar constraint dinamik seçimin avantajını azaltır. Node provisioning süresi production scale-up metriği olarak izlenmelidir.

NodePool

NodePool, Karpenter'ın hangi node özelliklerini sağlayabileceğini tanımlayan temel kaynaklardan biridir. Instance category, architecture, zone ve capacity type gibi kısıtlar burada ifade edilebilir. Birden fazla NodePool farklı workload sınıflarını ayırabilir. Çok sayıda çakışan NodePool operasyonel yönetimi zorlaştırabilir. Platform ekibi az sayıda anlaşılır kapasite sınıfı oluşturmayı hedeflemelidir.

Workload Gereksinimine Göre Node Seçimi

Karpenter scheduler ihtiyaçlarından yola çıkarak Pod'ların resource ve scheduling constraint'lerine uygun node seçebilir. Bu özellik GPU, memory-heavy veya compute-heavy workload'larda faydalıdır. Pod request değerleri yanlışsa node seçimi de yanlış olur. Çok yüksek request pahalı instance, çok düşük request aşırı packing oluşturabilir. Node autoscaling kalitesi uygulama right-sizing kalitesine doğrudan bağlıdır.

Instance Type

Instance type CPU, memory, network ve özel donanım kapasitesini belirler. Dinamik provisioning birden fazla uyumlu instance type arasından seçim yapabilir. Bu çeşitlilik cloud kapasite sıkıntısı sırasında alternatif bulmayı kolaylaştırır. Ancak uygulama bazı CPU architecture veya local disk özelliğine bağımlıysa constraint gerekir. Gereksiz dar instance listeleri availability ve maliyet optimizasyonunu sınırlayabilir.

Availability Zone

NodePool birden fazla availability zone'da provisioning yapılmasına izin verebilir. Bu sayede tek zone kapasite problemi sırasında diğer bölgede node açma şansı artar. Stateful volume constraint'leri yine Pod'u belirli zone'a bağlayabilir. Topology spread yeni replica'ların zone'lar arasında dengelenmesine yardımcı olur. Zone bazlı node sayısı ve capacity error metrikleri izlenmelidir.

Spot ve On-Demand

Spot kapasite maliyet avantajı sunabilir, ancak kesinti riski taşır. On-demand daha öngörülebilir kapasite sağlar fakat birim maliyeti daha yüksek olabilir. Karpenter iki kapasite tipini politika içinde değerlendirebilir. Kritik replica'ların tamamını yalnızca spot üzerinde tutmak availability riskini artırabilir. Workload disruption toleransı ve PDB tasarımı kapasite tipi seçiminin parçasıdır.

Node Consolidation

Consolidation düşük kullanılan veya verimsiz node dağılımını daha uygun kapasiteyle değiştirmeyi hedefler. Bu işlem cloud maliyetini azaltabilir. Ancak Pod'ların taşınması disruption oluşturduğu için PDB ve workload constraint'leri dikkate alınır. Çok agresif consolidation sürekli node churn yaratabilir. Node değişim frekansı ve toplam tasarruf birlikte ölçülerek politika ayarlanmalıdır.

Cluster Autoscaler mı Karpenter mı?

Cluster Autoscaler ve Karpenter aynı genel node kapasitesi problemini farklı provisioning modelleriyle ele alır. Cluster Autoscaler çoğu kullanımda önceden tanımlı node group'ların boyutunu değiştirir. Karpenter workload gereksiniminden yola çıkarak daha dinamik instance seçimi yapabilir. Cloud provider desteği, ekip deneyimi ve mevcut altyapı modeli seçimde belirleyicidir. Geçiş kararı yalnızca provisioning hızına değil, operasyonel sürdürülebilirlik ve maliyet verisine dayanmalıdır.

Predefined Node Groups

Cluster Autoscaler önceden tanımlanmış node group yapılarını büyütüp küçültme modeliyle güçlüdür. Platform ekibi instance type ve zone kararlarını group seviyesinde önceden verir. Bu yapı anlaşılır ve birçok platformda yerleşik olabilir. Workload çeşitliliği büyüdükçe çok sayıda node group gerekebilir. Group yönetim yükü arttığında daha dinamik modeller değerlendirilebilir.

Dynamic Instance Selection

Karpenter farklı instance seçenekleri arasından Pod gereksinimine uygun kapasite seçebilir. Bu esneklik workload profili değiştikçe daha iyi packing ve kapasite bulunabilirliği sağlayabilir. Pod resource request kalitesi burada temel girdidir. Yanlış request doğru instance seçimini zorlaştırır. Dinamik seçimin davranışı cost ve disruption dashboard'larıyla izlenmelidir.

Provisioning Speed

Node provisioning hızında controller karar süresi kadar cloud instance'ın gerçek açılma süresi de etkili olur. Karpenter unschedulable workload'a doğrudan uygun node seçerek bazı modellerde hızlı tepki sağlayabilir. Cluster Autoscaler node group büyütme üzerinden ilerler. Gerçek fark platform, image, bootstrap ve network setup süresine bağlıdır. Karşılaştırma production'a benzeyen yük testinde yapılmalıdır.

Cost Optimization

Dinamik instance seçimi ve consolidation farklı workload'ları daha uygun maliyetli compute üzerinde çalıştırmaya yardımcı olabilir. Cluster Autoscaler tarafında doğru node group tasarımıyla benzer biçimde güçlü maliyet kontrolü sağlanabilir. Spot kullanımı iki yaklaşımda da stratejiye bağlıdır. En ucuz instance her zaman en düşük toplam maliyet anlamına gelmez. Daha yavaş node veya yüksek network maliyeti kullanıcı başına toplam harcamayı artırabilir.

Cloud Provider Desteği

Node autoscaler seçimi kullanılan cloud veya altyapı ortamının destek seviyesine bağlıdır. Cluster Autoscaler geniş bir provider ekosistemine sahiptir. Karpenter'ın özellikleri ve provider desteği kullanılan platforma göre değerlendirilmelidir. Managed Kubernetes servisinin resmi entegrasyon yöntemleri upgrade güvenliği açısından önemlidir. Araç seçmeden önce sürüm uyumluluğu ve support modeli kontrol edilmelidir.

Operasyonel Karmaşıklık

Daha dinamik provisioning daha fazla esneklik sunarken ekip için yeni kaynak türleri ve troubleshooting yöntemleri getirir. Basit ve sabit workload'larda mevcut node group modeli yeterli olabilir. Çok çeşitli ve hızlı değişen iş yüklerinde dinamik seçim daha fazla değer sağlayabilir. Ekibin gözlemlenebilirlik ve incident response yetkinliği seçimde hesaba katılmalıdır. Amaç en fazla özelliği kullanmak değil, en güvenilir ve ölçülebilir platformu kurmaktır.

Node Autoscaling ve Scheduler İlişkisi

Node autoscaler yeni Pod'un hangi kapasiteye ihtiyaç duyduğunu scheduler perspektifinden anlamaya çalışır. Resource request, node selector, affinity, taint ve topology constraints bu ihtiyacı belirler. Autoscaler yalnızca toplam CPU eksikliğine bakmaz, Pod'un gerçekten schedule edilebileceği node tipini değerlendirmelidir. Yanlış scheduling constraint uygun kapasite eklenmesini engelleyebilir. HPA, scheduler ve node autoscaler event'lerini aynı zaman çizgisinde görmek scaling troubleshooting'i çok kolaylaştırır.

Resource Requests

Scheduler Pod yerleşimini resource request değerlerine göre yapar. Node autoscaler da yeni kapasite ihtiyacını bu değerlerden türetir. Uygulama gerçekte 200m CPU kullanırken 4 CPU request ediyorsa gereksiz büyük node'lar açılabilir. Tersi durumda düşük request node'u aşırı doldurabilir. Right-sizing hem performance hem node maliyeti için temel bir uygulamadır.

Node Selector

Node selector Pod'u belirli label'a sahip node'larla sınırlar. Autoscaler bu constraint'i karşılayan kapasite üretebilmelidir. Uygun node group veya NodePool yoksa Pod sonsuza kadar Pending kalabilir. Selector yalnızca gerçekten gerekli donanım veya güvenlik ayrımları için kullanılmalıdır. Gereksiz dar label koşulları cluster esnekliğini azaltır.

Node Affinity

Node affinity daha gelişmiş node seçim kuralları tanımlar. Required kurallar sert kısıt, preferred kurallar tercih olarak çalışabilir. Autoscaling sırasında required kuralların sağlanabildiği kapasite bulunması gerekir. Çok sayıda sert koşul instance seçimini daraltır. Availability ihtiyacıyla uyumluysa preferred constraint daha esnek provisioning sağlayabilir.

Pod Anti-Affinity

Pod anti-affinity replica'ların aynı node veya topology domain üzerinde toplanmasını engellemek için kullanılabilir. Availability açısından değerli olsa da çok katı kurallar scheduling kapasitesini azaltabilir. HPA hızlı replica artırdığında yeni Pod için uygun domain bulunamayabilir. Topology spread constraints bazı senaryolarda daha ölçeklenebilir ve kontrollü bir alternatif sunar. Kural seçimi cluster büyüklüğü ve failure domain yapısına göre yapılmalıdır.

Taint/Toleration

Taint özel node havuzlarını yalnızca uygun toleration'a sahip workload'lara ayırmaya yardımcı olur. GPU node'ları buna yaygın örnektir. HPA yeni Pod açtığında toleration eksikse özel kapasiteye schedule edilemez. Node autoscaler doğru taint'e sahip node sağlasa bile Pod toleration taşımıyorsa sorun çözülmez. Workload template ile node pool tanımları birlikte version control altında gözden geçirilmelidir.

Topology Spread Constraints

Topology spread constraints replica'ların node veya zone gibi domain'ler arasında dengeli dağıtılmasını sağlar. `maxSkew` kabul edilen dağılım farkını sınırlar. HPA yeni Pod eklediğinde scheduler bu kurallara göre placement yapar. Böylece tek zone veya tek node hotspot riski azaltılabilir. Çok sert constraint zone kapasite sıkıntısında Pending Pod yaratabileceği için failure senaryosu test edilmelidir.

Pod Topology Spread ile Yük Dengeleme

Pod topology spread ağ load balancing'den farklı olarak replica'ların fiziksel node ve zone dağılımını dengeler. Trafik load balancer tarafından eşit dağıtılsa bile tüm Pod'lar aynı node'daysa node arızası büyük kapasite kaybı yaratır. Replica'ları farklı failure domain'lere yaymak availability ve topology-aware routing açısından faydalıdır. HPA yeni Pod eklediğinde spread constraints yerleşim dengesinin korunmasına yardımcı olur. Node autoscaler'ın her zone'da uygun kapasite sağlayabilmesi bu modelin tamamlayıcı parçasıdır.

Pod'ları Node'lara Dengeli Dağıtmak

Replica'ları birden fazla node'a yaymak tek node arızasında tüm uygulamanın kaybolmasını önler. Aynı zamanda CPU ve network yükünü node'lar arasında dağıtabilir. HPA replica artırırken scheduler yeni Pod'ları mevcut topology dengesine göre yerleştirebilir. Node sayısı azsa istediğiniz spread sağlanamayabilir. Minimum node kapasitesi availability hedefiyle uyumlu tutulmalıdır.

Availability Zone Dağılımı

Multi-AZ cluster'da Pod'ları zone'lara yaymak tek zone arızasına karşı dayanıklılık sağlar. HPA replica sayısı zone sayısından azsa tam dağılım mümkün olmayabilir. Minimum replica bu nedenle zone sayısıyla birlikte düşünülmelidir. Same-zone routing kullanıldığında zone başına Pod sayısı trafik dengesini de etkiler. Zone failure testi architecture review'un standart parçası olmalıdır.

maxSkew

`maxSkew`, topology domain'leri arasındaki replica farkının ne kadar olabileceğini belirler. Düşük değer daha dengeli dağılım hedefler. Ancak bir zone'da kapasite bulunmazsa çok katı ayar yeni Pod'u Pending bırakabilir. `whenUnsatisfiable` davranışı bu noktada önemlidir. Availability ile scheduling esnekliği arasında uygulama ihtiyacına uygun denge kurulmalıdır.

Single-Zone Hotspot Önleme

Tüm yeni replica'ların boş kapasite bulunan tek zone'a yerleşmesi trafik ve failure riskini yoğunlaştırabilir. Topology spread bu durumu azaltır. Same-zone routing kullanılıyorsa hotspot etkisi daha görünür olabilir. Zone bazında CPU ve RPS dashboard'ları dengesizliği hızlı gösterir. Node autoscaler da yalnızca tek zone'da kapasite açmayacak şekilde uygun esnekliğe sahip olmalıdır.

HPA ile Yeni Pod'ların Dağılımı

HPA yalnızca desired replica sayısını belirler, yeni Pod'ların fiziksel yerleşimini scheduler yapar. Topology spread constraints bu nedenle HPA'nın doğal tamamlayıcısıdır. Replica sayısı arttıkça yeni Pod'lar farklı node ve zone'lara yayılabilir. Bir zone kapasitesi doluysa Pending Pod veya dengesiz dağılım görülebilir. HPA başarı metriği olarak yalnızca replica sayısı değil topology dağılımı da izlenmelidir.

PodDisruptionBudget ve Autoscaling

PodDisruptionBudget, gönüllü kesintiler sırasında belirli sayıda replica'nın kullanılabilir kalmasını hedefler. Node autoscaler scale-down için node boşaltmak istediğinde PDB Pod eviction işlemini engelleyebilir. Bu availability açısından yararlıdır, fakat aşırı katı PDB boş node'ların silinmesini durdurup maliyet oluşturabilir. `minAvailable` veya `maxUnavailable` değerleri gerçek replica sayısı ve failure hedefiyle uyumlu olmalıdır. HPA scale-down ve node scale-down aynı döneme geldiğinde bu ilişkiler özellikle test edilmelidir.

PDB Nedir?

PDB planlı veya gönüllü Pod disruption işlemlerinde uygulamanın minimum kullanılabilir kapasitesini korumaya yardımcı olan politikadır. Node drain ve bazı autoscaler scale-down süreçleri bu bütçeye saygı gösterir. PDB tüm arıza türlerini önleyen bir availability garantisi değildir. Ani node kaybı gönüllü disruption sayılmaz. Yine de maintenance ve consolidation sırasında önemli bir güvenlik katmanıdır.

minAvailable

`minAvailable` disruption sırasında en az kaç Pod'un kullanılabilir kalması gerektiğini belirtir. Üç replica çalışan uygulamada minAvailable üç seçilirse gönüllü eviction için hiç alan kalmayabilir. Bu durum node scale-down işlemini engeller. HPA minimum replica sayısıyla PDB değerinin uyumlu olması gerekir. Availability hedefini korurken en az bir kontrollü disruption alanı bırakmak çoğu sistem için faydalıdır.

maxUnavailable

`maxUnavailable`, aynı anda kaç replica'nın gönüllü disruption nedeniyle kullanılabilir olmamasına izin verildiğini belirtir. Yüzde veya sabit sayı kullanılabilir. Büyük deployment'larda yüzde tabanlı değer daha esnek olabilir. HPA replica sayısı değiştikçe izin verilen disruption miktarı da buna göre değişebilir. Node consolidation davranışı bu değerlerle gerçek yük altında test edilmelidir.

Node Scale-Down

Node scale-down sırasında autoscaler node üzerindeki Pod'ları başka node'lara taşımak ister. PDB yeterli disruption bütçesi yoksa eviction engellenebilir. Böyle durumda node düşük kullanımlı olsa bile silinmez. Scheduler constraint'leri nedeniyle Pod başka node'a sığmıyorsa aynı sonuç oluşabilir. Scale-down blocker metric veya event'lerini maliyet dashboard'unda izlemek faydalıdır.

PDB Nedeniyle Node'un Silinememesi

Çok katı PDB node'un boşaltılmasını uzun süre engelleyebilir. Özellikle `minAvailable` replica sayısına eşitse gönüllü tek Pod eviction bile mümkün olmayabilir. Bu durum rolling update ve maintenance süreçlerini de yavaşlatır. PDB yalnızca “daha yüksek sayı daha güvenlidir” mantığıyla ayarlanmamalıdır. Availability hedefi ve operasyonel hareket alanı birlikte düşünülmelidir.

Availability ve Cost Dengesi

PDB availability sağlamak için belirli kapasiteyi korur, fakat bu karar node maliyetini artırabilir. Çok az disruption alanı cluster'ın gereksiz node tutmasına neden olabilir. Çok geniş disruption alanı ise maintenance sırasında kullanıcı latency'sini etkileyebilir. Uygulama SLO'su kabul edilebilir kesinti bütçesini belirlemelidir. Cost optimizasyonu availability kurallarını körü körüne gevşetmek yerine ölçülebilir hedeflerle yapılmalıdır.

Stateful Workload'larda Autoscaling

Stateful workload'larda yatay ölçekleme stateless API'lere göre daha fazla veri ve koordinasyon sorunu içerir. Yeni replica açmak her zaman yeni kapasite anlamına gelmez, çünkü veri replikasyonu veya shard dağılımı gerekebilir. StatefulSet sabit network kimliği ve storage ilişkisi sunar, ancak otomatik database scaling problemini tek başına çözmez. Persistent volume topology kısıtları scheduler ve node autoscaler davranışını etkileyebilir. VPA veya uygulamaya özgü operator'lar bazı senaryolarda yatay replica artışından daha uygun olabilir.

Stateless ve Stateful Farkı

Stateless Pod herhangi bir replica üzerinde aynı request'i işleyebilirken stateful workload belirli veri veya kimliğe bağlı olabilir. Bu fark load balancing ve autoscaling tasarımını değiştirir. Stateless sistemde HPA yeni Pod'u hızlı biçimde kullanabilir. Stateful sistemde yeni replica'nın veri senkronizasyonu zaman alabilir. Capacity planning veri dağılımını da hesaba katmalıdır.

StatefulSet

StatefulSet Pod'lara kararlı isim ve sıralı kimlik sağlayan workload türüdür. Persistent volume ilişkileri replica yeniden oluşsa bile korunabilir. Database veya queue sistemlerinde faydalıdır. HPA ile StatefulSet ölçeklemek teknik olarak mümkün olsa da uygulamanın yeni replica'yı nasıl kullandığı ayrıca değerlendirilmelidir. Cluster üyelik ve veri replikasyon davranışı uygulamaya özeldir.

Persistent Volume

Persistent Volume stateful Pod'un verisini Pod yaşam döngüsünden bağımsız tutar. Storage class ve volume topology Pod'un hangi zone'a schedule edilebileceğini kısıtlayabilir. HPA yeni replica açtığında yeni PVC provisioning süresi gerçek scale-up süresine eklenebilir. Zone kapasite sorunu Pod'u Pending bırakabilir. Node autoscaler ile storage topology'nin uyumu production öncesinde test edilmelidir.

Database Scaling

Database scaling yalnızca daha fazla Pod açarak çözülemez. Write consistency, replication, sharding ve leader election gibi veri katmanı sorunları bulunur. HPA'nın otomatik olarak database replica artırması uygulamanın desteklemediği topolojiyi oluşturabilir. Database için uygulamaya özel operator veya managed service ölçekleme modeli tercih edilebilir. Kubernetes autoscaling araçları veri mimarisinin yerine geçmez.

Horizontal Scaling'in Sınırları

Stateful sistemde horizontal scaling partition veya shard sayısıyla sınırlı olabilir. Yeni replica veri taşımak için yoğun network ve disk kullanabilir. Trafik zirvesi sırasında rebalancing yapmak performansı daha da düşürebilir. Bu nedenle pre-scaling ve planlı kapasite artışı daha güvenli olabilir. Replica artış süresi gerçek veri boyutuyla test edilmelidir.

VPA Kullanımı

Stateful workload yatay olarak kolay ölçeklenemiyorsa VPA right-sizing açısından değerli olabilir. Daha fazla CPU veya memory tek replica'nın throughput'unu artırabilir. Ancak VPA resource update Pod restart gerektiriyorsa availability etkisi vardır. StatefulSet rollout sırası ve replication health izlenmelidir. Otomatik update yerine recommendation modu kritik veritabanlarında daha kontrollü bir başlangıç sunar.

Kafka Consumer Autoscaling

Kafka consumer workload'larında CPU çoğu zaman en iyi scaling metriği değildir. Asıl amaç consumer lag değerini kabul edilebilir sınırda tutmaktır. KEDA Kafka scaler veya custom metrics yaklaşımı lag üzerinden replica sayısını artırabilir. Partition sayısı aynı anda aktif iş yapabilecek consumer sayısını sınırlar. Bu nedenle maximum replica değerini belirlerken topic partition sayısı ve tek mesaj işleme süresi birlikte değerlendirilmelidir.

CPU Neden Yetersiz Metric Olabilir?

Consumer mesaj beklerken CPU düşük olabilir, ancak lag hızla büyüyor olabilir. I/O ağırlıklı işlemde CPU gerçek iş kapasitesini doğru yansıtmaz. HPA yalnızca CPU'ya baktığında scale-up gecikebilir. Kullanıcı veya veri pipeline gecikmesi CPU yükselmeden önce bozulabilir. Lag ve queue age daha erken sinyal sağlayabilir.

Consumer Lag

Consumer lag producer ile consumer ilerlemesi arasındaki farkı gösterir. Lag sürekli büyüyorsa tüketim kapasitesi üretim hızının altında kalmıştır. Autoscaling lag değerini hedef aralıkta tutmak için replica artırabilir. Sıfır lag her zaman hedef olmak zorunda değildir, çünkü gereksiz kapasite maliyeti oluşturabilir. Kabul edilebilir işleme gecikmesine göre threshold belirlenmelidir.

Partition Sayısı

Kafka consumer group içinde aynı partition aynı anda tek consumer tarafından işlenir. Bu nedenle partition sayısı faydalı paralellik için doğal bir üst sınır oluşturur. Sekiz partition olan topic'te yüz replica açmak çoğu durumda doksan iki idle consumer üretir. Autoscaler max replica bu yapıyı bilmeli veya metric hesabı sınırlandırılmalıdır. Partition sayısını artırmak da ayrı performans ve operasyon sonuçları doğurur.

KEDA

KEDA Kafka scaler lag metriğini doğrudan event-driven scaling'e bağlayabilir. Worker sayısı queue backlog'a göre artıp azalabilir. Scale-to-zero seyrek kullanılan topic consumer'larında maliyet avantajı sağlayabilir. İlk mesaj geldiğinde cold start gecikmesi varsa minimum replica tutulabilir. Authentication ve broker erişim hatalarının fallback davranışı test edilmelidir.

Maximum Useful Replica Count

Maksimum faydalı replica sayısı yalnızca HPA `maxReplicas` alanından ibaret değildir. Kafka partition sayısı, downstream throughput ve Pod başına işlem kapasitesi gerçek üst sınırı belirler. Daha fazla replica connection sayısını artırıp broker ve veritabanına zarar verebilir. Load testte throughput'un hangi replica sayısından sonra artmadığı bulunmalıdır. Bu noktadan daha yüksek max replica yalnızca maliyet ve operasyon yükü yaratabilir.

Batch Job'larda Otomatik Ölçekleme

Batch workload'lar kullanıcı request'i yerine bekleyen işler üzerinden kapasiteye ihtiyaç duyar. Queue-based scaling iş sayısı yükseldiğinde worker veya Job paralelliğini artırabilir. KEDA ScaledJob bu modele uygun araçlardan biridir. Ani batch burst sırasında node kapasitesi de hızla büyümek zorunda kalabilir. İşler tamamlandığında hem Pod hem node seviyesinde scale-down yapılarak maliyet azaltılabilir.

Queue-Based Scaling

Queue-based scaling bekleyen iş sayısını doğrudan replica veya Job kapasitesine bağlar. İşler aynı maliyetteyse queue length iyi bir başlangıç metriğidir. Farklı iş boyutlarında queue age ve estimated processing time daha anlamlı olabilir. Scale-up downstream service concurrency limitini aşmamalıdır. Backpressure olmadan yüzlerce worker açmak sistemi daha hızlı değil daha kararsız hale getirebilir.

KEDA ScaledJob

ScaledJob event geldiğinde Kubernetes Job örnekleri oluşturarak batch işlerini paralelleştirebilir. Her Job belirli işi tamamlayıp sonlanabilir. Bu model uzun yaşayan worker Deployment yerine iş bazlı lifecycle sunar. Çok hızlı Job creation API server ve scheduler üzerinde burst oluşturabilir. Maximum replica ve polling ayarları cluster kapasitesine göre sınırlandırılmalıdır.

Node Burst Capacity

Batch burst sırasında mevcut node'lar kısa sürede dolabilir. Node autoscaler yeni kapasite ekleyene kadar Job'lar Pending kalır. Uzun node startup süresi batch completion SLO'sunu etkiler. Planlı batch pencerelerinde önceden warm node açmak daha hızlı sonuç verebilir. Node provisioning metric'i batch platform dashboard'unda izlenmelidir.

Spot Instance

Kesintiye toleranslı batch işler spot kapasite için uygun aday olabilir. İş yarıda kesildiğinde tekrar denenebiliyorsa maliyet avantajı sağlanabilir. Checkpoint olmayan çok uzun işlerde interruption maliyeti daha yüksektir. KEDA ve node provisioning politikası spot ile on-demand kapasiteyi birlikte kullanabilir. İş başına gerçek maliyet interruption oranıyla birlikte ölçülmelidir.

İş Tamamlandıktan Sonra Scale-Down

Queue boşaldığında worker veya Job kapasitesinin düşmesi batch maliyetinin önemli bölümünü kontrol eder. KEDA cooldown değerleri replica azaltım hızını etkiler. Node autoscaler boş node'ları kaldırırken PDB veya başka Pod'lar engel oluşturabilir. Scale-down çok erken olursa hemen gelen yeni batch için tekrar cold node açılır. Batch arrival pattern'e göre kısa warm pencere tutulabilir.

GPU ve AI Workload'larında Autoscaling

GPU workload autoscaling CPU tabanlı web servislerinden farklı maliyet ve provisioning özelliklerine sahiptir. GPU node'ları pahalıdır ve bazı bölgelerde kapasite bulunması zor olabilir. Model server replica sayısı GPU memory, queue depth, batch size ve inference latency gibi sinyallerle ilişkilendirilmelidir. Karpenter veya başka node autoscaler GPU isteyen Pending Pod için uygun node sağlayabilir. Büyük model yükleme süresi nedeniyle reactive scaling tek başına ani peak trafiğe yetişmeyebilir.

GPU Node Pool

GPU node pool özel accelerator donanımı taşıyan node'ları diğer workload'lardan ayırır. Taint ve toleration kullanılarak genel Pod'ların pahalı GPU node'larına yerleşmesi engellenebilir. Node autoscaler yalnızca GPU isteyen workload için bu havuzu büyütmelidir. Minimum warm GPU sayısı cold start ile maliyet arasındaki dengeyi belirler. GPU quota ve bölgesel capacity riski önceden kontrol edilmelidir.

GPU Scheduling

Pod GPU resource request belirttiğinde scheduler yalnızca uygun accelerator kapasitesi bulunan node'ları seçebilir. Bir GPU modeli veya memory gereksinimi varsa node selector gibi constraint'ler eklenebilir. Çok dar constraint uygun instance bulunmasını zorlaştırır. Pending Pod event'leri GPU resource eksikliğini açıkça göstermelidir. Node autoscaler GPU instance provisioning başarısızlıklarını ayrı alert olarak raporlamalıdır.

Model Server Replicas

Model server replica sayısı yalnızca gelen request sayısına göre belirlenmemelidir. Model başına GPU memory, batching davranışı ve request token uzunluğu throughput'u büyük ölçüde etkiler. Aynı RPS farklı prompt uzunluklarında çok farklı GPU yükü oluşturabilir. Queue depth veya active tokens gibi model-aware metrikler daha iyi scaling sinyali sağlayabilir. Replica kapasitesi gerçek inference benchmark'ıyla ölçülmelidir.

GPU Utilization

GPU utilization inference kapasitesini anlamak için yararlı bir metrik olsa da tek başına yeterli değildir. Memory bandwidth, VRAM kullanımı veya batching nedeniyle düşük GPU utilization altında yüksek latency görülebilir. Model server queue'su daha erken doygunluk sinyali verebilir. HPA custom metric veya KEDA trigger ile queue depth kullanılabilir. GPU utilization kontrol metriği olarak dashboard'da mutlaka izlenmelidir.

Queue Depth

Inference request'leri model server önünde kuyruklanıyorsa queue depth kullanıcı latency'sini CPU veya GPU utilization'dan önce gösterebilir. Kuyruk büyüdükçe yeni model replica ihtiyacı ortaya çıkar. Ancak model yükleme süresi dakikalar sürüyorsa reactive scale-up geç kalabilir. Minimum warm replica veya predictive scaling bu yüzden önemlidir. Queue age metriği de kullanıcı bekleme süresini doğrudan gösterir.

Karpenter ve GPU Node Provisioning

Karpenter workload GPU request'ine göre uygun accelerator node seçimi yapabilecek şekilde yapılandırılabilir. NodePool hangi GPU instance ailelerinin ve zone'ların kullanılabileceğini sınırlar. Birden fazla uygun seçenek capacity bulunabilirliğini artırabilir. GPU node açıldıktan sonra driver ve model hazırlığı da toplam provisioning süresine eklenir. End-to-end scale time yalnızca cloud instance creation olarak ölçülmemelidir.

LLM Inference Yük Dengeleme

LLM inference request'leri token sayısı, context uzunluğu ve generation süresi nedeniyle birbirinden çok farklı maliyete sahip olabilir. Bu yüzden klasik round-robin her replica'ya eşit sayıda request gönderse bile gerçek GPU yükünü eşit dağıtmayabilir. KV cache ve session state belirli model server ile ilişki kurabilir. Model-aware routing aktif sequence veya token yüküne göre daha bilinçli backend seçimi yapmayı hedefler. Gateway API çevresindeki inference odaklı geliştirmeler bu alanın Kubernetes trafik yönetiminde giderek daha önemli hale geldiğini gösterir.

Geleneksel Round-Robin Neden Yetersiz Kalabilir?

İki LLM request'i aynı request sayısına sahip olsa da işlem maliyetleri tamamen farklı olabilir. Biri kısa prompt ve on token çıktı isterken diğeri uzun context ve bin token generation yapabilir. Round-robin her iki backend'e birer request göndererek eşit dağılım yaptığını düşünür. Gerçekte bir GPU uzun süre meşgul kalabilir. Backend seçimini active tokens veya queue load gibi metriklerle desteklemek daha dengeli sonuç verebilir.

Uzun Süren Inference Request'leri

LLM generation request'leri saniyeler veya daha uzun süre açık kalabilir. Streaming response boyunca backend GPU kapasitesi kullanılmaya devam eder. HPA yeni replica eklediğinde mevcut request'ler yeni Pod'a taşınmaz. Bu durum uzun bağlantılı load balancing problemine benzer. Active sequence ve queue metric'leri kapasite ihtiyacını daha doğru gösterebilir.

KV Cache ve Session State

KV cache aynı conversation veya prefix için yeniden hesaplama maliyetini azaltabilir. Fakat cache belirli Pod veya GPU üzerinde tutulduğunda routing stateful hale gelir. Kullanıcı isteğini başka replica'ya göndermek cache hit avantajını kaybettirebilir. Tam sticky routing ise yük dengesizliği oluşturabilir. Model serving mimarisinde cache locality ile load distribution arasında bilinçli denge kurulmalıdır.

GPU Utilization

GPU utilization LLM server yükünü anlamak için önemli olsa da request maliyetini tek başına anlatmaz. Memory occupancy ve token throughput ayrıca izlenmelidir. Dynamic batching GPU utilization'ı yükseltirken kullanıcı latency'sini de etkileyebilir. Scaling metriği p95 latency veya queue age ile desteklenebilir. Model server'ın batching algoritması HPA hedeflerinden bağımsız düşünülmemelidir.

Model-Aware Routing

Model-aware routing backend seçiminde model kimliği, queue depth, KV cache veya active request bilgisi gibi sinyalleri kullanmayı hedefler. Farklı model boyutları veya quantization sürümleri aynı cluster'da bulunabilir. Route yalnızca Service adına bakmak yerine gerçek serving kapasitesini değerlendirebilir. Bu yaklaşım LLM workload'larında basit connection balancing'den daha iyi GPU kullanımı sağlayabilir. Gözlemlenebilirlik ve fallback davranışı production tasarımının temel parçaları olmalıdır.

Gateway API Inference Extension

Gateway API ekosisteminde inference workload'ları için model-aware routing ihtiyaçlarını ifade etmeye yönelik çalışmalar bulunmaktadır. Bu alan hızla geliştiği için production tasarımında kullanılan extension sürümü ve implementation desteği mutlaka kontrol edilmelidir. Amaç model serving trafik yönetimini standart Gateway API kaynaklarıyla uyumlu biçimde genişletmektir. Yeni özellikler prototip aşamasında denenebilir, fakat core production akışı olgunluk seviyesi doğrulanmadan buna bağlanmamalıdır. Upgrade ve fallback planı özellikle önemlidir.

Load Balancing + Model Autoscaling

LLM platformunda load balancing backend GPU'lar arasında iş dağıtır, autoscaling ise yeterli model replica ve GPU node kapasitesini oluşturur. Queue büyüdüğünde model replica artabilir, yeni Pod için GPU kapasitesi yoksa node autoscaler devreye girer. Model loading süresi uzun olduğu için warm capacity kritik hale gelir. New replica hazır olduğunda model-aware router gerçek trafiği ona yönlendirebilmelidir. Bu zincirin her adımı token throughput ve kullanıcı latency'si üzerinden ölçülmelidir.

Multi-AZ Kubernetes Tasarımı

Multi-AZ Kubernetes tasarımı node ve Pod kapasitesini birden fazla availability zone'a dağıtarak tek zone arızasına karşı dayanıklılığı artırır. Bunun için yalnızca node'ların farklı zone'da bulunması yeterli değildir, replica'ların ve kritik bağımlılıkların da uygun şekilde dağılması gerekir. Cross-zone trafik maliyeti ve latency aynı-zone routing tercihlerini önemli hale getirir. Node autoscaler her zone'da kapasite sağlayamayabilir ve cloud capacity shortage görülebilir. Failure testleri bir zone tamamen devre dışı kaldığında kalan kapasitenin SLO'yu taşıyıp taşıyamadığını doğrulamalıdır.

Pod'ları Birden Fazla Zone'a Dağıtmak

Topology spread constraints Pod replica'larını availability zone'lara daha dengeli yayabilir. Bu sayede tek zone kaybında uygulamanın tüm replica'ları kaybolmaz. Minimum replica sayısı zone sayısıyla uyumlu olmalıdır. Üç zone'da iki replica kullanan uygulama doğal olarak bir zone'u boş bırakacaktır. Kritik servislerde minimum replica ve topology spread birlikte belirlenmelidir.

Cross-Zone Traffic

İstemci bir zone'dayken backend başka zone'da olduğunda cross-zone network oluşabilir. Bu durum latency ve cloud network maliyeti yaratabilir. Same-zone routing tercihi bu trafiği azaltabilir. Ancak local zone kapasitesi yetersiz olduğunda availability daha önemli hale gelir. Routing optimizasyonu failover esnekliğini kaybetmemelidir.

Same-Zone Routing

Same-zone routing yakın endpoint'i tercih ederek network maliyetini düşürmeye yardımcı olur. Pod'lar zone'lara dengeli dağılmışsa sonuç daha öngörülebilir olur. HPA bir zone'a daha fazla Pod yerleştiremiyorsa lokal trafik hotspot oluşturabilir. Node autoscaler ilgili zone'da yeni node sağlayabilmelidir. Zone başına RPS ve Ready replica grafikleri birlikte izlenmelidir.

Node Autoscaling

Multi-AZ node autoscaling birden fazla zone'da kapasite üretebilmelidir. Tek zone kapasitesi tükendiğinde alternatif zone seçenekleri availability sağlar. Stateful volume constraint'leri yine belirli zone'a bağımlılık oluşturabilir. Karpenter veya node group tasarımı zone çeşitliliğini desteklemelidir. Cloud capacity error oranı production alert'lerine dahil edilmelidir.

Zone Capacity Shortage

Cloud provider belirli zone'da istediğiniz instance type için geçici kapasite bulamayabilir. Autoscaler sürekli aynı zone ve instance'a bağlıysa Pending Pod sorunu uzar. Birden fazla instance type ve zone seçeneği esnekliği artırır. GPU workload'larında bu problem daha sık görülebilir. Capacity shortage chaos senaryosu olarak tasarlanıp failover davranışı test edilmelidir.

Zone Failure

Zone failure durumunda o bölgedeki node ve Pod'ların tamamı kaybedilebilir. Kalan zone'lar toplam trafiği karşılayacak warm veya autoscalable kapasiteye sahip olmalıdır. HPA ve node autoscaler yeni replica'ları kalan zone'larda oluşturabilir, ancak provisioning süresi vardır. Bu süre boyunca minimum kapasite SLO'yu korumalıdır. Gerçek disaster testleri yalnızca teorik mimari diyagramdan daha değerlidir.

Multi-Cluster Load Balancing

Birden fazla Kubernetes cluster kullanmak bölgesel failover, kapasite izolasyonu veya organizasyonel ayrım sağlayabilir. Global traffic management istemciyi uygun cluster'a yönlendirir. Active-active model iki veya daha fazla cluster'ın aynı anda trafik taşımasını sağlarken active-passive model yedek cluster'ı beklemede tutar. Multi-Cluster Services ve Gateway API çevresindeki yaklaşımlar servis erişimini cluster sınırlarının ötesine taşımayı amaçlar. Ancak state, veri replikasyonu ve global session yönetimi tek cluster autoscaling'den daha geniş bir mimari problem oluşturur.

Neden Birden Fazla Cluster?

Tek cluster birçok uygulama için yeterlidir, bu nedenle multi-cluster varsayılan hedef olmamalıdır. Bölgesel arıza toleransı, regülasyon veya çok büyük blast radius kontrolü gibi açık gerekçeler varsa anlamlı hale gelir. Her ek cluster operasyon, observability ve deployment yükünü artırır. Autoscaling politikalarının cluster'lar arasında farklı davranması kapasite dengesizliği yaratabilir. Multi-cluster kararı ölçülebilir risk azaltımına dayanmalıdır.

Regional Failover

Regional failover bir bölge tamamen erişilemez olduğunda trafiğin başka bölgedeki cluster'a aktarılmasını sağlar. Yedek bölgenin kapasitesi failure anında yeterli olmalıdır. Sıfır warm kapasite ile tüm node'ları failover sırasında açmak recovery süresini uzatabilir. DNS veya global load balancer failover süresi ayrıca ölçülmelidir. Data replication gecikmesi kullanıcı deneyimi açısından network routing kadar kritiktir.

Global Traffic Management

Global traffic management kullanıcıları coğrafi konum, health veya policy bilgisine göre uygun bölgesel cluster'a yönlendirebilir. Her cluster kendi Gateway ve Service katmanına sahip olabilir. Trafik oranı değiştiğinde cluster içi HPA ve node autoscaler buna tepki verir. Global load balancer hızlı trafik kaydırırsa hedef cluster'ın warm kapasitesi yetersiz kalabilir. Bölgesel capacity limit ve failover ramp-up politikası birlikte tasarlanmalıdır.

Active-Active

Active-active model birden fazla cluster'ın normal zamanda aynı anda trafik taşımasını sağlar. Bu yöntem yedek kapasiteyi boşta tutmak yerine aktif kullanabilir. Bölge arızasında kalan cluster'lar kaybolan trafiği üstlenir. Her cluster normalde yüzde elli yükte çalışıyorsa tek cluster kaybında diğerinin aniden yüzde yüz veya daha fazla trafik taşıması gerekir. Autoscaling tepki süresi nedeniyle yeterli headroom bırakılmalıdır.

Active-Passive

Active-passive model ana cluster trafiği taşırken yedek cluster minimum veya düşük kapasitede bekler. Maliyet active-active modele göre farklı olabilir. Failover sırasında passive cluster hızlı şekilde kapasite artırmalıdır. Node ve Pod cold start toplam recovery time'ı etkiler. Kritik sistemlerde tamamen sıfır kapasite yerine minimum warm servis katmanı tutulabilir.

Multi-Cluster Services

Multi-Cluster Services bir Service'i birden fazla cluster backend'i üzerinden keşfetme ve erişme problemini standartlaştırmayı hedefleyen Kubernetes yaklaşımıdır. Kullanım ve destek durumu platforma göre değerlendirilmelidir. Global failover ile uygulama service discovery tasarımını birbirinden ayırmak faydalıdır. Stateful bağımlılıklar yine ayrı veri replikasyonu gerektirir. Multi-cluster networking production öncesinde network partition testleriyle doğrulanmalıdır.

Gateway API ile Gelecek Yaklaşımlar

Gateway API rol ve route modelinin cluster'lar arası trafik yönetimine genişletilmesi cloud-native networking için önemli bir gelişim alanıdır. Ancak her özellik aynı olgunluk seviyesinde değildir. Production mimarisinde kullanılan implementasyonun desteklediği release channel ve conformance bilgisi kontrol edilmelidir. Yeni API'ler önce laboratuvar ortamında test edilmelidir. Multi-cluster sistemde standart API kadar operasyon ve failover otomasyonu da başarı için belirleyicidir.

Kubernetes Autoscaling'de Maliyet Optimizasyonu

Autoscaling maliyet optimizasyonu yalnızca replica sayısını mümkün olduğunca azaltmak değildir. Doğru minimum ve maksimum replica, gerçekçi resource request, VPA right-sizing, node consolidation ve gerektiğinde spot kapasite birlikte değerlendirilir. Scale-to-zero düşük kullanımlı workload'larda güçlü tasarruf sağlayabilir. Cross-zone network maliyeti de compute maliyeti kadar önemli hale gelebilir. Hedef kullanıcı SLO'sunu koruyarak başarılı request başına toplam cloud maliyetini düşürmektir.

Minimum Replica

Minimum replica değeri boş trafik dönemindeki taban maliyeti belirler. Çok yüksek değer gereksiz compute tüketir. Çok düşük değer ani burst ve Pod failure sırasında latency artışı oluşturabilir. Zone sayısı ve startup süresi minimum değeri belirleyen önemli girdilerdir. Tasarruf amacıyla minimum replica düşürüldüğünde load spike testi tekrarlanmalıdır.

Maximum Replica

Maximum replica kontrolsüz cost artışını sınırlar, fakat peak kapasitenin altında seçilmemelidir. Gerçek sınır database ve downstream connection kapasitesiyle de uyumlu olmalıdır. Yüksek max replica kötü bir retry storm sırasında yüzlerce Pod açılmasına yol açabilir. Rate limiting ve circuit breaker bu riski azaltır. Max replica bir güvenlik limiti olarak düzenli capacity test ile güncellenmelidir.

Resource Requests

Resource request node packing ve HPA utilization davranışının merkezindedir. Fazla request daha çok node, düşük request ise throttling ve gereksiz HPA hareketi yaratabilir. Production telemetry ile p50, p95 ve peak kaynak kullanımı analiz edilmelidir. Request değerleri release'lerle birlikte değişebilir. Düzenli right-sizing cloud maliyetinde büyük fark yaratabilir.

VPA Right-Sizing

VPA recommendation resource kullanım trendlerinden öneriler üretir. Bu değerler aşırı yüksek veya düşük request'leri bulmak için kullanılabilir. Otomatik update gerekmeksizin FinOps ve platform ekiplerine veri sağlayabilir. Öneriler peak ve failure headroom dikkate alınarak uygulanmalıdır. Her request düşüşü sonrası load test yapılması güvenli yaklaşımdır.

Node Consolidation

Node consolidation düşük kullanılan node'ların daha az veya daha uygun kapasite üzerinde yeniden düzenlenmesini sağlar. Bu yöntem özellikle değişken workload'larda önemli maliyet tasarrufu oluşturabilir. Pod disruption ve PDB kısıtları dikkate alınmalıdır. Çok sık consolidation node churn ve cache cold start oluşturabilir. Tasarruf ile disruption oranı aynı dashboard'da karşılaştırılmalıdır.

Spot Instances

Spot instance uygun workload'larda compute maliyetini azaltır. Kesinti toleranslı batch ve stateless replica'lar iyi aday olabilir. Kritik servis kapasitesinin tamamını spot'a taşımak risklidir. On-demand taban kapasite ile spot burst kapasitesi birlikte kullanılabilir. Interruption oranı ve yeniden scheduling süresi SLO açısından ölçülmelidir.

Scale-to-Zero

Scale-to-zero düşük kullanım sürelerinde Pod maliyetini azaltır. Node autoscaler da boş node'u kaldırabiliyorsa tasarruf compute seviyesine yansır. Ancak yeniden trafik geldiğinde Pod ve node cold start süresi ortaya çıkar. Kullanıcıya dönük kritik API'lerde bu latency kabul edilmeyebilir. Workload sınıfına göre farklı minimum kapasite politikası belirlemek daha doğrudur.

Cross-Zone Network Cost

Cross-zone network trafiği yüksek RPS sistemlerinde ciddi maliyet yaratabilir. Same-zone tercihleri ve dengeli Pod dağılımı bu maliyeti azaltabilir. Ancak network tasarrufu için availability'den vazgeçilmemelidir. Zone kapasitesi yetersiz olduğunda başka zone'a trafik gidebilmelidir. Compute ve network maliyetini aynı FinOps raporunda görmek gerçek optimizasyon fırsatlarını daha iyi gösterir.

Availability ile Maliyet Arasındaki Denge

En ucuz Kubernetes cluster genellikle en az kapasiteyi tutan cluster değildir, çünkü başarısız istekler ve SLO ihlalleri iş açısından daha yüksek maliyet yaratabilir. Warm kapasite ani trafik artışını ve node failure'ı karşılamak için gereklidir. Minimum Pod ve node sayıları failure domain yapısına göre belirlenmelidir. Autoscaling gereksiz boş kapasiteyi azaltır, fakat tamamen sıfır headroom hedeflememelidir. Cloud maliyeti ile availability aynı karar tablosunda değerlendirilmelidir.

Çok Agresif Scale-Down

Trafik düşer düşmez replica ve node sayısını hızla azaltmak kısa vadede tasarruf sağlar. Fakat trafik birkaç dakika içinde geri dönerse yeni cold start gerekir. Bu durum kullanıcı latency'sini artırır ve node provisioning maliyeti oluşturur. Stabilization ve cooldown süreleri bu yüzden önemlidir. Trafik dalga periyodu ölçülerek scale-down hızı ayarlanmalıdır.

Warm Capacity

Warm capacity aktif trafiğin üzerinde hazır tutulan güvenlik payıdır. Pod veya node failure sırasında sistemi hemen doygunluğa girmekten korur. HPA yeni kapasite hazırlanana kadar bu pay peak yükü taşır. Çok yüksek warm kapasite maliyetlidir, fakat sıfır headroom da risklidir. SLO ve startup süreleri kullanılarak gerekli oran load testte bulunmalıdır.

Minimum Pod Sayısı

Minimum Pod sayısı uygulama availability hedefinin temel parçalarından biridir. Tek replica restart sırasında downtime yaratabilir. Multi-zone uygulamada replica sayısı zone yayılımını desteklemelidir. HPA minimum değeri yalnızca düşük trafik ortalamasına göre belirlenmemelidir. Failure senaryosunda kalan replica kapasitesi test edilmelidir.

Minimum Node Sayısı

Minimum node sayısı cluster'ın Pod failure ve topology dağılımı için taban kapasitesini belirler. Tek node üzerinde birden fazla replica çalışıyorsa node kaybı beklenenden büyük etki yaratır. En az birkaç failure domain üzerinde kapasite tutmak kritik uygulamalarda anlamlıdır. Node autoscaler boş node'ları kaldırırken bu minimum sınırları korur. Zone başına taban kapasite gereksinimi ayrıca değerlendirilebilir.

SLO ve Cloud Cost

SLO kullanıcıya verilen hizmet hedefini tanımlar ve maliyet kararlarına sınır koyar. Yüzde 99,9 availability ile yüzde 99,99 hedefi aynı kapasite ve failover yatırımı gerektirmez. Her ekstra replica'nın maliyeti SLO ihlal riskindeki azalmayla karşılaştırılmalıdır. Bu yaklaşım altyapı tartışmasını yalnızca “kaç node kullandık” seviyesinden çıkarır. İş değeri ile teknik kapasite arasında daha anlaşılır bağlantı kurar.

Failover Kapasitesi

Failover kapasitesi Pod, node veya zone kaybında kalan sistemin trafiği taşıyabilmesini sağlar. Normal durumda yüzde doksan utilization ile çalışmak failure anında yeterli boş alan bırakmayabilir. HPA ve node autoscaler yeni kapasite ekleyebilir, fakat bunun zaman maliyeti vardır. En kritik trafiği bu süre boyunca warm kapasite karşılamalıdır. Failure testleri gerekli headroom oranını gerçek verilerle belirler.

Autoscaling İçin SLO-Based Yaklaşım

SLO-based autoscaling yalnızca CPU yüzdesini değil kullanıcı deneyimini ve hizmet hedeflerini tasarımın merkezine koyar. p95 latency, error rate, queue age, throughput ve saturation gibi sinyaller gerçek hizmet durumunu daha iyi anlatır. Scaling metriği doğrudan SLO metriği olmak zorunda değildir, fakat scaling sonucunun SLO'yu koruduğu ölçülmelidir. Örneğin RPS HPA'yı tetiklerken p95 latency kararın başarılı olup olmadığını doğrulayabilir. Bu yaklaşım kapasiteyi teknik sayılardan iş etkisine bağlar.

CPU Yerine Kullanıcı Deneyimini Ölçmek

CPU yüzde yetmiş olduğu için kullanıcı deneyiminin kötü olduğunu varsayamayız. Bazı uygulamalar yüzde doksan CPU'da kabul edilebilir latency sunarken bazıları yüzde kırkta database beklediği için yavaş olabilir. Kullanıcı latency ve error rate gerçek hizmet kalitesini gösterir. CPU yine saturation metriği olarak değerlidir. Autoscaling hedefi kaynak yüzdesi değil, SLO'nun korunması olmalıdır.

p95 Latency

p95 latency isteklerin yüzde doksan beşinin hangi sürede tamamlandığını gösterir. Ortalama latency birkaç çok yavaş isteği gizleyebilir. p95 yükseldiğinde kapasite veya downstream sorunu oluşuyor olabilir. HPA'nın scale-up sonrası p95'i hedef aralığa indirip indirmediği izlenmelidir. Aksi halde daha fazla Pod açmak gerçek darboğazı çözmüyor demektir.

Error Rate

Error rate capacity saturation, timeout veya deployment hatalarının doğrudan kullanıcı etkisini gösterir. Trafik spike'ında 5xx yükseliyorsa autoscaling yeterince hızlı olmayabilir. Ancak uygulama bug'ı da aynı metriği yükseltebilir. Error rate tek başına replica artırma sinyali olarak dikkatli kullanılmalıdır. SLO alert'i ve scaling başarısı doğrulaması için güçlü bir metriktir.

Queue Age

Queue age asynchronous işlerin ne kadar süredir beklediğini gösterir. Kullanıcıya “işiniz beş dakika içinde tamamlanacak” SLO'su verildiyse queue age doğrudan bu hedefle ilişkilidir. Queue length aynı kalsa bile işleme süresi uzadığında age yükselir. KEDA scaling ile backlog azaltılabilir. Downstream kapasite limitleri maksimum worker sayısını belirlemelidir.

Throughput

Throughput sistemin birim zamanda tamamladığı başarılı iş miktarını gösterir. Replica artışı throughput'u yükseltmiyorsa başka bir darboğaz vardır. Database, lock veya external API limiti yatay scaling kazancını sınırlayabilir. Load testte replica sayısı ile throughput eğrisi çıkarılmalıdır. Eğrinin yataylaştığı nokta maksimum faydalı kapasiteyi gösterir.

Saturation

Saturation sistem kaynağının kapasite sınırına ne kadar yaklaştığını anlatır. CPU, worker pool, connection pool veya queue occupancy saturation göstergesi olabilir. Kullanıcı latency bozulmadan önce saturation artıyorsa erken scaling sinyali sağlar. Her uygulamada doğru saturation metriği farklıdır. Performans profilleme bu metriği bulmanın en güvenilir yoludur.

Load Test ile Autoscaling Nasıl Test Edilir?

Autoscaling yalnızca YAML apply işlemiyle doğrulanamaz, kontrollü load test gerekir. Test ortamı production topolojisine, resource request değerlerine ve startup süresine mümkün olduğunca benzemelidir. k6 veya Locust gibi araçlarla artan RPS, ani spike ve uzun süreli yük senaryoları uygulanabilir. Test yalnızca scale-up'ı değil trafik düştükten sonraki scale-down davranışını da kapsamalıdır. Desired replica, Ready replica, Pending Pod, node count, p95 latency ve error rate aynı zaman çizgisinde izlenmelidir.

Test Ortamı

Autoscaling testi laptop üzerinde tek node cluster'da yapıldığında production node provisioning ve network davranışı görülmez. En azından benzer resource request, probe ve gateway yapılandırması kullanılmalıdır. Cloud node autoscaling test edilecekse gerçek provisioning süresi ölçülmelidir. Test verisi production'a zarar vermeyecek izole ortamda çalışmalıdır. Database veya queue kapasitesi de gerçekçi sınırlar içinde temsil edilmelidir.

k6

k6 HTTP ve bazı protokol yük testleri oluşturmak için kullanılabilen açık kaynaklı araçlardan biridir. Virtual user ve request rate senaryolarıyla trafik rampası tasarlanabilir. Autoscaling testinde sabit RPS yerine farklı aşamalar kullanmak daha değerlidir. Örneğin beş dakika düşük yük, iki dakika hızlı artış ve on dakika sustained load uygulanabilir. Sonuçlar Kubernetes replica grafikleriyle aynı zaman ekseninde karşılaştırılmalıdır.

Locust

Locust Python tabanlı yük senaryoları yazmak isteyen ekipler için esnek bir test aracıdır. Kullanıcı davranışını task'lar üzerinden modellemek mümkündür. Farklı endpoint'lerin işlem maliyeti değişiyorsa gerçek kullanım oranlarını senaryoya eklemek önemlidir. Sadece en hafif endpoint'i test etmek HPA kapasite hedefini yanıltır. Load generator'ın kendisinin darboğaz olmadığından emin olunmalıdır.

Artan RPS

Artan RPS testi sistemin hangi talep seviyesinde scale-up başlattığını gösterir. RPS kademeli yükseltilerek CPU, latency ve replica değişimi gözlenebilir. HPA çok erken scale ediyorsa target veya request değerleri yeniden değerlendirilebilir. Çok geç scale ediyorsa kullanıcı latency'si SLO dışına çıkabilir. Pod başına sustainable RPS kapasitesi bu testten çıkarılabilir.

Ani Traffic Spike

Spike testi kısa süre içinde büyük trafik artışını taklit eder. Bu senaryo reactive autoscaling'in en zor durumlarından biridir. HPA metric'i görüp replica artırana kadar warm kapasite trafiği taşımak zorundadır. Node kapasitesi yoksa provisioning gecikmesi de eklenir. Test sırasında ilk hata zamanı ile ilk yeni Ready Pod zamanı karşılaştırılmalıdır.

Sustained Load

Sustained load sistemi uzun süre yüksek RPS altında tutar. Kısa benchmark'ta görünmeyen memory leak, connection pool ve cache problemleri bu testte ortaya çıkabilir. HPA replica sayısının zaman içinde kararlı kalması beklenir. Sürekli yükselen replica sayısı kapasite modelinde veya memory metriğinde sorun gösterebilir. Node ve application resource trendleri en az birkaç ölçekleme döngüsü boyunca izlenmelidir.

Scale-Down Testi

Yük kaldırıldıktan sonra replica sayısının nasıl azaldığı production maliyeti ve stability açısından önemlidir. Stabilization window nedeniyle hemen düşüş beklenmeyebilir. Pod termination sırasında 5xx veya connection reset oluşmamalıdır. Node autoscaler boş kapasiteyi daha sonra kaldırabilir. Scale-down testi graceful shutdown ve PDB hatalarını ortaya çıkarmak için özellikle değerlidir.

Autoscaling Testinde Hangi Metrikler İzlenmeli?

Autoscaling testinde tek bir CPU grafiği yeterli değildir. Desired replicas, current replicas ve Ready replicas kontrol düzleminin farklı aşamalarını gösterir. Pending Pods ve node count kapasite zincirindeki altyapı gecikmesini görünür kılar. RPS, p95 ve p99 latency ile error rate kullanıcı etkisini gösterir. Son olarak cost metriği performans iyileşmesinin ne kadar kaynakla elde edildiğini değerlendirmeyi sağlar.

Desired Replicas

Desired replicas HPA'nın o anda kaç replica istediğini gösterir. Bu değer metric kararının sonucudur, gerçek kullanılabilir kapasite değildir. Desired hızla artarken Ready sabit kalıyorsa scheduler veya startup problemi olabilir. Grafik diğer replica metrikleriyle birlikte okunmalıdır. HPA event ve condition bilgisi neden belirli sayıya ulaştığını açıklayabilir.

Current Replicas

Current replicas workload controller'ın mevcut replica durumunu gösterir. Desired ile current arasında kısa süreli fark normal olabilir. Fark uzun sürüyorsa Pod creation veya controller problemi araştırılmalıdır. Current replica Ready anlamına gelmez. Kullanıcı kapasitesi için Ready replica daha değerlidir.

Ready Replicas

Ready replicas gerçek trafik almaya hazır Pod sayısını gösterir. HPA desired sayıyı artırsa bile startup süresi nedeniyle Ready daha yavaş yükselir. Bu fark autoscaling latency'nin uygulama kısmını ölçer. Readiness yanlışsa grafik yanıltıcı olabilir. Ready replica ile backend RPS eşleştirilerek yeni Pod'ların gerçekten trafik aldığı doğrulanmalıdır.

Pending Pods

Pending Pods node kapasitesi veya scheduling constraint sorunlarını gösterir. HPA scale-up sırasında Pending sayısı artıyorsa node autoscaling zinciri incelenmelidir. Scheduling event nedeni CPU, memory, affinity veya quota problemi hakkında bilgi verir. Uzun süre Pending kalan Pod production kapasitesine katkı sağlamaz. Alert threshold workload startup hedefiyle uyumlu olmalıdır.

Node Count

Node count node autoscaler'ın kapasite değişimini gösterir. HPA scale-up sonrası Pending Pod oluşup node count artıyorsa altyapı controller'ı devreye girmiştir. Node Ready zamanı Pod Ready zamanından önce gelir. Scale-down sonrası node sayısının gereksiz yüksek kalması PDB veya consolidation sorununa işaret edebilir. Cost analizi node count ile instance type bilgisini birlikte kullanmalıdır.

CPU/Memory

CPU ve memory hem scaling metric hem sistem saturation göstergesi olabilir. Pod bazında dağılım ortalama metriğin gizlediği hotspot'ları gösterir. Yeni replica açıldıktan sonra ortalama kullanımın düşmesi beklenir. Tek Pod sürekli çok yüksek kalıyorsa session affinity veya uzun connection problemi olabilir. Resource trendleri request ve limit değerleriyle birlikte gösterilmelidir.

RPS

RPS toplam kullanıcı talebini ve Pod başına trafik dağılımını gösterir. Replica sayısı iki katına çıktığında Pod başına RPS'nin nasıl değiştiği load balancing kalitesini anlatır. Toplam RPS sabitken birkaç Pod aşırı trafik alıyorsa load imbalance vardır. Route veya session davranışı incelenmelidir. HPA metric'i CPU olsa bile RPS kullanıcı talebinin temel referansıdır.

p95/p99 Latency

p95 ve p99 latency tail kullanıcı deneyimini gösterir. Scaling sırasında kısa latency spike'ları Pod warm-up veya node provisioning gecikmesini görünür kılar. Replica artışı sonrası latency düşmüyorsa gerçek darboğaz başka yerdedir. p99 özellikle nadir ama ciddi gecikmeleri gösterir. SLO hedefleriyle dashboard üzerinde doğrudan karşılaştırılmalıdır.

Error Rate

Error rate autoscaling geçişlerinin kullanıcı hatasına dönüşüp dönüşmediğini gösterir. Scale-up sırasında timeout, scale-down sırasında 5xx veya connection reset görülebilir. Hata türleri status code ve exception bazında ayrılmalıdır. Retry'ler gerçek başarısızlık oranını gizleyebilir. Client-side retry metriği de izlenmelidir.

Cost

Cost metriği autoscaling politikasının ekonomik sonucunu gösterir. Daha hızlı scale-up latency'yi düşürürken fazla warm node maliyeti yaratabilir. Instance type, replica count ve network egress aynı raporda değerlendirilmelidir. Successful request başına maliyet güçlü bir karşılaştırma metriğidir. FinOps analizi performans ve SLO verisinden bağımsız yapılmamalıdır.

Prometheus ve Grafana ile Autoscaling Monitoring

Autoscaling monitoring yalnızca HPA objesini değil bütün kapasite zincirini kapsamalıdır. Prometheus HPA, Pod, node ve uygulama metriklerini bir araya getirebilir, Grafana bu verileri aynı zaman çizgisinde gösterebilir. KEDA trigger durumu, node autoscaler event'leri, scheduler hataları ve load balancer metrikleri ayrı panellerde görülebilir. Unified dashboard incident sırasında “hangi katman geç kaldı?” sorusuna hızlı yanıt sağlar. Dashboard zaman damgalarının aynı timezone ve scrape aralığında tutulması karşılaştırmayı kolaylaştırır.

HPA Metrics

HPA desired replica, current replica, target metric ve condition bilgileri izlenmelidir. Scaling limited veya metric error durumları alarm üretebilir. Target ile current metric arasındaki oran replica kararını açıklar. Behavior değişikliklerinden sonra replica hareket frekansı karşılaştırılmalıdır. HPA event bilgisi dashboard linklerinden hızlı erişilebilir olmalıdır.

KEDA Metrics

KEDA trigger değerleri ve scaler aktivasyon durumu event-driven sistemin neden scale ettiğini gösterir. Queue threshold veya Prometheus trigger değeri ayrı panelde gösterilebilir. Scale-to-zero geçişleri kullanıcı latency'siyle karşılaştırılmalıdır. Trigger error metric source problemi hakkında erken uyarı sağlar. KEDA tarafından oluşturulan HPA da aynı dashboard'da izlenmelidir.

Node Autoscaler Metrics

Node autoscaler scale-up ve scale-down kararları kapasite zincirinin altyapı kısmını gösterir. Unschedulable Pod sayısı, node provisioning süresi ve scale-down blocker nedenleri izlenmelidir. Cloud capacity veya quota error'ları ayrı alarm olmalıdır. Node Ready olma süresi instance type bazında karşılaştırılabilir. Uzayan provisioning süresi SLO riskini önceden gösterebilir.

Pod Scheduling Events

Scheduler event'leri Pending Pod nedenini açıklar. `Insufficient cpu`, affinity mismatch veya untolerated taint gibi reason değerleri kategorize edilebilir. Yük testi sırasında Pending sayısı artarsa hangi reason'ın baskın olduğu hemen görülür. Aynı event'in binlerce kez log üretmesi ayrıca alarm gürültüsü oluşturabilir. Event retention ve aggregation buna göre planlanmalıdır.

Load Balancer Metrics

Load balancer connection, request, backend health ve error metrikleri trafiğin uygulamaya ulaşmadan önceki durumunu gösterir. Backend Pod sayısı artmasına rağmen load balancer aynı hedefleri kullanıyorsa ağ katmanında propagation sorunu olabilir. L7 gateway p95 latency upstream application latency ile karşılaştırılmalıdır. TLS error veya connection reset gibi sinyaller backend 5xx'den ayrılmalıdır. Bu metrikler HPA dashboard'uyla aynı zaman ekseninde izlenmelidir.

Unified Scaling Dashboard

Unified dashboard kullanıcı trafiğinden node kapasitesine kadar bütün scaling zincirini tek görünümde toplar. Üst satırda RPS, latency ve error rate; sonraki satırda HPA desired ve Ready replica; ardından Pending Pod ve node count gösterilebilir. Queue veya custom metric de aynı zaman çizgisinde bulunmalıdır. Incident sırasında ekip farklı sistemler arasında sekme değiştirmek zorunda kalmaz. Bu yaklaşım root cause bulma süresini önemli ölçüde azaltabilir.

Kubernetes Autoscaling Troubleshooting

Autoscaling sorunu araştırırken controller zincirini sırayla kontrol etmek en hızlı yöntemdir. Önce metric gerçekten geliyor mu, sonra HPA desired replica artırıyor mu, Deployment yeni Pod oluşturuyor mu, scheduler Pod'u yerleştirebiliyor mu ve Pod Ready oluyor mu sorularına bakılır. Ardından Service ve gateway yeni endpoint'e trafik gönderiyor mu kontrol edilir. Node autoscaler ek kapasite sağlayamıyorsa cloud quota ve scheduling constraint incelenir. Bu sıra rastgele log okumaktan daha hızlı sonuç verir.

HPA unknown Metric

HPA metric değerini `unknown` gösteriyorsa metric API erişimi kontrol edilmelidir. Resource metric için Metrics Server, custom metric için adapter ve APIService durumu incelenir. Metric adı veya label selector yanlış olabilir. Prometheus'ta sorgu çalışıyor olsa bile adapter mapping hatalıysa HPA veri alamaz. Önce metric API endpoint'ini doğrudan sorgulamak problemi daraltır.

HPA Replica Artırmıyor

HPA replica artırmıyorsa current metric hedefin altında olabilir veya maxReplicas sınırına ulaşılmış olabilir. Resource request eksikliği CPU utilization hesabını etkileyebilir. Metric gecikmeli veya yanlış namespace'ten geliyor olabilir. HPA condition ve event bilgisi controller kararını açıklar. Tahmin yürütmeden önce mevcut target ile current değeri yan yana kontrol etmek gerekir.

HPA Sürekli Scale Ediyor

Sürekli replica değişimi metric dalgalanması veya çok dar target nedeniyle oluşabilir. Stabilization window ve tolerance davranışı incelenmelidir. Request değerleri değişiyorsa HPA utilization oranı da sürekli değişebilir. Session affinity pod bazında dengesizlik yaratıp ortalamayı oynatabilir. Replica change frequency metriği bu problemi görünür hale getirir.

Yeni Pod'lar Pending

Pending Pod sorunu HPA'dan sonra scheduler katmanında oluşur. `kubectl describe pod` scheduling event'leri ilk kontrol noktasıdır. CPU, memory, taint, affinity veya volume zone kısıtı görülebilir. Node autoscaler logları neden yeni node açılmadığını gösterebilir. Cloud quota ve instance availability ayrıca kontrol edilmelidir.

Node Autoscaler Node Eklemiyor

Node autoscaler unschedulable Pod'u destekleyen node group bulamıyor olabilir. Group max size sınırına ulaşılmış veya cloud quota dolmuş olabilir. Pod request mevcut tüm instance type'lardan büyük olabilir. Required affinity veya selector uygun node class bırakmamış olabilir. Autoscaler event ve cloud provisioning logları birlikte incelenmelidir.

Node Scale-Down Yapılmıyor

Düşük kullanılan node hemen silinmiyorsa PDB, local storage veya Pod placement constraint'i engel olabilir. Scale-down cooldown süresi henüz dolmamış olabilir. Başka node'larda yeterli kapasite bulunmaması da eviction'ı önler. Autoscaler'ın unremovable node reason bilgisi değerlidir. Maliyet optimizasyonu için bu nedenler haftalık raporlanabilir.

Yeni Pod Trafik Almıyor

Yeni Pod Ready görünmesine rağmen trafik almıyorsa Service selector ve EndpointSlice kontrol edilmelidir. Pod doğru label taşımıyor olabilir. Gateway veya proxy endpoint update'i gecikmiş olabilir. Uzun yaşayan connection'lar nedeniyle eski Pod'lar trafik taşımaya devam ediyor olabilir. Pod bazında connection ve RPS metriği problemi ayırmaya yardımcı olur.

Load Balancer Bazı Pod'ları Aşırı Yüklüyor

Bazı Pod'ların sürekli daha fazla yük alması session affinity, long-lived connection veya topology routing nedeniyle oluşabilir. Uygulama içindeki connection pool davranışı da belirli backend'lerde yük yoğunlaştırabilir. HPA ortalama metric kullandığı için tek Pod hotspot'u gizlenebilir. Pod bazında p95 latency ve RPS karşılaştırılmalıdır. Gerekirse connection lifetime veya affinity stratejisi değiştirilmelidir.

Load Imbalance Neden Oluşur?

Load imbalance yalnızca load balancer'ın hatalı çalışmasından kaynaklanmaz. Uzun bağlantılar, session affinity, zone-local routing, Pod dağılımı ve readiness davranışı gerçek trafik paylarını değiştirir. Uygulama içindeki connection pooling de backend kullanımını dengesizleştirebilir. HPA ortalama metric kullandığı için tek Pod'un aşırı yüklenmesi genel ortalamada görünmez hale gelebilir. Bu nedenle toplam Service metriğinin yanında Pod ve zone bazlı dağılım mutlaka izlenmelidir.

Long-Lived Connections

Uzun bağlantılar backend seçimini uzun süre sabitleyebilir. Yeni Pod eklendiğinde eski bağlantılar aynı backend'de kalır. Replica sayısı artmasına rağmen yük hemen dengelenmez. WebSocket ve gRPC sistemlerinde bu çok yaygındır. Connection age ve reconnect davranışı production tuning'in parçası olmalıdır.

Session Affinity

Session affinity belirli istemciyi aynı Pod'a bağlayabilir. NAT arkasındaki büyük kullanıcı grupları tek kaynak IP olarak görülebilir. Böyle durumda tek Pod aşırı trafik alabilir. HPA ortalama CPU metriği yeni replica açsa bile sticky kullanıcılar eski Pod'da kalabilir. Harici session store stateless dağılımı kolaylaştırır.

Zone-Local Routing

Same-zone tercihleri network maliyetini azaltırken zone başına kapasite eşit değilse yük dengesizliği oluşturabilir. Bir zone'da iki, diğerinde altı Pod olması local trafik yoğunluğunu değiştirebilir. HPA toplam metriğe baktığında bölgesel hotspot'u fark etmeyebilir. Topology spread yeni replica'ların zone'lara dağılmasına yardımcı olur. Zone bazlı metric dashboard'u gereklidir.

Uneven Pod Distribution

Replica'ların çoğu aynı node veya zone'a yerleşmişse trafik politikaları dengesiz yük oluşturabilir. Scheduler varsayılan davranışı her zaman sizin istediğiniz dağılımı garanti etmez. Topology spread constraints bu dengeyi daha açık ifade eder. Node autoscaler kapasiteyi farklı zone'larda sağlayabilmelidir. Pod dağılımı her rollout sonrası kontrol edilmelidir.

Yanlış Readiness

Readiness yanlış pozitif verirse hazır olmayan Pod trafik alır ve yavaş yanıt üretir. Yanlış negatif verirse sağlıklı Pod trafikten çıkar ve kalan Pod'ların yükü artar. HPA bu yükselen CPU'yu kapasite ihtiyacı olarak görebilir. Asıl problem probe olsa bile replica sayısı gereksiz büyür. Probe success rate ve transition count izlenmelidir.

Uygulama İçindeki Connection Pooling

Uygulama veya gateway backend connection pool'unu uzun süre açık tutabilir. Yeni endpoint'ler eklendiğinde pool yeni bağlantı kurmadığı için trafik eski backend'lerde kalabilir. HTTP/2 multiplexing bu etkiyi büyütebilir. Connection max age veya refresh davranışı kontrollü biçimde ayarlanabilir. Değişiklik handshake maliyetiyle birlikte test edilmelidir.

HPA'nın Ortalama Metrik Kullanması

HPA çoğu per-Pod metric senaryosunda ortalama değere göre replica ihtiyacı hesaplar. Dört Pod'dan biri yüzde yüz CPU, üçü yüzde yirmi CPU kullanıyorsa ortalama kritik hotspot'u yumuşatabilir. Kullanıcılar aşırı yüklü Pod'da hata görmeye devam edebilir. Pod başına dağılım metrikleri bu nedenle SLO dashboard'unda bulunmalıdır. Asıl dengesizlik load balancing katmanında çözülmelidir.

Thundering Herd Problemi

Thundering herd, çok sayıda istemci veya worker'ın aynı anda aynı kaynağa yüklenmesiyle ani kapasite patlaması oluşmasıdır. Trafik spike'ı sırasında HPA çok sayıda replica isteyebilir, fakat bu replica'ların tamamı cold Pod olarak aynı anda startup yükü oluşturur. Node kapasitesi yoksa cold node provisioning de zincire eklenir. Pre-scaling, rate limiting ve queue tabanlı backpressure bu darbeyi yumuşatabilir. Amaç yalnızca daha hızlı scale etmek değil, talebi sistemin kaldırabileceği hızda kabul etmektir.

Trafik Ani Geldiğinde Ne Olur?

Ani trafik geldiğinde mevcut warm Pod'lar ilk yükü taşır. Metric pipeline sinyali gözleyip HPA scale-up başlatana kadar belirli süre geçer. Yeni Pod'lar Ready olana kadar mevcut kapasite yüksek utilization altında kalır. Retry'ler de başlarsa trafik daha hızlı büyüyebilir. Rate limiting ve queue kullanıcı talebini kontrollü biçimde emmeye yardımcı olur.

Cold Pod'lar

Cold Pod application cache ve connection pool hazırlığını henüz tamamlamamış yeni replica'dır. Bir anda çok sayıda cold Pod açılırsa database connection storm oluşabilir. Cache miss oranı downstream servislere ek yük bindirebilir. Readiness erken başarılı olmamalıdır. Pre-warming veya kademeli trafik geçişi startup yükünü azaltabilir.

Cold Node'lar

Cold node cloud'dan yeni oluşturulan ve henüz cluster workload'larını taşımaya hazır olmayan compute kapasitesidir. Bootstrap, CNI kurulumu ve image pull toplam süreyi uzatır. HPA yeni Pod istediğinde node yoksa kullanıcı kapasitesi bu süreç bitene kadar artmaz. Warm node headroom kritik peak sistemlerinde önemlidir. Node ready time metriği düzenli izlenmelidir.

Aynı Anda Çok Sayıda Replica

Çok sayıda replica aynı anda image registry, DNS, database ve config servislerine bağlanabilir. Bu durum startup storm oluşturabilir. HPA scale-up policy artış hızını sınırlayabilir. Ancak çok yavaş artış da trafik spike'ına yetişmez. Doğru hız bağımlılıkların kaldırabileceği startup concurrency ile belirlenmelidir.

Pre-Scaling

Bilinen peak öncesinde replica ve node kapasitesini artırmak thundering herd etkisini azaltır. Pod'lar trafik gelmeden önce cache ve connection pool hazırlığını tamamlayabilir. Kampanya trafiğinde bu yöntem reactive autoscaling'e göre daha kontrollüdür. Gerçek metric HPA yine beklenmeyen artışları karşılar. Scheduled ve reactive scaling birbirini tamamlar.

Rate Limiting

Rate limiting sistemin güvenli işleme kapasitesinin üzerinde trafik kabul etmesini engeller. Kullanıcıya kontrollü 429 dönmek, tüm backend'lerin çökmesinden daha iyi olabilir. Gateway katmanında veya uygulama içinde uygulanabilir. Limit değerleri HPA'nın scale-up kapasitesini de hesaba katmalıdır. Çok düşük limit gereksiz kullanıcı reddi oluşturur.

Queue ve Backpressure

Queue ani trafiği hemen işlemek yerine kontrollü backlog olarak tutabilir. Worker sayısı KEDA ile queue metriğine göre artırılabilir. Backpressure downstream servisin kaldırabileceğinden fazla paralel iş başlatılmasını önler. Queue age SLO'yu izlemek için önemlidir. Bu yaklaşım özellikle asynchronous işlerde thundering herd riskini ciddi biçimde azaltır.

Retry Storm Autoscaling'i Nasıl Bozabilir?

Retry storm ilk request başarısız olduğunda çok sayıda istemcinin kısa aralıklarla tekrar deneme yapmasıyla gerçek trafik hacminin katlanmasıdır. Backend yavaşladıkça timeout artar, retry sayısı yükselir ve CPU daha da artabilir. HPA bu ek trafiği gerçek kullanıcı talebi sanarak daha fazla replica açar. Downstream sistem aynı retry yükü altında daha da yavaşlayabilir. Circuit breaker, exponential backoff ve jitter autoscaling ile birlikte kullanılan temel koruma mekanizmalarıdır.

Timeout

Timeout istemcinin yanıt için ne kadar bekleyeceğini belirler. Çok kısa timeout normal yükte tamamlanabilecek request'i başarısız sayıp retry başlatabilir. Çok uzun timeout connection ve worker kaynaklarını gereksiz tutabilir. Gateway ve application timeout değerleri birbirleriyle uyumlu olmalıdır. Latency dağılımı üzerinden gerçekçi değer belirlenmelidir.

Retry

Retry geçici network hatalarında kullanıcı deneyimini iyileştirebilir. Fakat her hata için anında üç tekrar yapmak trafik yükünü birkaç katına çıkarabilir. Idempotent olmayan işlemlerde veri tutarlılığı riski de vardır. Retry yalnızca uygun hata türleri için sınırlandırılmalıdır. Backoff ve jitter olmadan geniş ölçekli istemci kitlesi aynı anda tekrar deneyebilir.

Trafik Çarpanı

Bir milyon gerçek request'in her biri iki kez retry edilirse backend üç milyon işlem görebilir. Autoscaling sistemi bu yükü gerçek talep olarak ölçebilir. Replica artışı devam ederken database daha fazla connection alır. Sistem kendi retry mekanizmasıyla problemi büyütür. Original request ve retry request metriklerini ayrı izlemek bu durumu erken gösterir.

CPU Artışı

Retry sayısı yükseldikçe uygulama aynı kullanıcı işi için daha fazla CPU harcar. HPA CPU metriği bunu kapasite ihtiyacı olarak yorumlar. Yeni Pod açılması geçici rahatlama sağlasa bile kök sorun devam eder. Downstream timeout sürdükçe replica sayısı max sınırına kadar çıkabilir. Retry rate ile CPU grafiğinin korelasyonu incident analizinde çok değerlidir.

HPA Scale-Up

HPA retry kaynaklı yüksek CPU veya RPS gördüğünde normal algoritmasıyla scale-up yapar. Controller açısından bu trafik gerçek kullanıcı talebinden ayırt edilemeyebilir. MaxReplicas maliyet ve downstream koruması açısından önemlidir. Circuit breaker retry trafiğini sınırlayarak HPA'nın yanlış sinyalle büyümesini engelleyebilir. Scaling metric mümkünse successful work rate ile de karşılaştırılmalıdır.

Circuit Breaker

Circuit breaker sürekli başarısız olan downstream çağrılarını geçici olarak durdurarak kaynak tüketimini sınırlar. Her request'i yavaş dependency'ye göndermek yerine hızlı hata veya fallback uygulanabilir. Böylece worker ve connection pool doygunluğu azalır. HPA gereksiz retry trafiğinden daha az etkilenir. Breaker threshold değerleri gerçek hata toleransına göre test edilmelidir.

Exponential Backoff

Exponential backoff her retry arasındaki bekleme süresini giderek artırır. Jitter eklendiğinde istemcilerin aynı anda tekrar deneme yapması azaltılır. Bu davranış thundering herd ve retry storm riskini ciddi biçimde düşürür. Maksimum retry sayısı yine sınırlandırılmalıdır. Client ve service mesh retry politikaları üst üste binerek toplam deneme sayısını istemeden büyütmemelidir.

GitOps ile Autoscaling Yönetimi

Autoscaling ayarları production davranışını doğrudan etkilediği için kod gibi version control altında yönetilmelidir. HPA manifestleri, KEDA ScaledObjects, NodePool tanımları ve Gateway API Route kaynakları Git repository'de izlenebilir. Pull request review metric target veya max replica değişikliğinin ekip tarafından görülmesini sağlar. Argo CD veya Flux gibi GitOps araçları deklaratif state'i cluster'a uygulayabilir. Değişiklik sonrası load test sonucu ve dashboard linki PR açıklamasına eklenirse kapasite kararları daha izlenebilir hale gelir.

HPA Manifestleri

HPA manifesti min, max, metric target ve behavior ayarlarını içerir. Bu değerlerin elle production cluster'da değiştirilmesi configuration drift oluşturabilir. Git üzerinden değişiklik yapmak review ve rollback kolaylığı sağlar. Metric target değişikliği performans testine bağlanmalıdır. PR içinde eski ve yeni replica davranışının grafikle karşılaştırılması faydalıdır.

KEDA ScaledObjects

ScaledObject trigger threshold, polling, cooldown ve replica sınırlarını tanımlar. Queue sisteminde küçük bir threshold değişikliği büyük cost farkı oluşturabilir. Bu nedenle ScaledObject manifestleri de version control altında tutulmalıdır. Authentication secret değerleri doğrudan repository'ye yazılmamalıdır. Secret yönetimi platformun güvenli mekanizmasıyla çözülmelidir.

NodePool Tanımları

NodePool instance type, zone ve capacity type seçimlerini etkiler. Yanlış değişiklik tüm cluster provisioning davranışını değiştirebilir. GitOps review bu değişiklikleri platform ekibinin kontrolünden geçirir. Cost etkisi özellikle spot ve büyük instance seçeneklerinde değerlendirilebilir. Production'a geçmeden staging workload ile provisioning testi yapılmalıdır.

Gateway API Routes

Gateway API Route değişiklikleri production trafiğini anında farklı backend'e yönlendirebilir. Weighted canary oranının 10'dan 100'e yanlışlıkla çıkması ciddi risk oluşturur. Git review ve policy kontrolü bu hatayı azaltır. Route ile backend Deployment version değişikliği aynı release planında izlenebilir. Rollback için önceki manifest commit'i açık olmalıdır.

Git Versioning

Git versioning autoscaling parametrelerinin geçmişini görünür hale getirir. Hangi gün max replica neden değişti sorusuna commit ve PR üzerinden yanıt bulunabilir. Incident sonrası önceki çalışan config'e dönmek kolaylaşır. Commit mesajlarında metric veya SLO gerekçesi belirtilmelidir. Sadece “HPA update” gibi belirsiz mesajlar uzun vadede bilgi kaybı oluşturur.

Pull Request Review

Pull request review autoscaling değişikliğinin en az ikinci kişi tarafından değerlendirilmesini sağlar. Reviewer target metric, max replica, PDB ve node kapasitesi etkisini kontrol edebilir. Değişiklik büyükse load test sonucu istenebilir. Cost etkisi tahmini de PR içine eklenebilir. Bu süreç platform bilgisini ekip içinde paylaşmanın etkili yollarından biridir.

Argo CD / Flux

Argo CD ve Flux deklaratif Git state'ini Kubernetes cluster'larına uygulamak için yaygın GitOps projeleridir. Autoscaling kaynakları diğer workload manifestleriyle aynı deployment akışına alınabilir. Drift detection production'daki manuel değişiklikleri görünür hale getirir. Sync davranışı HPA'nın runtime `replicas` değişiklikleriyle çakışmayacak şekilde resource ownership açısından doğru tasarlanmalıdır. Deployment replica alanını sürekli Git değerine zorlayan yanlış yapı HPA ile conflict oluşturabilir.

Kubernetes İçin En İyi Programlama Dili Hangisidir?

Kubernetes öğrenmek için tek bir “en iyi” programlama dili yoktur, çünkü platformun temel çalışma modeli declarative API ve container sistemleri üzerine kuruludur. Go Kubernetes ekosistemindeki controller ve operator geliştirmede güçlü konuma sahiptir. Python automation, API entegrasyonu ve platform script'leri için oldukça pratiktir. YAML ve Helm günlük workload tanımlamalarında programlama dili kadar önemlidir. Asıl farkı Linux, networking, container, observability ve distributed system temelleri yaratır.

Go Neden Kubernetes Ekosisteminde Öne Çıkıyor?

Kubernetes'in kendisi büyük ölçüde Go ile geliştirildiği için ekosistemde birçok controller ve operator Go kullanır. Client kütüphaneleri ve controller framework'leri güçlüdür. Cloud-native altyapı ürünü geliştirmek isteyen yazılımcılar için Go iyi bir yatırım olabilir. Ancak Kubernetes kullanıcısı olmak için Go bilmek zorunlu değildir. Önce API kaynaklarını ve control loop mantığını anlamak daha değerlidir.

Python ile Kubernetes Automation

Python hızlı automation script'leri ve Kubernetes API entegrasyonları için rahat bir seçenektir. Kaynak raporlama, deployment kontrolü veya maliyet analizi araçları yazılabilir. Veri analizi ekosistemi autoscaling metriklerini incelemek için de faydalıdır. Uzun yaşayan production controller geliştirirken retry ve concurrency davranışı dikkatle tasarlanmalıdır. Dil seçiminden bağımsız olarak idempotent reconciliation mantığını öğrenmek önemlidir.

YAML ve Declarative Configuration

Kubernetes günlük kullanımında YAML kaynak tanımları önemli yer tutar. Deployment, Service, HPA ve Gateway API Route gibi nesneler declarative olarak ifade edilir. YAML programlama dili değildir, fakat Kubernetes API şemasını doğru kullanma becerisi gerektirir. Büyük manifestlerde tekrar ve ortam farkları yönetilmelidir. GitOps yaklaşımı YAML değişikliklerini review edilebilir hale getirir.

Helm Template'leri

Helm benzer Kubernetes manifestlerini parametrelerle paketlemeye yardımcı olur. HPA min ve max değerleri farklı ortamlar için values dosyalarından yönetilebilir. Çok fazla template logic chart'ı okunması zor hale getirebilir. Kritik autoscaling değerlerinin varsayılanları açık tutulmalıdır. Chart değişiklikleri rendered manifest üzerinden review edilmelidir.

Programlama Dilinden Daha Önemli Olan Cloud-Native Temelleri

Kubernetes konusunda iyi olmak yalnızca Go veya Python bilmekle gerçekleşmez. Linux process modeli, DNS, TCP/IP, container isolation ve resource management daha temel konulardır. Scheduler ve Service davranışını anlamadan autoscaling sorunları doğru teşhis edilemez. Observability ve distributed system failure modelleri production deneyimini belirler. Programlama dili bu temeller üzerinde araç üretmek için kullanılan bir katmandır.

Open Source ve İşbirliği ile Kubernetes

Kubernetes ve çevresindeki pek çok cloud-native proje açık kaynak geliştirme modeliyle ilerler. KEDA, Karpenter, Gateway API, Cilium ve Prometheus gibi projeler farklı autoscaling, networking ve observability ihtiyaçlarına odaklanır. Bu projelerin issue ve documentation çalışmalarına katkıda bulunmak yalnızca kod yazmaktan ibaret değildir. Test, örnek manifest, Türkçe teknik içerik ve bug reproduction da değerli katkılardır. Topluluk içinde küçük bir laboratuvar projesiyle başlayan öğrenme süreci gerçek open source katkısına dönüşebilir.

Kubernetes Açık Kaynak Projesi

Kubernetes büyük bir contributor topluluğu tarafından geliştirilen açık kaynak projedir. Networking, scheduling, storage ve autoscaling gibi alanlar farklı çalışma grupları tarafından ele alınır. Yeni başlayanlar dokümantasyon ve good first issue türündeki görevlerle katkıya başlayabilir. Kod tabanına girmeden önce ilgili SIG toplantı notlarını okumak faydalıdır. Açık kaynak katkısı teknik iletişim becerisini de geliştirir.

CNCF Ekosistemi

CNCF ekosistemi Kubernetes çevresindeki gözlemlenebilirlik, networking, runtime ve delivery projelerini bir araya getirir. Bir problemi çözmek için önce Kubernetes core içinde özellik aramak yerine ekosistem projeleri değerlendirilebilir. Her proje farklı maturity ve support modeline sahiptir. Production seçimi yapılırken yalnızca popülerlik değil release düzeni ve topluluk sağlığı incelenmelidir. Laboratuvar projeleri bu değerlendirmeyi öğrenmenin iyi yoludur.

KEDA

KEDA event-driven autoscaling alanında açık kaynak katkı fırsatları sunar. Yeni scaler, documentation veya example çalışmaları yapılabilir. Bir queue teknolojisini kullanan geliştirici kendi gerçek kullanım deneyimini issue olarak paylaşabilir. Test senaryoları scaling edge case'lerini ortaya çıkarabilir. Topluluk workshop'unda küçük bir ScaledObject örneği geliştirmek iyi başlangıçtır.

Karpenter

Karpenter node provisioning ve kapasite optimizasyonu konusunda öğrenmek isteyenler için zengin bir açık kaynak alanıdır. NodePool ve scheduling kararlarını laboratuvar cluster'ında gözlemlemek scheduler bilgisini güçlendirir. Cloud quota ve spot interruption senaryoları test edilebilir. Documentation contribution da değerli bir başlangıçtır. Production denemeleri her zaman kontrollü hesap ve bütçe sınırlarıyla yapılmalıdır.

Gateway API

Gateway API Kubernetes networking modelinin gelişen önemli parçalarından biridir. HTTPRoute, GRPCRoute ve traffic splitting örnekleri öğrenme projeleri için uygundur. Farklı implementation'ların conformance sonuçlarını karşılaştırmak standardizasyon fikrini anlamayı kolaylaştırır. Documentation ve test katkıları mümkündür. Yeni protokol özellikleri üzerinde çalışmadan önce API design ve release channel kavramlarını öğrenmek faydalıdır.

Cilium

Cilium eBPF tabanlı networking ve observability konularını pratikte öğrenmek için güçlü bir açık kaynak projesidir. Service load balancing, network policy ve flow visibility laboratuvar ortamında incelenebilir. Linux networking bilgisi bu çalışmadan büyük fayda görür. kube-proxy replacement gibi özellikler test cluster'ında denenmelidir. Production geçişi yalnızca temel demo sonucuna dayanarak yapılmamalıdır.

Prometheus

Prometheus Kubernetes autoscaling ve uygulama gözlemlenebilirliği için temel projelerden biridir. Kendi uygulamanıza metric ekleyip PromQL sorgusu yazmak öğretici bir başlangıçtır. Daha sonra Prometheus Adapter veya KEDA trigger ile bu metriği autoscaling'e bağlayabilirsiniz. Böyle bir proje monitoring ile control loop arasındaki ilişkiyi net gösterir. Cardinality ve query performansı da gerçek sistem düşüncesi kazandırır.

GitHub Üzerinden Katkı

GitHub üzerinden katkı yalnızca büyük feature geliştirmek anlamına gelmez. Dokümantasyondaki yanlış örneği düzeltmek, reproducible bug hazırlamak veya test eklemek de değerlidir. Contribution guide her proje için önce okunmalıdır. Küçük ve net pull request review sürecini öğrenmeyi kolaylaştırır. Yerel topluluk içinde birlikte issue seçip çözmek motivasyonu artırabilir.

Kubernetes Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Kubernetes alanında ilerlemek isteyen geliştiricinin önce temel sistem bilgisini güçlendirmesi gerekir. Linux, container, networking ve DNS konuları Kubernetes'in davranışını anlamayı ciddi biçimde kolaylaştırır. Daha sonra workload, Service, Ingress veya Gateway API, observability ve autoscaling konuları uygulamalı projelerle öğrenilebilir. Cloud platformu ve GitOps bilgisi production iş akışını tamamlar. Her aşamada küçük ama gerçek bir proje üretmek yalnızca dokümantasyon okumaktan daha kalıcı öğrenme sağlar.

Linux

Kubernetes node'larının büyük bölümü Linux üzerinde çalıştığı için process, file system ve network temellerini bilmek çok değerlidir. `top`, `ss`, `ip`, `dig` ve log araçları troubleshooting sırasında sık kullanılır. cgroup resource yönetimini anlamak CPU ve memory limit davranışını açıklar. Namespace kavramı container isolation temelini gösterir. Kubernetes öğrenmeden önce Linux'ta rahat olmak süreci hızlandırır.

Docker ve Container Temelleri

Container image nasıl oluşturulur, layer yapısı nasıl çalışır ve process lifecycle nasıl yönetilir bilinmelidir. Kubernetes image'ı çalıştırır, fakat kötü hazırlanmış container'ı otomatik düzeltmez. SIGTERM handling ve health endpoint tasarımı container seviyesinde başlar. Image boyutu Pod startup süresini etkiler. Autoscaling performansı için küçük ve hızlı başlayan image önemli avantaj sağlar.

Networking

IP, port, TCP, UDP, DNS, NAT ve TLS kavramları Kubernetes networking'in temelidir. Service ve load balancer davranışını anlamak için paket akışını zihinde takip edebilmek gerekir. `externalTrafficPolicy` veya same-zone routing gibi özellikler bu temeller üzerinde anlam kazanır. Network troubleshooting yalnızca YAML kontrol etmekle çözülmez. Basit packet flow diyagramları çizmek öğrenmeyi kolaylaştırır.

Kubernetes Workloads

Pod, Deployment, StatefulSet, DaemonSet ve Job kaynaklarının farkları bilinmelidir. HPA çoğu stateless servis için Deployment ölçeklerken batch işlerde Job yaklaşımı daha uygun olabilir. Workload controller replica ve rollout davranışını yönetir. Readiness ve graceful shutdown bu kaynaklarla birlikte öğrenilmelidir. Autoscaling konusu workload yaşam döngüsü anlaşıldıktan sonra çok daha kolay hale gelir.

Service ve DNS

Service dinamik Pod kümesini sabit network kimliği arkasında toplar. DNS uygulamaların Service isimleriyle birbirini bulmasını sağlar. ClusterIP, NodePort ve LoadBalancer farkları uygulamalı olarak denenmelidir. EndpointSlice çıktısına bakmak Service'in gerçek backend'lerini anlamayı sağlar. Bu bilgi load balancing troubleshooting için temeldir.

Ingress ve Gateway API

HTTP routing öğrenirken önce host ve path yönlendirmesi kurulabilir. Daha sonra TLS termination ve canary traffic splitting denenebilir. Ingress ile Gateway API kaynak modeli karşılaştırıldığında platform role separation daha anlaşılır hale gelir. HTTPRoute backend weights küçük demo için iyi bir konudur. Her deneyde gerçek request akışı curl veya load test aracıyla doğrulanmalıdır.

Observability

Metrics, logs ve traces production Kubernetes öğreniminin ayrılmaz parçalarıdır. HPA neden scale etti sorusunu metric olmadan cevaplamak mümkün değildir. Prometheus ve Grafana ile basit dashboard oluşturmak iyi başlangıçtır. Daha sonra custom metric ile HPA kurulabilir. Her laboratuvar projesine en az bir dashboard eklemek iyi bir öğrenme alışkanlığıdır.

Autoscaling

Autoscaling öğrenirken önce CPU HPA kurulup kontrollü load test yapılabilir. Sonra RPS custom metric ve KEDA queue scaling denenebilir. Üçüncü aşamada node autoscaler eklenerek Pending Pod zinciri gözlenebilir. Her deneyde desired, Ready ve node count grafikleri kaydedilmelidir. Böylece kontrol döngülerinin sırası gerçek verilerle anlaşılır.

Cloud Platformları

Managed Kubernetes hizmetleri load balancer ve node autoscaling entegrasyonlarını öğrenmek için uygundur. Ancak cloud maliyet limitleri laboratuvar öncesinde belirlenmelidir. VPC, subnet, security group ve IAM kavramları Kubernetes dışında da öğrenilmelidir. Node provisioning failure çoğu zaman cloud quota veya network ayarından kaynaklanabilir. Platform bilgisi cluster troubleshooting'i ciddi biçimde hızlandırır.

GitOps

GitOps Kubernetes manifestlerini review edilebilir ve geri alınabilir deployment sürecine bağlar. HPA veya Gateway Route değişikliği doğrudan production shell komutuyla yapılmak yerine Git üzerinden ilerler. Argo CD veya Flux laboratuvarı bu workflow'u öğretir. Drift detection manuel değişiklikleri görünür kılar. Küçük ekiplerde bile bu disiplin production güvenilirliğini artırır.

Diyarbakır Yazılım Topluluğu İçin Kubernetes Proje Fikirleri

Kubernetes öğrenmenin en etkili yollarından biri aynı sistemi birkaç farklı arıza ve trafik senaryosuyla çalıştırmaktır. Diyarbakır Yazılım Topluluğu içinde HPA, Prometheus, KEDA, Gateway API ve node autoscaling konularını ayrı mini laboratuvarlara bölmek mümkün. Katılımcılar yalnızca manifest yazmak yerine aynı dashboard üzerinden latency ve replica davranışını yorumlayabilir. Bu yaklaşım networking, backend ve DevOps ilgisi olan kişileri aynı proje etrafında buluşturur. Topluluğun mevcut çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir.

Kubernetes Autoscaling Lab

Basit bir HTTP API Deployment ile başlayıp CPU HPA kurulabilir. k6 veya benzeri araçla RPS kademeli artırılır. Katılımcılar desired ve Ready replica farkını gözlemler. Daha sonra node kapasitesi kasıtlı azaltılarak Pending Pod senaryosu oluşturulur. Tek laboratuvar içinde HPA, scheduler ve node autoscaling zinciri anlaşılır hale gelir.

HPA + Prometheus Workshop

Workshop'ta uygulama özel RPS metriği expose edebilir. Prometheus bu metriği toplar ve adapter üzerinden HPA'ya sunar. CPU HPA ile RPS HPA sonuçları farklı trafik profillerinde karşılaştırılır. Katılımcılar hangi metriğin daha erken scale ettiğini grafik üzerinden görür. Bu çalışma metric seçiminin teoriden çok ölçüm işi olduğunu öğretir.

KEDA Event-Driven Scaling Projesi

Küçük bir queue ve worker sistemi kurularak KEDA ScaledObject kullanılabilir. Queue boşken replica sıfıra iner, mesaj geldiğinde worker başlar. Cold start süresi ölçülür. Ardından minimum replica bir yapılıp kullanıcı gecikmesi ve maliyet farkı karşılaştırılır. Bu proje scale-to-zero kararının gerçek trade-off'unu görünür hale getirir.

Gateway API Traffic Splitting Demo

Uygulamanın v1 ve v2 sürümleri iki Service olarak yayınlanabilir. HTTPRoute backend weight önce 90/10, sonra 50/50 olacak şekilde değiştirilir. Her backend'in request sayısı Prometheus üzerinden izlenir. İki sürüme ayrı HPA verilerek trafik ağırlığı ile replica ihtiyacı karşılaştırılır. Canary deployment kavramı bu deneyle çok daha kolay anlaşılır.

Karpenter/Cluster Autoscaler Laboratuvarı

Katılımcılar küçük node kapasitesiyle başlayan cluster'da bilinçli Pending Pod oluşturabilir. Cluster Autoscaler veya uygun ortamda Karpenter yeni node sağlamaya çalışır. Node Ready süresi ve Pod Ready süresi ayrı ölçülür. Daha sonra resource request değeri değiştirilerek seçilen node kapasitesi karşılaştırılır. Bu çalışma scheduler ile node provisioning ilişkisini net biçimde gösterir.

Kubernetes Open Source Contribution Day

Bir günlük etkinlikte katılımcılar Kubernetes ekosistemindeki açık issue veya dokümantasyon görevlerini inceleyebilir. Gruplar KEDA, Gateway API veya Prometheus gibi projelerde contribution guide okuyabilir. İlk hedef kod değil, düzgün issue reproduction veya documentation düzeltmesi olabilir. Pull request review süreci birlikte takip edilir. Bu deneyim açık kaynak katkısının erişilebilir olduğunu gösterir.

Yerel Uygulamalar İçin Cloud-Native Deployment Projesi

Yerel ihtiyaçlara yönelik basit bir uygulama container haline getirilip Kubernetes'e deploy edilebilir. Service, Gateway, TLS, HPA, monitoring ve GitOps adımları aynı proje içinde uygulanır. Daha sonra load test ile scaling davranışı ölçülür. Proje yalnızca demo değil, production checklist üzerinden değerlendirilen bir çalışma haline gelir. Diyarbakır Yazılım Topluluğu hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresi ziyaret edilebilir.

Uçtan Uca Production Kubernetes Scaling Mimarisi Nasıl Kurulur?

Production-ready scaling mimarisi tek bir HPA manifestiyle başlamaz, trafik profilinin ölçülmesiyle başlar. SLO, resource request, Service ve Gateway katmanı oluşturulduktan sonra probe, topology spread ve doğru scaling metriği belirlenir. Daha sonra node autoscaling, PDB, load test, failure test ve monitoring eklenir. Kubernetes Üzerinde Yük Dengeleme ve Otomatik Ölçekleme bu adımlar birlikte ele alındığında güvenilir hale gelir. Son aşamada production verileri üzerinden scaling parametreleri düzenli olarak yeniden değerlendirilmelidir.

1. Trafik Profilini Ölçün

İlk adım uygulamanın ne kadar trafik aldığını ve trafiğin zaman içinde nasıl değiştiğini ölçmektir. Ortalama RPS tek başına yeterli değildir. Peak RPS, request dağılımı, burst süresi ve connection davranışı kaydedilmelidir. WebSocket veya gRPC bağlantıları ayrıca incelenmelidir. Scaling metriği bu gerçek trafik profilinden türetilmelidir.

2. SLO'ları Belirleyin

p95 latency, availability ve error rate hedefleri yazılı hale getirilmelidir. “Sistem hızlı olsun” ölçülebilir bir kapasite hedefi değildir. Örneğin p95 300 ms altında kalmalı gibi açık bir hedef load test değerlendirmesini kolaylaştırır. Queue workload'larında queue age SLO'su belirlenebilir. Autoscaling başarısı bu hedefler üzerinden ölçülmelidir.

3. Resource Requests Belirleyin

Load test sırasında Pod başına CPU ve memory tüketimi ölçülür. Request değerleri ortalama ve peak davranışına göre belirlenir. Çok yüksek değer node packing'i bozar, çok düşük değer HPA'yı yanıltabilir. VPA recommendation ek veri sağlayabilir. Her büyük uygulama sürümünden sonra right-sizing yeniden gözden geçirilmelidir.

4. Service Oluşturun

Deployment arkasında sabit ağ erişimi için uygun Service tanımlanır. Çoğu backend uygulaması için ClusterIP yeterlidir. Selector değerleri Pod label'larıyla doğrulanır. EndpointSlice içinde Ready backend'ler gözlenir. Service erişimi gateway eklenmeden önce cluster içinden test edilmelidir.

5. Gateway/Ingress Yapısını Kurun

HTTP veya HTTPS giriş katmanı için Gateway API veya mevcut platform standardı olan Ingress yapılandırılır. Host, path ve TLS kuralları test edilir. Backend Service doğrudan route hedefi olur. Gateway'in kendi replica kapasitesi ve autoscaling ihtiyacı gözden geçirilir. Tek giriş katmanının uygulama backend'lerinden önce darboğaz olmadığı load test ile doğrulanır.

6. Readiness ve Startup Probe Ekleyin

Startup probe yavaş başlayan uygulamanın başlangıç sürecini doğru yönetir. Readiness probe gerçek trafik hazırlığını bildirir. Yeni Pod ancak gerekli bağlantılar hazır olduğunda Ready olmalıdır. Probe hatası production endpoint kapasitesini doğrudan etkiler. Load test sırasında probe transition sayısı izlenmelidir.

7. Pod Topology Spread Ayarlayın

Replica'ların node ve availability zone'lara dengeli dağılması için topology spread constraints tanımlanabilir. `maxSkew` availability ihtiyacına göre seçilir. Çok katı kurallar kapasite sıkışıklığında Pending Pod oluşturabilir. HPA scale-up sırasında dağılım gözlenir. Zone failure testi gerçek davranışı doğrular.

8. HPA veya KEDA Metric'ini Seçin

Compute-bound servis için CPU, web API için RPS veya queue consumer için lag uygun olabilir. Metric talep artışını mümkün olduğunca erken göstermelidir. KEDA dış event kaynaklarını bağlamak için değerlendirilebilir. HPA multiple metrics ile birden fazla risk sinyali kullanılabilir. Seçim load test korelasyonuna dayanmalıdır.

9. Scale-Up/Scale-Down Behavior Ayarlayın

Scale-up trafik artışına yetişecek kadar hızlı olmalıdır. Scale-down kısa süreli düşüşlerde kapasiteyi hemen kaldırmamalıdır. Stabilization window ve policy değerleri trafik periyoduna göre ayarlanır. Replica churn metriği test edilir. Amaç hem SLO hem cost açısından kararlı kontrol döngüsü oluşturmaktır.

10. Node Autoscaling Kurun

HPA'nın yeni Pod'ları mevcut node'lara sığmadığında node autoscaler devreye girmelidir. Cluster Autoscaler veya uygun platformda Karpenter değerlendirilebilir. Node group veya NodePool workload gereksinimlerini karşılamalıdır. Cloud quota ve zone capacity kontrol edilir. Node Ready süresi load testte ölçülür.

11. PDB Tanımlayın

Node drain ve gönüllü disruption sırasında minimum uygulama kapasitesini korumak için PDB tanımlanabilir. `minAvailable` veya `maxUnavailable` HPA minimum replica ile uyumlu olmalıdır. Çok katı PDB node scale-down'ı engelleyebilir. Rolling update testi yapılmalıdır. Availability hedefi ile operasyon hareket alanı dengelenmelidir.

12. Load Test Yapın

Artan RPS, spike ve sustained load senaryoları uygulanmalıdır. Desired, Ready ve Pending replica aynı anda izlenir. Node count ve p95 latency grafiklere eklenir. Her testte scale-up süresi ölçülür. Sonuçlar GitOps değişikliklerine kanıt olarak eklenebilir.

13. Failure Testi Yapın

Pod silme, node drain ve mümkünse zone kaybı senaryoları test edilir. Sistem yeni kapasite oluştururken SLO'nun korunup korunmadığı ölçülür. Retry ve connection draining davranışı gözlenir. Stateful bağımlılık failure senaryoları ayrıca ele alınır. Bu testler gerçek incident öncesinde mimari açığı gösterir.

14. Monitoring ve Alerting Kurun

RPS, latency, error rate, HPA, Pending Pods ve node count için dashboard oluşturulur. Metric source kesintisi için ayrı alarm tanımlanır. Max replica sınırına ulaşmak önemli bir capacity alert'idir. Node quota error kritik alarm olmalıdır. Alert'ler doğrudan kullanıcı etkisiyle ilişkilendirilmelidir.

15. Maliyetleri Ölçün

Replica ve node sayısının trafikle nasıl değiştiği maliyet raporunda görünmelidir. Resource request verimliliği incelenir. Cross-zone traffic ve spot kullanım oranı ayrıca ölçülür. Successful request başına cost iyi bir üst seviye KPI'dır. SLO iyileşmesi ile maliyet artışı birlikte değerlendirilir.

16. Production'a Alın

Production rollout kademeli ve gözlenebilir yapılmalıdır. Gateway weighted routing varsa önce küçük trafik yüzdesi kullanılabilir. HPA ve node autoscaler davranışı canlı metric'lerle izlenir. Rollback planı release öncesinde hazır olmalıdır. İlk peak trafik penceresinde ekip dashboard ve alert'leri yakın takip etmelidir.

17. Scaling Parametrelerini Sürekli İyileştirin

Trafik modeli ve uygulama performansı zaman içinde değişir. Bir yıl önce doğru olan CPU request veya RPS target bugün gereksiz maliyet yaratabilir. Yeni release startup süresini değiştirebilir. Autoscaling parametreleri düzenli capacity review toplantısında gözden geçirilmelidir. Production telemetry her iyileştirmenin ana veri kaynağı olmalıdır.

Kubernetes Yük Dengeleme ve Autoscaling'de En Sık Yapılan Hatalar

Kubernetes scaling sorunlarının çoğu tek bir araç hatasından değil, bileşenlerin birbirinden kopuk tasarlanmasından kaynaklanır. Yalnızca HPA kurmak node, traffic ve readiness sorunlarını çözmez. Resource request ve metric seçimi yanlışsa controller matematiksel olarak doğru ama operasyonel olarak yanlış karar verir. Session affinity, topology ve PDB gibi ayrıntılar production yükünde beklenmedik sonuçlar doğurabilir. En etkili önlem gerçekçi load test ve failure testlerini release sürecinin parçası haline getirmektir.

Yalnızca HPA Kurup Ölçeklemenin Tamamlandığını Sanmak

HPA yalnızca workload replica sayısını değiştirir. Node kapasitesi yoksa yeni Pod'lar Pending kalır. Readiness yanlışsa Pod trafiğe katılmaz. Gateway veya long-lived connection yeni endpoint'i kullanmıyorsa gerçek yük azalmaz. Bu nedenle scaling zinciri uçtan uca izlenmelidir.

Resource Requests Tanımlamamak

Resource request scheduler ve HPA utilization hesaplarında önemli rol oynar. Request olmadan CPU utilization tabanlı HPA beklenen biçimde çalışmayabilir. Scheduler da gerçek kapasite ihtiyacını doğru planlayamaz. Node autoscaler yanlış veya eksik kapasite sinyali alabilir. Her production container için ölçüme dayalı request değeri belirlenmelidir.

Her Uygulamayı CPU'ya Göre Scale Etmek

CPU kolay metric olduğu için her workload'a uygulanması yaygın hatadır. Queue consumer veya I/O ağırlıklı API CPU yükselmeden doygunluğa ulaşabilir. RPS, concurrency veya lag daha erken sinyal olabilir. Metric seçimi uygulama tipine göre yapılmalıdır. Load test metric ile latency arasındaki ilişkiyi göstermelidir.

Readiness Probe Kullanmamak

Readiness olmadan yeni Pod process başlar başlamaz trafik alabilir. Cache veya connection pool henüz hazır değilse kullanıcı hatası oluşur. Scale-up sırasında çok sayıda cold Pod aynı anda sorun yaşayabilir. Termination sırasında trafik kesme davranışı da daha zayıf olur. Production Service arkasındaki uygulamalar gerçek readiness sinyali sunmalıdır.

Node Autoscaling Kullanmamak

HPA replica artırırken node kapasitesi sabitse belli noktada yeni Pod'lar yer bulamaz. Peak trafik sırasında Pending sayısı yükselir. Manuel node eklemek reactive scaling avantajını ortadan kaldırır. En azından capacity alert ve planlı headroom bulunmalıdır. Değişken trafik sistemlerinde node autoscaling güçlü bir tamamlayıcıdır.

Çok Agresif Scale-Down

Scale-down'ı çok hızlı yapmak kısa trafik düşüşlerinde Pod'ları gereksiz kapatır. Trafik geri geldiğinde cold start gerekir. Node autoscaler da aynı anda node kaldırıyorsa gecikme daha büyür. Stabilization ve cooldown değerleri trafik desenine göre ayarlanmalıdır. Scale-down latency ve cost birlikte ölçülmelidir.

HPA ve VPA'yı Aynı CPU Metric'inde Çalıştırmak

VPA CPU request'i değiştirirken HPA utilization hesaplamasının paydası değişir. Bu iki controller'ın birbirine tepki vermesine neden olabilir. Replica ve request değerleri kararsız hale gelebilir. VPA recommendation veya custom metric HPA daha güvenli kombinasyonlar sunar. Production öncesinde kontrol döngüsü etkisi açıkça test edilmelidir.

Session Affinity'yi Kontrol Etmemek

Session affinity bazı kullanıcıların aynı Pod'a bağlanmasına neden olur. HPA yeni Pod açsa bile mevcut sticky trafik eski Pod'da kalabilir. Bir Pod aşırı yüklenirken diğerleri boş görünebilir. Ortalama metric bu durumu gizleyebilir. Pod bazında RPS ve active session dağılımı izlenmelidir.

Zone Dağılımını Görmezden Gelmek

Replica sayısı yüksek olsa bile tüm Pod'lar aynı zone'daysa zone failure büyük kesinti oluşturabilir. Same-zone routing kullanıldığında dağılım trafik dengesini de etkiler. Topology spread constraints bu riski azaltır. Node autoscaler farklı zone'larda kapasite sağlayabilmelidir. Zone failure testi production readiness kontrolüne eklenmelidir.

PDB Tanımlamamak

PDB olmadan node drain sırasında çok fazla replica aynı anda evict edilebilir. Uygulama minimum availability hedefi zarar görebilir. Ancak PDB eklemek tek başına yeterli değildir. Çok katı PDB de node scale-down'ı tamamen durdurabilir. Değerler gerçek replica sayısı ve disruption ihtiyacına göre seçilmelidir.

Cold Start'ı Hesaba Katmamak

HPA desired replica artırdığı an kapasite gelmez. Scheduler, image pull, startup ve readiness süreleri vardır. Node yoksa provisioning de eklenir. Uzun cold start yüksek trafik spike'ında kullanıcı hatası oluşturur. Minimum warm capacity ve pre-scaling bu gecikmeyi karşılayabilir.

Production Öncesi Load Test Yapmamak

Autoscaling manifestinin syntax olarak geçerli olması davranışın doğru olduğunu göstermez. Metric threshold, startup süresi ve node kapasitesi ancak yük altında birlikte görülür. Spike testi en zayıf noktayı hızla ortaya çıkarır. Scale-down testi graceful shutdown sorunlarını gösterir. Production öncesi test incident riskini ciddi biçimde azaltır.

Sadece CPU/Memory İzlemek

CPU ve memory sistem kaynağını gösterir, kullanıcı deneyimini doğrudan göstermez. p95 latency, error rate ve RPS ayrıca izlenmelidir. Queue sisteminde age ve backlog daha önemlidir. HPA doğru scale etse bile downstream database kullanıcı latency'sini bozabilir. Unified dashboard bu farklı sinyalleri bir araya getirir.

Trafik Dağılımı ile Replica Dağılımını Birlikte İncelememek

Beş replica bulunması trafiğin beş Pod'a eşit dağıldığı anlamına gelmez. Long-lived connection, affinity veya topology routing bazı Pod'ları daha fazla yükleyebilir. HPA ortalama metric kullanınca hotspot görünmez hale gelir. Pod başına RPS ve zone dağılımı aynı grafikte incelenmelidir. Load balancing ve autoscaling bu nedenle ayrı ekiplerin izole sorumluluğu olmamalıdır.

Production-Ready Kubernetes Scaling Checklist

Production-ready bir sistem için networking, application lifecycle, Pod autoscaling, node autoscaling, availability, observability ve cost başlıklarının birlikte doğrulanması gerekir. Checklist'in amacı yalnızca kaynakların varlığını kontrol etmek değil davranışın test edildiğini kanıtlamaktır. Service tanımlı olması tek başına yeterli değildir, yeni Pod'un gerçekten trafik alması görülmelidir. HPA mevcut olması yeterli değildir, spike altında SLO'yu koruduğu ölçülmelidir. Her madde düzenli production review sürecinde yeniden değerlendirilebilir.

Networking

Networking kontrolünde Service, Gateway veya Ingress ve backend endpoint akışı uçtan uca doğrulanmalıdır. DNS çözümü, TLS ve route kuralları gerçek client isteğiyle test edilir. Yeni replica Ready olduğunda endpoint listesine katıldığı gözlenir. Long-lived connection varsa yeni Pod'un trafik alma süresi ölçülür. Network failure ve route rollback senaryoları da dokumente edilmelidir.

Service doğru mu?

Service selector Pod label'larıyla eşleşmelidir. Port ve targetPort doğru container portuna yönlenmelidir. ClusterIP erişimi uygulama içinden test edilmelidir. EndpointSlice içinde beklenen Ready endpoint'ler görünmelidir. Autoscaling sonrası backend sayısının arttığı doğrulanmalıdır.

Gateway/Ingress doğru mu?

Gateway veya Ingress host ve path kuralları beklenen Service'e gitmelidir. TLS sertifikası ve listener ayarları test edilmelidir. Controller'ın route kaynağını kabul ettiği status alanından kontrol edilmelidir. Weighted route varsa gerçek trafik oranı metric üzerinden doğrulanmalıdır. Rollback sırasında önceki backend'e dönüş testi yapılmalıdır.

Trafik yeni Pod'lara ulaşıyor mu?

Ready olan yeni Pod'un RPS metriği kısa süre içinde yükselmelidir. Uzun bağlantılı workload'da bu geçiş daha yavaş olabilir. Service EndpointSlice yeni Pod'u içermelidir. Gateway upstream pool refresh davranışı gözlenmelidir. Yeni Pod sürekli sıfır trafik alıyorsa load balancing katmanı ayrıca incelenmelidir.

Application

Application katmanında stateless tasarım, graceful shutdown ve health probe davranışı autoscaling ile doğrudan ilişkilidir. Pod açıldığında ve kapanırken kullanıcı isteğinin zarar görmemesi gerekir. Session state mümkünse harici store'a taşınmalıdır. SIGTERM handling gerçek Pod deletion testiyle doğrulanmalıdır. Startup ve readiness probe süreleri production telemetrisiyle uyumlu olmalıdır.

Stateless tasarım

Her replica aynı request'i işleyebiliyorsa yatay scaling daha güvenilir olur. Pod local session verisi kullanıcıyı belirli backend'e bağlamamalıdır. Gerekli state paylaşılan store'da tutulabilir. Pod silinmesi kullanıcı oturumunu doğrudan kaybettirmemelidir. Bu tasarım session affinity ihtiyacını da azaltır.

Graceful shutdown

Uygulama SIGTERM aldığında yeni request kabulünü kontrollü biçimde durdurmalıdır. Mevcut request'lerin tamamlanması için yeterli grace period verilmelidir. Endpoint removal propagation süresi test edilmelidir. Uzun connection'larda drain davranışı ayrıca kontrol edilmelidir. Scale-down sırasında 5xx artışı olmamalıdır.

Health probes

Startup, readiness ve liveness probe farklı amaçlara hizmet eder. Readiness trafik almaya hazır olma durumunu doğru göstermelidir. Liveness geçici downstream yavaşlığında tüm Pod'ları yeniden başlatmamalıdır. Probe timeout ve failureThreshold değerleri gerçek uygulama davranışına göre seçilmelidir. Probe transition metric'leri monitoring sistemine eklenmelidir.

Pod Autoscaling

Pod autoscaling kontrolünde metric, min ve max replica ile stabilization ayarları birlikte doğrulanmalıdır. Metric uygulamanın gerçek talep sinyalini temsil etmelidir. Minimum replica failure ve cold start hedefiyle uyumlu olmalıdır. Maximum replica downstream limitlerini aşmamalıdır. Spike ve sustained load testleri policy'nin doğru davrandığını göstermelidir.

Doğru metric

CPU yalnızca uygulama yüküyle güçlü korelasyon gösteriyorsa kullanılmalıdır. Web API için RPS veya concurrency daha erken sinyal olabilir. Queue consumer için lag veya queue age daha anlamlıdır. Metric pipeline güvenilir ve düşük gecikmeli olmalıdır. Scaling sonrası SLO iyileşmesi metric seçiminin başarısını doğrular.

min/max replicas

Minimum replica cold start ve availability için taban kapasiteyi belirler. Maximum replica cost ve downstream koruması sağlar. İki değer load test kapasitesine dayanmalıdır. Zone sayısı minimum replica kararında hesaba katılmalıdır. Max değere sık ulaşılması capacity alarmı olarak görülmelidir.

stabilization

Stabilization kısa metric dalgalanmalarının sürekli replica değişimi oluşturmasını önler. Scale-down için daha uzun pencere yaygın bir yaklaşımdır. Trafik örüntüsü çok hızlıysa gereksiz warm kapasite oluşabilir. Çok kısa pencere thrashing yaratabilir. Replica change frequency üzerinden ayar doğrulanmalıdır.

Node Autoscaling

Node autoscaling kontrolü HPA'nın oluşturduğu Pod'ların gerçek compute kapasitesine ulaşmasını garanti etmeye odaklanır. Uygun instance class, cloud quota ve consolidation davranışı test edilmelidir. Pending Pod reason dashboard'da görünür olmalıdır. Node Ready süresi peak trafik hedefiyle karşılaştırılmalıdır. Scale-down sırasında PDB ve topology constraint engelleri izlenmelidir.

Uygun node kapasitesi

Node instance type Pod resource ve özel donanım ihtiyacını karşılamalıdır. Büyük request küçük node'a sığmayabilir. GPU workload yalnızca accelerator node üzerinde çalışabilir. Birden fazla uygun instance seçeneği capacity bulunabilirliğini artırır. NodePool veya node group politikası workload sınıflarıyla uyumlu olmalıdır.

quota

Cloud quota node autoscaler'ın teorik kapasitesini gerçek hayatta sınırlar. vCPU, IP ve instance limitleri düzenli izlenmelidir. Peak dönemden önce limit artış ihtiyacı kontrol edilmelidir. Quota error production alert'i olmalıdır. Autoscaler logu ile cloud event'i birlikte incelenmelidir.

consolidation

Consolidation düşük kullanılan node'ları azaltarak maliyet verimliliği sağlar. Pod disruption güvenli sınırlar içinde tutulmalıdır. Çok sık node replacement cache ve startup maliyeti oluşturabilir. PDB ve topology constraint'ler hareket alanını belirler. Cost tasarrufu ile disruption sayısı aynı raporda değerlendirilmelidir.

Availability

Availability katmanı tek Pod veya node arızasında uygulamanın hizmet vermeye devam etmesini hedefler. PDB, topology spread ve multi-zone kapasite birbirini tamamlar. Minimum replica tek failure domain'e sıkışmamalıdır. Node autoscaler failure sonrası yeni kapasite ekleyebilir, fakat provisioning zaman alır. Warm kapasite bu süre boyunca SLO'yu korumalıdır.

PDB

PDB gönüllü disruption sırasında kullanılabilir replica sayısını korur. minAvailable değeri HPA minimum replica ile uyumlu olmalıdır. Çok katı ayar node drain'i engelleyebilir. Çok gevşek ayar maintenance sırasında fazla Pod kaybına yol açabilir. Node scale-down testi bu dengeyi doğrular.

topology spread

Topology spread replica'ları farklı node ve zone'lara dağıtır. `maxSkew` kabul edilen dengesizliği belirler. HPA yeni Pod açarken kuralların uygulanması gerekir. Zone kapasitesi yoksa Pending Pod oluşabilir. Failure test bu davranışın SLO ile uyumunu gösterir.

multi-zone

Multi-zone deployment tek zone arızasına karşı dayanıklılık sağlar. Pod ve node kapasitesi en az iki veya daha fazla zone'da bulunmalıdır. State ve storage bileşenleri de aynı failure modeline göre tasarlanmalıdır. Same-zone routing network maliyetini azaltabilir. Zone kaybında kalan kapasitenin toplam trafiği taşıyabildiği test edilmelidir.

Observability

Observability olmadan autoscaling kontrol döngüsünün neden belirli karar verdiğini anlamak zordur. RPS, latency, error rate, replica count ve node count aynı dashboard'da bulunmalıdır. Pending Pod ve metric error bilgileri kapasite zincirindeki gecikmeyi gösterir. Pod ve zone bazlı dağılım toplam ortalamaların gizlediği hotspot'ları açığa çıkarır. Alert'ler kullanıcı etkisine ve kapasite sınırlarına bağlanmalıdır.

RPS

RPS toplam talep hacmini gösterir. Pod başına RPS load balancing dengesini ölçer. Replica artışı sonrası trafik dağılımının nasıl değiştiği izlenmelidir. Endpoint bazında aşırı fark session veya connection problemine işaret edebilir. RPS SLO ve cost metriğiyle birlikte kullanılmalıdır.

latency

p95 ve p99 latency kullanıcı deneyimini gösterir. Scale-up başladıktan sonra latency'nin ne kadar sürede normale döndüğü ölçülmelidir. Pod warm-up veya node provisioning süresi grafikte görülebilir. Replica artmasına rağmen latency yüksekse darboğaz başka yerdedir. SLO threshold dashboard üzerinde açıkça gösterilmelidir.

error rate

Error rate scaling geçişlerinin kullanıcıya hata olarak yansıyıp yansımadığını gösterir. Scale-down sırasında 5xx artışı graceful shutdown problemine işaret edebilir. Retry kaynaklı başarısızlıklar ayrı metric olarak izlenmelidir. Gateway ve application error rate karşılaştırılmalıdır. Alarm yalnızca kısa tek spike yerine SLO burn rate ile ilişkilendirilebilir.

replica count

Desired, current ve Ready replica ayrı ayrı izlenmelidir. Desired ile Ready farkı scaling pipeline gecikmesini gösterir. Çok sık değişim thrashing belirtisidir. Max replica sınırına ulaşma capacity riskidir. Replica grafiği RPS ile aynı zaman ekseninde bulunmalıdır.

node count

Node count cluster kapasitesinin zaman içindeki değişimini gösterir. Pending Pod sonrası node artışının ne kadar sürdüğü ölçülmelidir. Traffic düştükten sonra gereksiz node'ların kaldırılıp kaldırılmadığı izlenmelidir. Instance type ve zone dağılımı ayrı boyutlar olarak gösterilebilir. Cost raporu node count verisiyle bağlanmalıdır.

Cost

Cost kontrolü autoscaling tasarımının sonunda değil başlangıcında düşünülmelidir. Right-sizing, idle capacity, spot kullanımı ve network egress farklı maliyet kalemleridir. En ucuz politika SLO'yu bozan politika olmamalıdır. Resource başına değil başarılı iş başına maliyet daha anlamlı karşılaştırma sağlar. Düzenli FinOps review scaling parametrelerini canlı trafik verisiyle güncel tutar.

right-sizing

Right-sizing Pod request ve limit değerlerini gerçek kullanım profiline yaklaştırır. Fazla request gereksiz node maliyeti oluşturur. Düşük request HPA ve scheduler kararlarını bozar. VPA recommendation veri sağlayabilir. Her büyük release sonrası resource profili tekrar ölçülmelidir.

idle capacity

Idle capacity tamamen israf değildir, çünkü burst ve failure sırasında güvenlik payı sağlar. Ancak saatlerce hiç kullanılmayan büyük kapasite optimize edilebilir. Minimum Pod ve node değerleri SLO'ya göre belirlenmelidir. Scale-to-zero bazı batch workload'larda uygun olabilir. Idle capacity yüzdesi uygulama sınıfına göre hedeflenmelidir.

Spot

Spot kesintiye toleranslı workload'larda önemli maliyet avantajı sunabilir. Kritik taban kapasiteyi tamamen spot'a bağlamak risklidir. Batch ve kolay yeniden schedule edilen stateless Pod'lar daha uygun adaydır. Interruption handling ve PDB test edilmelidir. Spot tasarrufu restart ve iş tekrarı maliyetiyle birlikte hesaplanmalıdır.

network egress

Network egress ve cross-zone trafik compute kadar önemli maliyet oluşturabilir. Same-zone routing tercihleri bu maliyeti azaltabilir. Multi-region sistemde data transfer daha da büyür. Cost dashboard network trafik yönünü göstermelidir. Network tasarrufu için availability veya latency hedefleri feda edilmemelidir.

Sık Sorulan Sorular

Kubernetes autoscaling konusunda sorular genellikle HPA'nın tanımından başlar, fakat üretim ortamına yaklaştıkça Service, Gateway, node kapasitesi ve metric seçimi daha önemli hale gelir. Aşağıdaki yanıtlar temel kavramları kısa ama uygulamaya dönük biçimde özetler. Her cevap tek başına bir YAML reçetesi yerine ilgili kontrol döngüsünün nasıl çalıştığını anlatır. Böylece problemi hangi katmanda aramanız gerektiği daha anlaşılır hale gelir. Production sistemlerinde bütün bu yanıtların load test ve gözlemlenebilirlikle doğrulanması gerekir.

Kubernetes'te load balancing nasıl çalışır?

Kubernetes Service dinamik Pod kümesini sabit erişim noktası arkasında toplar. EndpointSlice hangi Pod endpoint'lerinin uygun olduğunu temsil eder. kube-proxy veya eBPF veri yolu Service trafiğini backend hedeflere taşır. Dış HTTP trafiği Gateway veya Ingress üzerinden uygun Service'e yönlendirilebilir. Uzun bağlantı ve session affinity nedeniyle trafik dağılımı her zaman replica başına eşit olmayabilir.

Kubernetes otomatik ölçekleme nasıl yapılır?

Önce hangi katmanın ölçekleneceği belirlenir. Pod sayısı için HPA veya KEDA, resource right-sizing için VPA ve node kapasitesi için node autoscaler kullanılabilir. Metric gerçek kullanıcı talebini temsil etmelidir. Resource request, probe ve node kapasitesi birlikte hazırlanmalıdır. Son adım load test ile scale-up ve scale-down davranışını doğrulamaktır.

HPA nedir?

HPA workload replica sayısını metric hedeflerine göre otomatik değiştirir. CPU ve memory yanında custom ve external metrics kullanılabilir. Birden fazla metric tanımlandığında her biri değerlendirilir. En yüksek replica ihtiyacı kapasite kararında belirleyici olabilir. Behavior ayarları artış ve azalış hızını kontrol eder.

VPA nedir?

VPA Pod CPU ve memory request değerleri için öneri veya güncelleme mekanizması sunar. Replica sayısını yatay olarak artırmak yerine Pod başına kaynak boyutlandırmasına odaklanır. Recommendation modu düşük riskli başlangıçtır. Otomatik update Pod restart etkisi oluşturabilir. CPU utilization HPA ile birlikte kullanılırken request denominator etkileşimi dikkate alınmalıdır.

KEDA nedir?

KEDA event-driven Kubernetes autoscaling projesidir. Kafka, queue, Prometheus ve cron gibi dış kaynakları scaling trigger olarak kullanabilir. ScaledObject Deployment benzeri workload'ları yönetir. Uygun external trigger senaryolarında scale-to-zero mümkündür. Queue consumer ve background worker sistemlerinde özellikle güçlüdür.

Cluster Autoscaler nedir?

Cluster Autoscaler mevcut node'lara yerleşemeyen Pod'lar için node group kapasitesini artırabilir. Uygun koşullarda kullanılmayan node'ları da azaltabilir. HPA ile farklı katmanda çalışır. HPA Pod ister, Cluster Autoscaler bu Pod için compute alanı sağlayabilir. PDB ve scheduling constraint'ler scale-down davranışını etkiler.

Karpenter nedir?

Karpenter workload gereksinimlerine göre dinamik node provisioning yapabilen açık kaynaklı bir yaklaşımdır. NodePool hangi instance, zone ve capacity type seçeneklerinin kullanılabileceğini tanımlar. Pod request ve constraint'lerine uygun compute seçilebilir. Consolidation maliyet verimliliğine katkı sağlar. Cloud provider desteği ve operasyon modeli seçim öncesinde değerlendirilmelidir.

HPA ile Cluster Autoscaler arasındaki fark nedir?

HPA Pod replica sayısını değiştirir, Cluster Autoscaler node kapasitesini değiştirir. HPA yeni Pod istediğinde mevcut node'larda yer yoksa Pod Pending kalır. Cluster Autoscaler uygun node group'u büyütebilir. Scheduler yeni node'a Pod'u yerleştirir. İki controller birlikte uçtan uca yatay kapasite artışı sağlar.

KEDA ile HPA arasındaki fark nedir?

HPA genel Kubernetes replica autoscaler'ıdır. KEDA dış event source'ları scaling sürecine bağlamayı kolaylaştırır. ScaledObject çoğu durumda HPA ile birlikte çalışır. KEDA sıfırdan replica açma ve geniş scaler kataloğu konusunda güçlüdür. CPU tabanlı basit API'de doğrudan HPA daha sade olabilir.

Kubernetes'te Ingress mi Gateway API mi kullanılmalı?

Mevcut çalışan Ingress ortamı yalnızca temel HTTP routing kullanıyorsa değiştirmek zorunlu değildir. Yeni platformlarda Gateway API rol ayrımı ve daha geniş route modellemesi sunar. HTTPRoute ve GRPCRoute gibi kaynaklar protokol niyetini açık ifade eder. Controller'ın Gateway API conformance desteği kontrol edilmelidir. Seçim ekip deneyimi ve gerçek özellik ihtiyacına dayanmalıdır.

ClusterIP ile LoadBalancer arasındaki fark nedir?

ClusterIP Service'i cluster içinden erişilebilir yapar. LoadBalancer destekleyen platformda harici veya internal load balancer provisioning isteyebilir. Her ikisi de backend Pod kümesini Service abstraction üzerinden temsil edebilir. HTTP uygulamalarında her Service için ayrı LoadBalancer yerine ortak Gateway kullanılabilir. Seçim trafiğin nereden geleceğine göre yapılmalıdır.

Kubernetes Service trafiği Pod'lara nasıl dağıtır?

Service bir sanal erişim noktası ve endpoint kümesi sunar. EndpointSlice sağlıklı backend bilgilerini taşır. kube-proxy veya eBPF tabanlı veri yolu paketi uygun Pod endpoint'ine iletir. Readiness başarısız olan Pod normal trafik için hedef olmamalıdır. Long-lived connection ve affinity gerçek dağılımı etkileyebilir.

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

Current metric hedefin altında olabilir veya HPA maxReplicas sınırına ulaşmış olabilir. Metric API hata veriyor olabilir. CPU utilization için resource request tanımları eksik veya yanlış olabilir. HPA condition ve event bilgisi controller kararını gösterir. İlk kontrol target metric ile current metric değerini karşılaştırmaktır.

HPA çalışırken Pod'lar neden Pending kalır?

HPA yalnızca replica ihtiyacını artırır, scheduler kapasitesini garanti etmez. Node CPU veya memory yetersiz olabilir. Affinity, taint, zone veya cloud quota problemi de Pod'u Pending bırakabilir. Node autoscaler uygun kapasite sağlayabiliyorsa yeni node açar. `kubectl describe pod` scheduling reason en hızlı teşhis kaynağıdır.

Kubernetes'te CPU dışında hangi metriklerle scale edilebilir?

Memory, RPS, active connections, queue length, queue age, Kafka lag ve business metrics kullanılabilir. Custom veya external metrics için uygun adapter ya da KEDA scaler gerekir. Metric replica artışıyla gerçekten iyileşen bir kapasite sinyali olmalıdır. p95 latency doğrulama metriği olarak değerlidir. En iyi metric uygulamanın gerçek darboğazına bağlıdır.

Kubernetes scale-to-zero destekler mi?

Event-driven kullanımda KEDA gibi araçlarla workload replica sayısını sıfıra indirmek mümkündür. Uygun external event geldiğinde kapasite tekrar açılır. Cold start bu modelin temel dezavantajıdır. User-facing düşük latency servislerde minimum replica bir veya daha yüksek tutulabilir. Batch ve seyrek worker sistemleri scale-to-zero için daha uygun adaylardır.

Kubernetes autoscaling maliyeti azaltır mı?

Doğru yapılandırıldığında boş kapasiteyi azaltarak maliyet düşürebilir. Ancak çok düşük request veya gürültülü metric gereksiz replica ve node artışı oluşturabilir. Scale-to-zero, right-sizing ve node consolidation ek tasarruf sağlar. Cross-zone network maliyeti de hesaba katılmalıdır. Başarılı request başına maliyet en sağlıklı karşılaştırma metriklerinden biridir.

Kubernetes için Go mu Python mı öğrenilmeli?

Controller ve operator geliştirmek istiyorsanız Go ekosistemde güçlü bir seçimdir. Automation ve API entegrasyonu için Python oldukça pratiktir. Kubernetes kullanmak için iki dilden biri zorunlu değildir. Linux, networking ve declarative API temelleri daha önce öğrenilmelidir. En iyi seçim yapmak istediğiniz proje türüne bağlıdır.

Ek Sık Sorulan Sorular

Aşağıdaki sorular özellikle production kurulumu, HPA yapılandırması ve yerel öğrenme veya danışmanlık arayışında sık karşılaşılan ihtiyaçları özetler. Cevapların ortak noktası load balancing ile autoscaling'in tek bir controller üzerinden ele alınmaması gerektiğidir. Service trafiği taşırken HPA replica ihtiyacını, node autoscaler ise compute ihtiyacını yönetir. Doğru metric ve gerçekçi load test bu katmanları aynı hedef etrafında birleştirir. Eğitim veya ekip çalışmasında da önce bu uçtan uca akışın anlaşılması en güçlü başlangıçtır.

Kubernetes üzerinde yük dengeleme (Load Balancing) nasıl yapılandırılır?

Önce Pod'ları temsil eden bir Service oluşturulur ve selector ile doğru backend kümesi tanımlanır. Dış HTTP veya HTTPS erişimi gerekiyorsa Gateway API ya da mevcut platform standardına uygun Ingress eklenebilir. L4 erişimi için LoadBalancer Service kullanılabilir. Readiness probe yalnızca sağlıklı Pod'ların trafik almasını sağlar. Son aşamada EndpointSlice ve Pod bazlı RPS kontrol edilerek yeni replica'ların gerçekten yük dengeleme havuzuna katıldığı doğrulanmalıdır.

Kubernetes HPA, VPA ve Cluster Autoscaler arasındaki farklar nelerdir?

HPA Pod replica sayısını yatay olarak değiştirir. VPA CPU ve memory request right-sizing problemine odaklanır. Cluster Autoscaler ise Pod'ların çalışacağı node kapasitesini artırıp azaltır. HPA yeni Pod isterken mevcut node'lar doluysa Cluster Autoscaler devreye girebilir. VPA'nın CPU request değişiklikleri CPU utilization HPA'yı etkileyebileceği için birlikte kullanım bilinçli tasarlanmalıdır.

Horizontal Pod Autoscaler (HPA) CPU, bellek ve özel metriklere göre nasıl yapılandırılır?

`autoscaling/v2` HPA bir veya birden fazla metric tanımlamayı destekler. CPU ve memory resource metrics için metrics API, custom metric için uygun adapter altyapısı gerekir. Resource utilization kullanılacaksa request değerleri gerçekçi olmalıdır. Birden fazla metric tanımlandığında controller her biri için replica ihtiyacı hesaplar ve gerekli kapasiteyi koruyan daha yüksek öneriyi dikkate alabilir. Scale-up ve scale-down behavior değerleri load test sonuçlarına göre ayarlanmalıdır.

Kubernetes Service, Ingress ve LoadBalancer kullanılarak trafik dağıtımı ve otomatik ölçekleme nasıl birlikte yönetilir?

LoadBalancer dış trafiği cluster'a getirir, Ingress veya Gateway L7 route kuralını uygular ve Service dinamik Pod kümesini temsil eder. HPA backend Deployment replica sayısını metric'e göre artırır. Yeni Pod Ready olduğunda endpoint kümesine katılır ve Service üzerinden trafik alabilir. Mevcut node kapasitesi yetmezse node autoscaler yeni compute sağlar. Bu zincir Kubernetes Ingress Service LoadBalancer ve HPA birlikte nasıl kullanılır sorusunun production karşılığıdır.

Kubernetes yük dengeleme ve otomatik ölçekleme konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Bu alanda destek ararken yalnızca bir HPA manifesti hazırlayan yaklaşım yerine networking, metrics, scheduler ve node kapasitesini birlikte ele alan eğitimleri tercih etmek gerekir. “Kubernetes yük dengeleme ve DevOps danışmanlığı yakınımda” veya “kurumsal Kubernetes load balancing ve autoscaling kurulum hizmeti” gibi aramalardaki gerçek ihtiyaç çoğu zaman ekiplerin production senaryolarını uygulamalı biçimde öğrenmesidir. Diyarbakır'da yazılım ve cloud-native konularında topluluk çalışmalarını takip etmek için https://www.diyarbakiryazilim.com.tr adresine ulaşabilirsiniz. Proje üretmek, workshop yapmak ve gerçek metric'lerle küçük laboratuvarlar kurmak öğrenme sürecini ciddi biçimde hızlandırır. Danışmanlık veya eğitim seçerken de load test, observability ve failure test yaklaşımının kapsamda olup olmadığını mutlaka sorun.

Sonuç

Kubernetes Üzerinde Yük Dengeleme ve Otomatik Ölçekleme, yalnızca trafiği birkaç Pod'a dağıtmak veya CPU yükseldiğinde replica sayısını artırmak değildir. Sağlam bir mimaride Service ve EndpointSlice trafiğin kullanılabilir backend'lere ulaşmasını sağlar, Gateway veya Ingress dış yönlendirmeyi yönetir, HPA veya KEDA Pod kapasitesini değiştirir ve node autoscaler gerekli compute alanını oluşturur. Readiness probe, graceful shutdown, topology spread, PDB, metric seçimi ve load test bu zincirin güvenli çalışmasını sağlar. En güçlü yaklaşım her katmanı ayrı ayrı kurmak yerine RPS yükseldiği andan yeni Pod'un gerçek trafik almaya başladığı ana kadar bütün süreci tek bir sistem olarak ölçmektir. Bu bakış açısı oturduğunda Kubernetes autoscaling hem kullanıcı deneyimini koruyan hem de kaynak kullanımını daha kontrollü hale getiren bir platform özelliğine dönüşür.

Kendi Kubernetes laboratuvarınızı kurmak, benzer projeleri incelemek veya Diyarbakır Yazılım Topluluğu çalışmalarına katılmak istiyorsanız https://www.diyarbakiryazilim.com.tr adresinden topluluğa ulaşabilirsiniz. En iyi başlangıç küçük bir API, bir Service, bir HPA ve basit bir load test kurmaktır. Ardından aynı sisteme custom metric, KEDA, Gateway API ve node autoscaling katmanlarını ekleyebilirsiniz. Her aşamada latency, replica ve cost değerlerini karşılaştırmak öğrendiklerinizi gerçek veriye dönüştürür. Böylece Kubernetes Üzerinde Yük Dengeleme ve Otomatik Ölçekleme konusu yalnızca dokümantasyonda okunan bir kavram olmaktan çıkar ve üretim ortamında ölçebildiğiniz bir mühendislik pratiğine dönüşür.