Pod'ları istediğiniz düğüme yerleştirmek: taint, toleration ve affinity uygulaması

İki yaklaşım: düğüm iter, pod çeker

Kubernetes scheduler varsayılan olarak pod'u uygun kaynağı olan herhangi bir düğüme yerleştirir. Yerleşimi yönlendirmek gerektiğinde ters yönlü mekanizmalar vardır.

Taint ve toleration düğüm tarafından yönetilir: düğüm 'ben belirli pod'ları kabul etmem' der, yalnızca bu işareti taşımayı kabul eden (tolerate eden) pod'lar oraya yerleşebilir. Bir düğümü özel donanım, kritik sistem iş yükü ya da belirli bir ekip için ayırmak istediğinizde bu yöntem kullanılır.

NodeSelector ve affinity pod tarafından yönetilir: pod 'şu etiketlere sahip düğümlerde çalışmak istiyorum' der. Pod'un hangi tür düğüme gideceğini tarif eder.

Bu mekanizmalar birbirinin yerine geçmez. Taint tek başına pod'un o düğüme gideceğini garanti etmez; yalnızca diğerlerini uzak tutar. Pod'un belirli düğüme gitmesini sağlamak için ayrıca nodeSelector ya da node affinity gerekir. Özel donanımlı bir düğüm havuzunu doğru ayırmak bu yüzden genellikle ikisinin birlikte kullanımıdır.

Taint eklemek ve kaldırmak

Bir düğüme taint, anahtar, değer ve etkiden oluşur. Etki üç değerden biridir:

• NoSchedule: toleration'ı olmayan yeni pod'lar düğüme yerleştirilmez; zaten çalışanlar etkilenmez
• PreferNoSchedule: yumuşak sürümü; scheduler kaçınmaya çalışır ama zorunlu değildir
• NoExecute: toleration'ı olmayan pod'lar düğümden çıkarılır, toleration'ı olanlar kalır

Ekleme ve kaldırma komutları:

kubectl taint nodes <dugum_adi> gpu=true:NoSchedule kubectl taint nodes <dugum_adi> gpu=true:NoSchedule-

Sondaki eksi işareti taint'i kaldırır. Bir düğümdeki taint'leri kubectl describe node <dugum_adi> çıktısındaki Taints satırından görürsünüz.

Kubernetes de bazı taint'leri kendi ekler: kubeadm kümelerinde control plane düğümleri varsayılan olarak control-plane taint'i taşır ve bu yüzden normal iş yükleri orada çalışmaz. Düğüm hazır değilse ya da ulaşılamıyorsa düğüm denetleyicisi not-ready ve unreachable taint'lerini NoExecute etkisiyle ekler.

Toleration yazımı

Toleration pod şablonunda spec.tolerations altında tanımlanır. Bir toleration, anahtar ve etki aynıysa ve ya operatör Equal iken değer de eşitse ya da operatör Exists ise taint ile eşleşir.

tolerations: - key: gpu operator: Equal value: 'true' effect: NoSchedule

Değerden bağımsız eşleşme için:

tolerations: - key: gpu operator: Exists effect: NoSchedule

Anahtarı boş bırakıp operatör Exists yazarsanız tüm taint'lere dayanıklı hâle gelir; bu, sistem düzeyindeki DaemonSet'ler gibi özel durumlar dışında tehlikelidir.

NoExecute etkisinde tolerationSeconds alanı, düğüme taint eklendikten sonra pod'un ne kadar süre bağlı kalacağını belirler. Süre dolunca pod çıkarılır; taint süre dolmadan kalkarsa pod kalır. Bu alan, geçici düğüm sorunlarında hemen tahliye etmek yerine bir süre beklemek için işe yarar.

Önemli bir ayrıntı: Kubernetes taint'leri bir filtre gibi değerlendirir. Pod'un dayanıklı olduğu taint'ler yok sayılır, geriye kalanların etkisi uygulanır.

nodeSelector ve node affinity

En basit hedefleme nodeSelector'dır: pod yalnızca listelenen etiketlerin hepsine sahip düğümlere yerleştirilir. Önce düğümü etiketlersiniz:

kubectl label nodes <dugum_adi> disk=ssd

Sonra pod şablonunda:

nodeSelector: disk: ssd

Daha anlatımlı kurallar için node affinity kullanılır. İki türü vardır: requiredDuringSchedulingIgnoredDuringExecution sert kuraldır, sağlanmazsa pod yerleşmez; preferredDuringSchedulingIgnoredDuringExecution yumuşak kuraldır, scheduler öncelik verir ama zorunlu tutmaz. İsimdeki IgnoredDuringExecution, pod çalışırken düğüm etiketi değişirse pod'un yerinde kalacağını söyler.

affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - <bolge_a> - <bolge_b> preferredDuringSchedulingIgnoredDuringExecution: - weight: <agirlik> preference: matchExpressions: - key: disk operator: In values: - ssd

Operatörler: In, NotIn, Exists, DoesNotExist, Gt ve Lt. NotIn ve DoesNotExist ile 'şu etikete sahip düğümden uzak dur' kuralı yazılır. Hem nodeSelector hem node affinity yazarsanız ikisi de sağlanmalıdır.

Pod affinity ve anti-affinity

Pod affinity, yerleşimi düğüm etiketlerine değil, düğümde zaten çalışan diğer pod'ların etiketlerine göre belirler. topologyKey, 'aynı yer' tanımını verir: aynı düğüm için kubernetes.io/hostname, aynı bölge için topology.kubernetes.io/zone kullanılır.

Tipik kullanımlar:

• Affinity: uygulama ile önbellek pod'unun aynı düğümde ya da aynı bölgede olması istenir, ağ gecikmesi düşer
• Anti-affinity: aynı Deployment'ın kopyalarının farklı düğümlere dağıtılması istenir, tek düğüm arızasında tüm kopyalar birden gitmez

podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: web topologyKey: kubernetes.io/hostname

Bu kural, app=web etiketli pod'ların ikisinin aynı düğümde bulunmasını yasaklar. Sert anti-affinity, düğüm sayısı kopya sayısından azsa pod'ları Pending bırakır; bu yüzden birçok ekip yumuşak sürümü ya da topologySpreadConstraints alanını tercih eder. Topoloji yayma kısıtları, kopyaları bölgeler ve düğümler arasında dengeli dağıtmak için daha doğal bir araçtır.

Hangi durumda hangisi? Örnek senaryolar ve hatalar

Örneğin ekip, yalnızca yapay öğrenme iş yüklerinin kullanacağı pahalı donanımlı düğümler ayırmak istiyor. Doğru kurgu: düğümlere hem etiket hem taint eklenir; iş yükü pod'larına hem nodeSelector (ya da node affinity) hem toleration yazılır. Yalnız taint yazılırsa başka bir pod'un da toleration verip oraya girmesi önlenmemiştir; yalnız etiket yazılırsa diğer pod'lar o düğümlere dolar.

Sık hatalar:

• Toleration'ın yerleşimi garanti ettiğini sanmak; toleration yalnız izin verir
• Sert anti-affinity yüzünden pod'ların Pending kalması; kubectl describe pod çıktısındaki olay mesajı hangi kuralın tutmadığını söyler
• spec.nodeName yazarak scheduler'ı atlamak; NoSchedule taint'i yok sayılır ama NoExecute taint'i kubelet tarafından yine uygulanır
• Etiket anahtarlarında yazım hatası; kural sessizce hiçbir düğümle eşleşmez
• Güvenlik amaçlı yalıtım için kubelet'in değiştirebildiği etiketleri kullanmak; NodeRestriction ön ekli etiketler bu iş içindir

Sorun giderirken sırayla bakın: pod olayları, düğüm etiketleri ve taint'ler, ardından kaynak talepleri.

Mindset programlarında bu beceri nerede çalışılır?

Kubernetes Scheduler ve Kaynak Yönetimi İncelikleri eğitimi, kapasiteyi ve pod yerleşimini bilinçli yönetmek zorunda olan platform mühendisleri ve SRE ekipleri için uygundur. Müfredatta Node Seçimi ve Affinity Kuralları ile Taint, Toleration ve Özel Donanım modülleri doğrudan bu sayfadaki konuyu işler; Öncelik, Preemption ve Tahliye modülü ise kaynak yetersizliğinde hangi pod'un öne geçeceğini ele alır.

Kubernetes Administrator (CKA) Hazırlık eğitimi ise iş yükü yönetimini sınav bağlamında çalıştırır. Kurumsal ekipler için kazanım, ortak düğüm havuzlarında ekipler arası kaynak çatışmasını kural düzeyinde çözebilmektir.