Kubernetes PriorityClass preemption'ı, PDB'lere rağmen güvenlik pod'larını evacuate edebiliyor

Preemption düşük öncelikli pod'ları nasıl hedef alır

Kubernetes'in PriorityClass API'si bir ismi bir tamsayıya eşler ve bu tamsayı güvenilirliği değil, scheduling sırasını belirler. dev.to'da yer alan bir yazıya göre cluster kapasitesi yetersiz kaldığında scheduler, daha yüksek değerli bir pod'u kabul edebilmek için daha düşük değerli pod'ları evacuate edebiliyor. Bu mekanizma iyi nedenlerle var — öncelikli servisler veya kritik job'lar gibi hızlı başlaması gereken iş yükleri için — ama mekanizmada harcanabilir iş yüklerini koruyucu olanlardan ayıran hiçbir şey yok. Orta düzeyde bir priority değerine sahip bir logging collector, admission controller, policy agent'ı veya olay müdahale aracı, herhangi bir batch job kadar evacuate edilmeye uygun.

Yazı, Kubernetes dokümantasyonunun kendisinden bir uyarıya atıf yapıyor: her kullanıcının güvenilir olmadığı cluster'larda yüksek öncelikli pod oluştabilen herkes diğer iş yüklerini aksatabilir.

Yaygın bir varsayım, PodDisruptionBudget'ın kritik pod'ları bu akibetten koruduğudur. Korumuyor. dev.to yazısının açıkladığı gibi, scheduler preemption sırasında PDB'lere yalnızca best-effort esasına göre danışıyor ve budget'ı karşılayan kurbanlar bulamazsa korumalı pod'ları yine de preempt ediyor.

Namespace korumaları neden işe yaramıyor

PriorityClass objeleri cluster düzeyinde yaşar, dolayısıyla etki alanı tek bir namespace'in çok ötesine uzanır. Bir iş yükü priorityClassName belirtmediğinde default class uygulanır; açık bir referans ise o class'ın değerini alır. Scheduler'daki kurban seçimi önceliğe göre yapılır ve kubelet'in node-pressure eviction'ı da kaynak kullanımı ve Quality of Service sınıfının yanı sıra önceliği dikkate alır.

Yazıya göre pratik sonuç şudur: bir namespace sıkı kısıtlı görünürken içindeki bir iş yükü riskli, cluster geneli bir class seçebilir. Bir service account, yüksek öncelikli bir template'i devralan job'lar başlatabilir. Bir ResourceQuota kaç pod'un çalışacağını sınırlar ama bunlardan birinin preempt eden bir class taşımasını engellemez.

Hata senaryosunu güvenli biçimde test etmek

Yazı, bir üretim olayını beklemek yerine aşamalı bir provayı öneriyor.

Üretim admission policy'lerini ve node pool yapılandırmasını yansıtan, üretim dışı bir cluster veya namespace kurun. Güvenlik agent'larına, DNS'e, ingress'e, logging'e ve her uygulama katmanına atanmış priority değerlerini envanterleyin. preemptionPolicy: Never ile yapılandırılmış bir test pod'u gönderin ve hiçbir şeyi evacuate etmeden kuyrukta beklediğini doğrulayın. Ancak bundan sonra, test ortamında gerçekten preempt eden bir class ile bir pod çalıştırın ve ardından ne olduğunu gözlemleyin: scheduler event'leri, PDB davranışı, restart policy'leri ve telemetrinin kesilip kesilmediği.

Bu çalışmanın yanı sıra yazar; ResourceQuota, RBAC, admission policy ve default PriorityClass'ı ayrı ayrı değil bir bütün olarak incelemeyi; kubectl get priorityclass ile class'ları listelemeyi; ve iş yükü template'lerinde açık priority referanslarını taramayı öneriyor. Ekipler ayrıca preemption event'lerine ve güvenlik servislerinin beklenen replica sayısındaki düşüşlere alarm koymalı.

Daha güvenli bir yapılandırma nasıl görünür

Yazının önerdiği sağlamlaştırma adımları şunlar: ayrıcalıklı class'ları oluşturabilen veya referans verebilen kimlikleri kısıtlamak; üretim iş yüklerinin bir default'u devralmak yerine class'larını açıkça belirtmesini zorunlu kılmak; ve güvenlik altyapısını, arıza kapasitesi ayrı olarak budget'lanmış node'larda veya iş yüklerinde çalıştırmak. Operator'lar ayrıca yüksek öncelikli bir iş yükü tekrarlanan eviction'lar tetiklerken control plane'in kanıt toplamaya devam edebildiğini doğrulamalı.

Çerçeveleme, mekanik kadar önemli. Bir priority değeri, sorumlu bir sahibi bulunan bir erişilebilirlik gereksinimini ifade etmelidir — yüksek erişilebilirliğin, scheduling kısıtlarının veya korunmuş ağ yollarının yerine geçmez. Bir iş yükünün önceliğini yükseltebilen herkes, aslında kapasite tükendiğinde hangi koruyucu kontrollerin ilk feda edileceğine karar veriyor demektir.

Neden önemli

Preemption doğası gereği sessizdir: scheduler bir kaynak kıtlığını çözer ve bir event yayınlar, ama kaldırdığı iş yükleri çoğu zaman operator'ların bir olay sırasında en çok ihtiyaç duyduğu iş yükleridir. Node baskısı tam yaşandığı anda logging, policy enforcement veya monitoring kaybetmek, hem koruma bariyerlerini hem de müdahale için gerekli kanıtları ortadan kaldırır. PriorityClass cluster düzeyinde olduğu ve namespace düzeyindeki kotalara görünmediği için bu hata senaryosu, başka türlü incelemeyi geçen cluster'larda var olmaya devam edebilir. Kısa bir denetim — class'ları saymak, oluşturulmaları ve kullanımları üzerinden RBAC'ı sıkılaştırmak ve eviction yolunu preemptionPolicy: Never ile provlamak — geleneksel policy kontrollerinin rutin olarak gözden kaçırdığı bir boşluğu kapatır.