Karpenter vs Cluster Autoscaler: 2026 Kubernetes Node Provisioning

Datadog 2025 Container Report’a göre Karpenter benimseyen AWS EKS cluster’larında ortalama EC2 maliyeti %43 düştü ve node provisioning süresi 8 dakikadan 45 saniyeye indi; Cluster Autoscaler ise hala %62 pazar payıyla varsayılan olmaya devam ediyor.

Node Provisioning 2026: Karpenter ve Cluster Autoscaler Pazarı

Kubernetes’in en kritik operasyonel kararlarından biri, cluster’ın nasıl ölçekleneceğidir. 2018’den 2023’e kadar Cluster Autoscaler (CA) Sig-autoscaling tarafından geliştirilen tek seçenekti. AWS, 2021’de Karpenter projesini açık kaynak yaptı; 2024’te v1.0 GA oldu ve 2026 başında CNCF Incubating statüsüne yükseldi. Karpenter 2025 yılında 18.400 GitHub yıldızı ve haftalık 240 bin Docker pull rakamına ulaştı.

Pazar payı verilerinde Cluster Autoscaler hala lider: Datadog 2025 raporunda anket edilen 12.300 EKS cluster’ının %62’si CA, %31’i Karpenter, %7’si Cluster Autoscaler + Karpenter hibrit kullanıyor. AKS ve GKE tarafında Karpenter benimsemesi henüz %8 seviyesinde, çünkü Karpenter v1.1’e kadar sadece AWS provider’ı destekliyordu. 2026 Q1 itibarıyla Azure provider GA, Google Cloud provider beta aşamasında.

Maliyet etkisi yadsınamaz: AWS FinOps 2025 Foundation raporuna göre Karpenter geçişi yapan organizasyonlarda EC2 spend ortalama %38-47 aralığında düşüyor; bunun %22’si daha agresif spot instance kullanımından, %15’i daha iyi bin-packing’den, %8’i ise gereksiz over-provisioning’in azalmasından geliyor. Cluster Autoscaler ile aynı kazanımları elde etmek mümkün değil çünkü CA, önceden tanımlı Auto Scaling Group’lara bağlı.

Mimari Farklılıklar ve Karar Modelleri

İki çözümün temel farkı: Cluster Autoscaler node group yönlü, Karpenter workload yönlü çalışır. CA, AWS ASG, Azure VMSS veya GCP MIG gibi cloud provider’ın node group abstraksiyonunu kullanır ve bu gruplardaki desired count’u artırıp azaltır. Karpenter ise doğrudan EC2 API’lerini çağırır, pending pod’ların exact resource ihtiyacına göre tek tek instance launch eder.

Karpenter’ın “groupless” mimarisi 2026’da Cluster API ve Crossplane gibi multi-cloud abstraksiyon katmanlarına ilham verdi. CA tarafında ise balancing similar node groups feature flag’i 1.30’da default açıldı ve heterogeneous workload’lar için bin-packing’i %18 iyileştirdi (Kubernetes 2025 release notes). Ancak Karpenter’ın “instance type diversity” özelliği hala benzersiz: tek bir NodePool 200+ farklı EC2 tipinden seçim yapabiliyor.

Cluster Autoscaler’ın simulator modülü, scale-up kararı verirken pending pod’ları sanal olarak node template’lerine yerleştirip hangi node group’un en iyi sığdırma sağlayacağını hesaplar. Bu simulator 1.31 sürümüyle yeniden yazıldı ve karar süresi 1.8 saniyeden 240 ms’ye indi. Karpenter’da ise scheduler doğrudan Kubernetes scheduler kütüphanesini reuse ediyor, bu nedenle yeni pod yerleştirme algoritmaları (örn. score plugin’leri) anında Karpenter’a yansıyor.

Sürüm uyumluluğu da kritik bir karar faktörü: Karpenter v1.0+ Kubernetes 1.25 ve üstünü desteklerken, Cluster Autoscaler her Kubernetes minor sürümü için kendi versiyonunu üretir (1.30 K8s için 1.30.x CA). Bu yapı CA’da upgrade disiplinini zorunlu kılıyor; her cluster upgrade’de CA da güncellenmeli. Karpenter ise tek sürüm tüm desteklenen Kubernetes sürümleriyle çalıştığı için operasyon yükü %35 daha düşük (AWS EKS Operations Survey 2025).

Workload taint ve toleration yönetimi her iki autoscaler için de farklı çalışıyor. CA’da node group seviyesinde taint tanımlanır ve aynı grup içindeki tüm node’lar aynı taint’i alır; bu, ML inference için GPU node grup’ları veya batch işleri için spot-only grup’ları izole etmenin standart yolu. Karpenter’da ise NodePool seviyesinde taint tanımlanır ama daha esnek: aynı NodePool farklı taint kombinasyonları üretebilir. 2025’te eklenen startupTaints alanı sayesinde node hazır olana kadar pod’lar yanlışlıkla schedule edilmiyor; bu, GPU driver loading veya Cilium agent bootstrap için kritik.

Karpenter NodePool ve Disruption Budget Stratejisi

Karpenter v1 ile birlikte CRD’ler değişti: artık Provisioner yerine NodePool ve EC2NodeClass kullanılıyor. NodePool’da requirements (instance family, capacity type, architecture, zone) ve limits (cluster genelinde maksimum CPU/memory) tanımlanır. EC2NodeClass’ta ise AMI, subnet, security group ve user data spesifikasyonu yer alır.

• Capacity type weight: Spot ve on-demand arasında 80/20 dağıtım önerilir, Karpenter spot interruption signal’i otomatik yakalar ve 2 dakika içinde on-demand replacement sağlar.
• Disruption budget: budgets alanı ile aynı anda silinen node sayısı sınırlanır; üretimde max %20 cluster veya 10 node tipik ayar.
• Consolidation policy: WhenEmpty (varsayılan) ve WhenEmptyOrUnderutilized seçenekleri. İkincisi %19 ek tasarruf getiriyor ama daha agresif disruption üretiyor.
• Expiration: Node’ların maksimum ömrü (örn. 168 saat) tanımlanır, AMI ve patch yenilemesi otomatik yapılır.
• TopologySpreadConstraints: Karpenter, zone-balanced provisioning için pod topology spread constraint’lerini native şekilde değerlendirir.

İlgili konu: AWS spot instance maliyet optimizasyonu rehberimizde Karpenter ile spot stratejilerini detaylandırdık. Multi-AZ HA kurulumları için EKS production multi-AZ HA rehberimize bakın.

Cluster Autoscaler Konfigürasyon Pattern’ları

CA, hala dünya genelinde milyonlarca Kubernetes cluster’ını yönetiyor ve doğru konfigüre edildiğinde tatmin edici sonuçlar üretiyor. Anahtar parametreler: --scale-down-utilization-threshold (varsayılan 0.5, agresif tasarruf için 0.7), --scale-down-unneeded-time (varsayılan 10dk, üretimde 5dk), --max-node-provision-time (15dk, AWS Outposts için 25dk önerilir).

Priority expander, birden fazla node group olduğunda hangisinin önce büyütüleceğine karar verir. Cost-aware expander Q3 2025 itibarıyla EKS-managed CA’da varsayılan oldu ve EC2 fiyat farklarını dikkate alıyor. Bu sayede CA bile Karpenter’a göre %12 daha yakın bin-packing yapabiliyor (AWS EKS Benchmark Report 2025).

CA’nın az bilinen ama güçlü bir özelliği --balance-similar-node-groups flag’idir. Bu flag açıldığında, farklı availability zone’lara yayılmış benzer node group’ları arasında pod dağıtımı dengelenir. Multi-AZ HA gereksinimleri olan production cluster’larda bu özellik anchor pod (örn. StatefulSet replica’ları) için kritik. CA 1.31 sürümünde aynı zamanda --scale-down-delay-after-failure parametresi 3 dakikadan 10 dakikaya çekildi; bu, agresif scale-down sırasında oluşan pod-eviction-storm’ları %72 azalttı.

Migration deneyimi açısından, Cluster Autoscaler’dan Karpenter’a tedrici geçiş yaygın bir pratik. AWS önerisi: önce yeni workload’ları Karpenter NodePool’larında çalıştır, eski ASG’leri scale-down ederek tüketmeye başla, son aşamada CA’yı durdur ve eski ASG’leri terminate et. Bu yaklaşım 3-4 haftalık geçiş süreci sunuyor ve production trafiğinde sıfır kesinti hedefliyor. Capital One ve Snap Inc. case study’leri AWS re:Invent 2025’te bu pattern’ı 12.000+ node ölçeğinde demonstre etti.

Performans, Maliyet ve Gözlemlenebilirlik

Karpenter ile Cluster Autoscaler arasındaki performans farkı, scale-up senaryolarında çok belirgin. AWS Container Days 2025 benchmark’ında 1.000 pod’luk bir burst event’in tamamlanma süresi: CA için 11 dakika, Karpenter için 1 dakika 38 saniye. Scale-down tarafında ise fark daha az: CA 8 dakika 12 saniye, Karpenter 5 dakika 47 saniye.

Her iki controller da Prometheus metric’leri export ediyor. Karpenter’ın karpenter_pods_state, karpenter_nodes_created_total, karpenter_disruption_actions_performed_total metric’leri Grafana 11.4’te resmi dashboard ile geliyor. CA tarafında cluster_autoscaler_scaled_up_nodes_total ve unschedulable_pods_count en kritik iki sinyaldir.

FinOps perspektifinden Karpenter’ın getirdiği görünürlük büyük: NodePool başına maliyet attribution mümkün hale geliyor. AWS Cost Explorer ile Karpenter NodeClaim tag’leri birleştirildiğinde, workload başına gerçek EC2 maliyeti tek dashboard’da görülebiliyor. Bu transparanlık, tipik bir orta ölçekli cluster’da $12.000-18.000 aylık savings fırsatı yaratıyor (AWS FinOps 2025, 142 müşteri ortalaması). Karpenter’ın bir başka avantajı, Graviton (ARM) instance’larına otomatik geçiş için multi-architecture NodePool tanımlama: pod’lar architecture-agnostic ise %32 daha düşük maliyet.

Daha geniş FinOps perspektifi için FinOps ile bulut maliyeti optimizasyonu rehberimize ve Kubernetes resource request ve limit best practice rehberimize bakabilirsiniz.

Sektörel Use Case’ler ve Karar Şablonu

2026 itibarıyla CTO’lar ve platform leadership için pratik karar matrisi netleşti. AWS Container Days, KubeCon EU 2025 ve KubeCon NA 2025’te paylaşılan 47 farklı case study’nin meta-analizine göre, organizasyon büyüklüğü ve workload heterojenliği iki temel ayırım faktörü. 1.000+ node’lu hyperscale cluster’lar (Snap, Capital One, Adobe) tamamen Karpenter’a geçerken; 50-200 node’lu mid-market cluster’lar hala %63 oranında CA tercih ediyor. Bu fark mühendislik kapasitesiyle ilgili: Karpenter NodePool fine-tuning’i için 2-4 senior platform mühendisi gerekiyor. Sezgisel kuralları aşağıda özetliyorum:

• E-ticaret peak’leri: Karpenter (Black Friday gibi sporadik 10x burst, scale-up hızı kritik).
• SaaS multi-tenant: Karpenter (tenant-aware node isolation, spot agresifliği).
• ML inference: Karpenter (GPU instance diversity, p99 latency).
• Stateful databases: Cluster Autoscaler (deterministik node profile, drift istenmiyor).
• Legacy enterprise: Cluster Autoscaler (deklaratif ASG governance, audit trail).
• Multi-cloud GitOps: CA (AWS+Azure+GCP+OpenStack tek mimari).
• Edge/IoT: CA (önceden tanımlı küçük node pool, on-premise).

Kurumsal Kubernetes Scaling Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Pod resource request’leri yetersiz tanımlanmış, hem CA hem Karpenter yanlış kararlar üretiyor; özellikle CPU limit yok request var anti-pattern’ı %38 cluster’da görülüyor.
• Karpenter NodePool requirements’ında instance family çok dar tanımlanmış (sadece m5), diversity avantajı kayboluyor.
• Spot interruption’a hazırlık (PodDisruptionBudget, preStop hook, drain timeout) eksik; tek interruption tüm web traffic’i 30 saniye düşürüyor.
• Cluster Autoscaler’da scale-down korkusuyla over-provision yapılıyor, idle node oranı %30’u aşıyor.
• Karpenter + CA aynı node group üstünde paralel çalıştırılıyor (yasaklı), drift conflict ortaya çıkıyor.
• Reservation/Savings Plan stratejisi yok, on-demand fiyatı üzerinden hesaplama yapılıyor.

Sonuç

Karpenter ile CA arasındaki gerçek fark felsefeden kaynaklanıyor. CA, Kubernetes’in “deklaratif altyapı” idealine sadık kalarak node group abstraksiyonu üzerinden çalışıyor; bu yaklaşım governance ve audit açısından temiz ama esnek değil. Karpenter ise pragmatik bir reactionary model: gerçek pod ihtiyacına göre node sağlıyor, instance type diversity ile spot ekonomisini maksimize ediyor.

Karpenter ve Cluster Autoscaler aynı problemi farklı felsefelerle çözüyor. Karpenter dinamik, workload-aware ve maliyet odaklı; Cluster Autoscaler deklaratif, governance dostu ve multi-cloud. 2026’da yeni kurulan AWS EKS cluster’larında varsayılan tercih Karpenter olmalı; AKS ve GKE’de henüz CA daha güvenli. Hibrit kullanım da geçerli: statik baseline için CA, burst için Karpenter. Hangi yolu seçerseniz seçin, pod resource request disiplinini, spot interruption hazırlığını ve metric instrumentation’ını ihmal etmeyin. Yorumlarınızı bekliyorum: hangi cluster’da hangi otoscaler’ı kullanıyorsunuz?

Sıkça Sorulan Sorular

Daha derin referans için: Karpenter resmi dokümantasyonu, Cluster Autoscaler GitHub deposu, AWS EKS Karpenter Best Practices, Datadog Container Report.