Node Readiness Controller: Kubernetes’te Ready’nin Ötesi
Kubernetes ile uzun süredir uğraşıyorsanız şu tabloyu kesin görmüşsünüzdür: Node Ready oluyor, kubelet keyifli, control plane tamam diyor, scheduler pod atmaya başlıyor… ama CNI ajanı daha ayağa kalkmamış. Ya da GPU driver yüklenmemiş. Ya da storage plugin hâlâ init aşamasında (yanlış duymadınız). Pod düşüyor, restart oluyor, bir daha düşüyor, sonra CrashLoopBackOff. Klasik işte.
İşte bu eski dertlere Kubernetes tarafında yeni bir cevap geldi: Node Readiness Controller. Bugün bunu biraz didikleyelim. Ama önce şunu söyleyeyim — bu proje aslında çoğumuzun yıllardır kendi tarafımızda hackleyerek çözmeye çalıştığı işi daha düzenli hâle getiriyor. Ve açık konuşayım, bence bu baya rahatlatacak.
“Ready” gerçekten ready mi? İşin düğümü burada
Standart Kubernetes modelinde bir node’un iş yükü kabul edip etmeyeceği tek bir binary condition’a bağlı: Ready. Kubelet API server’a “ben hazırım” diyor, control plane bunu işaretliyor, scheduler da pod dağıtmaya başlıyor. Kağıt üstünde temiz dürüyor.
Gel gelelim modern bir cluster’da bir node’un gerçekten “hazır” sayılması için kubelet’in ayakta olması yetmiyor. Bir sürü parça daha var; CNI ajanı (Cilium, Calico, Azure CNI vs.) düğüme yerleşmiş ve routing tablolarını çekmiş olmalı, CSI driver’ları çalışıyor olmalı (özellikle stateful iş yüklerinde kritik), GPU node’larda NVIDIA driver ile DCGM ve device plugin ayağa kalkmış olmalı. Yanı mesele sadece node’un nefes alması değil.
Peki neden?
- CNI ajanı (Cilium, Calico, Azure CNI vs.) düğüme yerleşmiş ve routing tabloları çekilmiş olmalı
- CSI driver’ları çalışıyor olmalı — özellikle stateful iş yükleri için kritik
- GPU node’larda NVIDIA driver, DCGM, device plugin ayakta olmalı
- Log ajanı (Fluent Bit, Vector), metrics ajanı (Prometheus node-exporter) hazır olmalı — ciddi fark yaratıyor
- Bazı ortamlarda özel güvenlik ajanları (Falco, security-agent) tam init olmalı
Bunların hepsi çoğu zaman DaemonSet olarak koşuyor. Ve DaemonSet’in pod’u ayağa kalkarken node zaten Ready durumda oluyor — yanı başka pod’lar da o node’a düşebiliyor (ki bu çoğu kişinin gözünden kaçıyor). Klasik race condition. Sonuç? İlk 30-60 saniye içinde node’a inen pod’lar sallantılı zeminde başlıyor.
Peki şimdiye kadar nasıl idare ediyorduk?
Sahada bu problemi çözmek için dört-beş tane bilinen yöntem var. Hiçbiri pürüzsüz değil:
- Taint + toleration dansı: Node’u kendiniz taint’lersiniz, DaemonSet’ler toleration ile yerleşir; “hazır” olunca bir script taint’i kaldırır. Elle bakım istiyor, hata payı da fena değil yüksek. (bu kritik)
- Startup taint controller (Cilium tarzı): Cilium’un kendi startup taint mekanizması var — node.cilium.io/agent-not-ready. Güzel çalışıyor ama Cilium’a özel kalıyor.
- Init container’lar: Her iş yüküne bir init container ekleyip “CNI hazır mı?” diye bakarsınız. Ölçek büyüyünce can sıkıyor; aynı kodu tekrar tekrar yazıyorsunuz.
- Cluster autoscaler’a warm-up süresi vermek: Bir nevi hile gibi; “node ayağa kalkınca 90 saniye bekle sonra pod at” diyorsunuz. Kaba ama bazen işe yarıyor.
Açıkçası, Neyse uzatmayalım; Node Readiness Controller (NRR) tam da bu manzarayı toparlamaya geliyor. Vendor-neutral dürüyor, deklaratif gidiyor ve mevcut Node Condition dünyasıyla konuşuyor.
Node Readiness Controller nasıl çalışıyor?
Mimarinin merkezinde NodeReadinessRule (NRR) diye bir CRD var. Kabaca şöyle düşünün: “Şu label’a sahip (belki yanılıyorum ama) node’lar için şu Node Condition’ların hepsi True olana kadar şu taint’i uygula.” Sız bunu diyorsunuz; controller da önü yapıyor. Sız hiç denediniz mi? Bitti gibi görünüyor ama tabiî detay var (eh, fena değil)
Ama şeytan yine detayda saklanıyor. İki ayrı çalışma modu var ve sahada fark yaratıyorlar: (bizzat test ettim)
Iki farklı çalışma modu
Continuous enforcement, node’un tüm yaşam döngüsü boyunca kuralın aktif kalması demek. Diyelim ki üç ay sonra GPU driver upgrade sırasında bozuldu ve ilgili condition False öldü; controller anında node’u taint ediyor, yeni pod’lar düşmüyor. Mevcut pod’lara dokunmuyor (taint’in NoSchedule effect’i sayesinde), ama yeniler dürüyor. Production’da insanın içini biraz rahatlatan davranış bu.
Bootstrap-only enforcement, adından tahmin edeceğiniz gibi sadece ilk açılışta çalışıyor. Şöyle düşünün: 15 GB boyutunda base image pre-pull ediyorsunuz; bu tek seferlik işse sürekli kontrol etmenin pek anlamı yok. Bu mod tam orada işe yarıyor: condition True olduğu an controller “tamamdır” deyip o kuralın takibini bırakıyor. kubernetes ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik. Bu konuyla ilgili VS Code Haziran 2026 Copilot: Paralel Ajanlar ve Maliyet Netliği yazımıza da göz atmanızı tavsiye ederim.
İşin aslı şu ki çoğu ekip continuous mode’u default sanıp her şeyi ona bağlıyor. Halbuki bootstrap-only mode özellikle image warm-up, disk formatlama ve TPM attestation gibi tek seferlik işler için daha temiz dürüyor.
Kural motoru neye bakıyor?
NNR kendi health check’ını yazmıyor; bence güzel taraflarından biri de bu zaten.
Controller sadece Node Condition’ları dinliyor.
Yanı ekosistemde zaten
Node Problem Detector
varsa ya da custom script’leriniz varsa bunları aynen kullanabiliyorsunuz.
NRR burada reaktif katmanı sağlıyor.
Proje ayrıca
Readiness Condition Reporter
adında hafif bir ajan getiriyor;
görevi basit:
bir komut çalıştır,
exit code’a göre Node Condition’a True/False yaz.
Klasik shell script’i Kubernetes native hâle getiriyor yanı.
Peki neden?
Çünkü her şeyi controller içine gömmek yerine,
mevcut sinyal kaynaklarını kullanmak çok daha az sürpriz çıkarıyor.
Az önce başka şey anlattım ama aslında doğru nokta burası:
NRR karar verici değil,
kararı uygulayan katman gibi davranıyor.
Bu ayrım önemli.
Sız ne dersiniz? (yanlış duymadınız)
Küçük bir örnekle bakalım
Diyelim ki GPU node’larınız var ve NVIDIA driver hazır olmadan pod düşmesin istiyorsunuz.
Şöyle bir NRR yazabilirsiniz:
apiVersion: readiness.k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
name: gpu-driver-ready
spec:
nodeSelector:
matchLabels:
workload-type: gpu
requiredConditions:
— type: NvidiaDriverReady
status: "True"
— type: DCGMExporterReady
status: "True"
taint:
key: node.readiness/gpu-not-ready
effect: NoSchedule
mode: Continuous
Daha fazla bilgi için Microsoft Foundry Haziran 2026: Haziran’da Ne Değişti? yazımıza bakabilirsiniz.
Bakın, Bitti gitti.
Controller devreye girer,
GPU node’ları başlangıçta bu taint ile açar,
iki condition True olana kadar bekler,
sonra tainti siler.
Bir şey bozulursa geri koyar.
Fena değil yanı.
Birkaç dip not bırakayım:
GPU workload’lardaki pod spec’e bu taint için toleration eklemenize
gerek yok
— controller tainti kaldırdıktan sonra normal pod’lar zaten yerleşiyor.
Sadece erken dönemde çalışması gereken DaemonSet’ler,
mesela driver installer gibi işler,
toleration istiyor.
Burada dengeyi kaçırırsanız olay tersine döner.
Bu kadar mı?
Değil tabiî ama ana fikir bu.
Peki Türkiye’deki ekipler için anlamı ne?
Açık konuşayım;
Türkiye’de Kubernetes benimsemesi son üç-dört yılda ciddi hızlandı.
Ama şunu çok görüyorum:
birçok ekip AKS,
EKS ya da GKE gibi managed servisleri kullanıyor (en azından benim deneyimim böyle). Node bootstrapping detaylarına fazla inmiyor.
Managed hizmetin güzelliği burada tabi;
ama bazen de ince problemler radarın dışında kalıyor.
Kurumsal tarafta özellikle bankacılık ve telekom gibi regülasyonlu sektörlerde security agent’,
log forwarder’,
DLP ajanları gibi ağır DaemonSet’
ler var;
bunlar tam hazır olmadan pod düşmesi uyumluluk açısından tatsız oluyor.
Şimdiye kadar bunu çoğunlukla init container’
larla çözdük;
her uygulama ekibine “şu init container’
i ekle” diye dolaşıldığını gördüm ben.
NRR burada baya toparlayıcı olabilir.
Bir de küçük ekip tarafı var.
Tek generic node pool ile çalışan startup’
larda NRR biraz fazla gelebilir,
bunu dürüstçe söyleyeyim.
Cluster’
ınızda beş-altı node varsa ve iş yükünüz tek tipse,
bu controller ekstra operasyon demek olabilir.
Bootstrap süresi zaten kısa olur genelde;
o yüzden vanilla Kubernetes ile devam etmek bazen daha mantıklı çıkar.
Emin değilim ama sanırım burada sade kalmak çoğu zaman kazanır.
Neyse dağıttım biraz,
konuya dönelim.
| Senaryo | NRR Değer Katıyor mu? | Neden |
|---|---|---|
| Senaryo |
| Senaryo | NRR Değer Katıyor mu? | Neden |
|---|---|---|
| Tek tip node pool,basit workload | Evet/Hayır | Karmaşıklık artarsa değmez |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder