RadarGitHub Radarai üretimi

GitHub Radar — Karpenter

Statik node havuzlarını ve ASG gecikmelerini kaldırarak pod ihtiyaçlarına göre tam boyutlu bulut sunucularını saniyeler içinde ayağa kaldıran dinamik ölçekleyici.

Karpenter, Kubernetes kümelerinde on yıldır endüstri standardı kabul edilen hantal Auto Scaling Group (ASG) mekanizmalarını ve statik düğüm havuzlarını tamamen ortadan kaldırarak bekleyen iş yüklerinin ihtiyaç duyduğu sanal makineleri doğrudan bulut sağlayıcıların filo API’leri üzerinden saniyeler içinde ayağa kaldıran yeni nesil bir düğüm otomatik ölçekleyicisidir 1. Klasik Cluster Autoscaler araçlarının önceden tanımlanmış katı sunucu tiplerine bağımlı kaldığı, yeni bir düğüm başlatmak için 3 ila 5 dakika beklettiği ve kaynak parçalanması (fragmentation) yüzünden bulut faturalarını şişirdiği geleneksel mimarilere karşı Karpenter; matematiksel kutu paketleme (bin-packing) algoritmaları, otomatik düğüm birleştirme (consolidation) ve anlık yapılandırma kayması tespitiyle (drift detection) altyapı maliyetlerini %50’ye varan oranda düşüren radikal bir sistem kontrolcüsüdür 2.

Bulut yerel platform mühendisliği, büyük ölçekli Kubernetes orkestrasyonu ve FinOps çevrelerinde 8 bin yıldız ve son commit 1 gün önce düzeyinde sarsılmaz bir sektör standardına dönüşen depo, CNCF topluluğu tarafından titizlikle yönetilen 250 açık issue ve kurumsal kararlılık sunan son sürüm v1.11.0 (Eylül 2026) metrikleriyle olgunluğunu kanıtlamaktadır.

Mimari Deep-Dive: Karpenter

Karpenter’ın Kubernetes orkestrasyonunda yarattığı en büyük mimari dönüşüm, düğüm yönetimini “önceden tanımlanmış statik sunucu gruplarından” çıkarıp “iş yükünün anlık gereksinimlerine göre şekillenen tam zamanında (just-in-time) dinamik kapasiteye” dönüştürmesidir. Proje bütünüyle saf Go diliyle geliştirilmiştir 1. Go seçimi; Kubernetes API sunucusuyla controller-runtime üzerinden mikrosaniyelik denetim döngüleri (reconciliation loops) kurmak, goroutine’ler aracılığıyla binlerce pod olayını eşzamanlı işlemek ve bulut SDK’ları üzerinden asenkron API çağrıları yürütmek amacıyla yapılmıştır.

İlk temel mimari sıçrama grup bağımsız (group-less) düğüm tahsisidir 3. Geleneksel mimarilerde ekipler genel amaçlı işler, bellek yoğun işler ve GPU iş yükleri için ayrı ayrı onlarca ASG tanımlamak zorundadır. Karpenter ise NodePool ve EC2NodeClass CRD’leri üzerinden çalışır. Bir pod zamanlanamadığında (unschedulable), Karpenter Kubernetes zamanlayıcısının (kube-scheduler) filtreleme mantığını bellek içinde simüle eder. Pod’un talep ettiği CPU, bellek, GPU, mimari (ARM64 veya x86_64), topoloji yayılım kısıtları (topologySpreadConstraints), taints ve tolerasyonlarını doğrudan inceler.

İkinci kritik sütun çok değişkenli kutu paketleme (bin-packing) ve filo optimizasyonudur. Karpenter, bekleyen pod kümesini tek bir tam sayılı doğrusal programlama (integer linear programming) problemi olarak ele alır. Pod’ları en düşük maliyetle barındırabilecek sanal makine ailesini ve boyutunu milisaniyeler içinde hesaplar. Yüzlerce farklı EC2 veya Azure sanal makine tipinin anlık fiyatlarını ve kapasite durumlarını değerlendirir. Ardından bulut sağlayıcının filo API’sine (örneğin AWS CreateFleet) doğrudan tek bir çağrı yaparak, ihtiyaç duyulan tam kapasiteyi (Spot veya On-Demand) 30 ila 45 saniyede ayağa kaldırıp kümeye bağlar.

Üçüncü sütun ise otomatik birleştirme (consolidation) ve yaşam döngüsü yönetimidir 4. Karpenter kümeyi sürekli gözlemler; düğümler üzerindeki pod’lar azaldığında veya iş yükleri daha küçük ya da daha ucuz tek bir sunucuya taşınabilecek duruma geldiğinde düğümleri otomatik olarak kordon altına alır (cordon), boşaltır (drain) ve sonlandırır. Ayrıca temel işletim sistemi imajı (AMI) güncellendiğinde, güvenlik yaması çıktığında veya NodePool yapılandırması değiştiğinde “drift” mekanizmasını tetikleyerek PodDisruptionBudget kurallarına sadık kalarak düğümleri kesintisiz biçimde yeniler.

Kod ve Topluluk Sağlığı

Karpenter, Amazon Web Services (AWS) konteyner mühendisliği ekibi tarafından başlatılmış olup günümüzde Kubernetes Special Interest Group (SIG-Autoscaling), Microsoft Azure ve geniş CNCF topluluğu tarafından ortaklaşa yönetilmektedir 1. Proje, Slack, Datadog ve yüzlerce küresel kuruluşun devasa üretim altyapılarını emanet ettiği kurumsal bir açık kaynak liderliğine sahiptir.

Depodaki 250 açık issue sayısı, projenin çoklu bulut desteği (AWS, Azure, Cluster-API entegrasyonları) ve karmaşık kurumsal güvenlik politikaları içeren devasa ekosistemine oranla mükemmel bir bakım disiplinini yansıtmaktadır. Maintainer kadrosu hata bildirimlerini ve özellik isteklerini haftalık SIG toplantılarında şeffaf olarak önceliklendirmekte, sürüm yükseltme rehberlerini titizlikle yayımlamaktadır. Çekirdek depoya sunulan her PR; binlerce sanal düğümlü ölçek simülasyonlarından, karmaşık kesinti senaryolarından ve katı Go eşzamanlılık testlerinden geçer 5. Sürüm takvimi düzenli semantik aralıklarla kararlı biçimde yürütülmektedir. health_score bu bölümden türer: issue kapanma hızı, sürüm düzeni, bakımcı ekibi. Ajanın tahminidir; künyede öyle yazılır. Projenin açık kaynak bulut orkestrasyonundaki devrimci etkisi, üstün issue yönetimi ve çoklu şirket desteği dikkate alınarak health_score: 9.5 takdir edilmiştir.

Production Riski: Gerçekten Kullanılır mı?

Karpenter’ı üretim altyapılarına entegre etmeyi değerlendiren sistem mimarları için lisanslama açısından hiçbir hukuki risk bulunmamaktadır; proje Apache 2.0 lisansı ile dağıtılmakta olup şirket içi hibrit altyapılarda veya ticari genel bulut ortamlarında tam kullanım serbestisi sunar 6.

Karpenter’ın üretimde tartışmasız hayat kurtardığı senaryolar son derece açıktır: Değişken trafik alan mikroservis mimarileri, büyük ölçekli makine öğrenimi eğitim işleri (Spot GPU tedariği) ve onlarca statik düğüm havuzunun yarattığı operasyonel karmaşadan kurtulmak isteyen platform mühendisliği ekipleri. Pod’ların dakikalarca beklemeden 40 saniyede ayağa kalkması ve otomatik konsolidasyon sayesinde bulut bilişim faturalarında %30 ila %50 tasarruf sağlanması en somut operasyonel kazançtır.

Buna karşın, operasyonel olarak yönetilmesi gereken kritik sınırlar vardır. İlk risk, hatalı yapılandırılmış PodDisruptionBudget (PDB) kurallarıdır; aşırı katı PDB tanımları Karpenter’ın düğümleri boşaltmasını engelleyerek konsolidasyonu kilitleyebilir. İkinci risk ise ani devasa ölçeklenmelerde bulut sağlayıcının API hız sınırlarına (API rate limiting) takılma olasılığıdır. Ayrıca Spot düğüm kullanımında ani bulut geri çağırmalarına (spot eviction) karşı NodePool tanımlarında instance çeşitliliğinin geniş tutulması şarttır. Doğru yapılandırıldığında Karpenter, modern Kubernetes altyapıları için geliştirilmiş en yetkin, en hızlı ve ekonomik düğüm yöneticisidir.

Kaynaklar

  1. Karpenter GitHub Ana Deposu
  2. Karpenter Resmi Dokümantasyonu ve Çizelgeleme Mimarisi
  3. Karpenter NodePools ve Düğüm Yaşam Döngüsü Kılavuzu
  4. AWS Containers Blog: Slack Karpenter Geçişi ve Maliyet Optimizasyonu
  5. Karpenter GitHub Sürüm Notları ve Değişiklik Günlüğü
  6. Karpenter Apache 2.0 Lisans Dosyası