Kubernetes v1.37 ile Node Lifecycle Conditions dönemi
Kubernetes v1.37, bir Node’un drain sürecinde olup olmadığını, bakım planlanıp planlanmadığını veya Graceful Node Shutdown işleminin sürüp sürmediğini göstermek için beş yeni Node condition türü sunuyor. Alpha seviyesindeki bu yapı, ilk aşamada çekirdek bileşenlerin davranışını değiştirmiyor. Yöneticiler ve yetkilendirilmiş kontrolcüler, Node yaşam döngüsünü ortak bir durum kanalı üzerinden izleyebiliyor.
Yeni Node lifecycle condition türleri
v1.37 ile bilinen Node condition türlerine şu beş değer ekleniyor:
- DrainInProgress: Node, yöneticinin belirlediği drain kriterlerine göre aktif olarak boşaltılıyor.
- Drained: Node, yöneticinin belirlediği drain kriterlerini karşıladı.
- MaintenancePlanned: Node’un ileride bir değişiklik veya bakım işleminden geçmesi bekleniyor.
- MaintenanceInProgress: Node üzerindeki bakım devam ediyor.
- GracefulNodeShutdownInProgress: Node üzerinde Graceful Node Shutdown sürecinin devam ettiği belirlenmiş durumda.
Bakım kavramı donanım veya yazılım dağıtımını, sorun giderme çalışmalarını, Node’un hizmetten çıkarılmasını ve hata ayıklamayı kapsayabilir. Bakımın drain gerektirip gerektirmediği, işlemin etkisine bağlı. Kubernetes yükseltmesi genellikle drain sonrasında yürütülmesi gereken bir işlem olarak değerlendirilirken kernel’e canlı yama uygulanması drain gerektirmeyebilir.
Condition durumları nasıl yorumlanmalı?
Diğer Node condition türlerinde olduğu gibi bu yaşam döngüsü condition’ları da status alanıyla gözlemlenen durumun aktif olup olmadığını bildiriyor:
- True: İlgili yaşam döngüsü durumu şu anda gözlemleniyor.
- False: İlgili yaşam döngüsü durumu şu anda gözlemlenmiyor.
- Unknown: Kubernetes, durumun aktif olup olmadığını belirleyemiyor.
reason alanı, mevcut durumun makine tarafından okunabilir ve kararlı nedenini belirtmek için kullanılmalı. message alanı ise insanlara ek açıklama sunabilir. Örneğin yetkili bir bakım kontrolcüsü, planlanan bakım penceresini MaintenancePlanned condition’ı üzerinden bildirebilir. Bu durumda status değeri True, reason değeri bakım penceresini tanımlayan kararlı bir değer, message alanı da bakımın planlandığını açıklayan bir metin olabilir.
Yaşam döngüsü durumu sona erdiğinde condition değeri False olarak ayarlanmalı veya condition kaldırılmalı. Her condition’ın sorumluluğunu hangi bileşenin üstleneceği de önceden belirlenmeli. Böylece farklı bileşenlerin aynı alanı birbiriyle çelişen bilgilerle güncellemesi önlenebilir.
Kubernetes v1.37’de ne değişiyor?
Bu sürüm, yeni adları bilinen NodeConditionType sabitleri olarak ayırıyor ve Alpha seviyesindeki NodeLifecycleConditions feature gate’ini tanıtıyor. Feature gate varsayılan olarak devre dışı.
Ancak v1.37’de bu gate’in etkisi sınırlı. Gate, bu condition’ları kimin ayarlayabileceğini kısıtlamıyor; ayrıca henüz hiçbir çekirdek Kubernetes bileşeni bu condition’ları okumuyor. Gate, ilerleyen sürümlerde condition’ları kullanması planlanan kontrolcü davranışlarının isteğe bağlı olarak etkinleştirilebilmesi için bir temel oluşturuyor.
Bu nedenle yöneticilerin condition’ları yayımlamaya başlamak için feature gate’i etkinleştirmesi gerekmiyor. İlk sürümde lifecycle condition’larını ayarlama ve temizleme sorumluluğu yöneticiye veya yönetici tarafından yetkilendirilmiş bir kontrolcüye ait.
Mevcut operasyonlarla birlikte kullanım
Bu condition’ların v1.37’deki temel işlevi operasyonel görünürlük sağlamak. Bakım otomasyonu, gelecekteki bakım penceresi planlandığında MaintenancePlanned condition’ını, çalışma başladığında da MaintenanceInProgress condition’ını yayımlayabilir. Drain otomasyonu, Pod’ları tahliye etmeye başladığında DrainInProgress condition’ını, yöneticinin belirlediği drain kriterleri karşılandığında ise Drained condition’ını ayarlayabilir.
GracefulNodeShutdownInProgress, Node üzerinde Graceful Node Shutdown sürecinin devam ettiğini bildirmek için kullanılabilir.
Önerilen yaklaşım, condition’ları durum bildirimi için kullanırken yaşam döngüsü işlemlerini mevcut mekanizmalarla yönetmeye devam etmek. Zamanlama veya tahliye davranışını değiştirmek için kubectl cordon, kubectl drain, taint’ler ve iş yüküne özel kontroller kullanılmalı. Lifecycle condition’ları ise bu işlemlerin durumunu insanlara, panolara, uyarı sistemlerine ve sinyali tüketmeyi seçen otomasyonlara bildirmeli.
Bu yaklaşım, Node’un yalnızca hazır olup olmadığını gösteren sinyallerin ötesine geçiyor. Node Readiness Controller ve Ready durumunun ötesindeki sinyaller üzerine kurulu yaklaşımlarla birlikte düşünüldüğünde Node yaşam döngüsündeki farklı durumlar daha açık biçimde ayrıştırılabilir.
Ortak yaşam döngüsü sinyali neden önemli?
Node yaşam döngüsü; kubelet, Node lifecycle controller, iş yükü kontrolcüleri, scheduler, autoscaler’lar, depolama operatörleri ve harici bakım sistemleri gibi birçok bileşeni ilgilendiriyor. Bu bileşenler bugün bir Node’da ne olduğunu çoğu zaman dolaylı sinyallerden çıkarmak zorunda. Bir kontrolcü Node readiness değerine, diğeri taint’lere, bir başkası da sonlandırılan veya eksik Pod’lara bakabiliyor. Altyapı sağlayıcıları ve operatörler de kendi label veya annotation yapılarını ekleyebiliyor.
Bu sinyaller kendi amaçları için yararlı, ancak aynı soruya yanıt vermiyor. Örneğin bir taint zamanlamayı veya tahliyeyi etkileyebilir; drain işleminin devam ettiğini ya da yöneticinin belirlediği drain kriterlerinin karşılandığını göstermez. NotReady bir Node da sorunun beklenmeyen bir arıza mı, graceful shutdown mı yoksa planlı bakım mı olduğunu tek başına açıklayamaz.
Ortak yaşam döngüsü bağlamı olmadığında, ayrı ayrı doğru çalışan bileşenler birbiriyle çelişen kararlar verebilir. Kubelet’in graceful shutdown sırasında sonlandırdığı bir Pod, DaemonSet kontrolcüsü tarafından yeniden oluşturulabilir. Yönetici tarafından kaldırılan bir Node üzerindeki terminal Pod fazını bekleyen Job kontrolcüsü süresiz olarak bekleyebilir. Depolama operatörü de bakımı ancak drain başladıktan sonra öğrenebilir.
Yeni condition’lar, eksik bağlamı Node üzerinde Kubernetes tarafından tanımlanmış ortak bir alana taşıyor. Gelecekteki bileşenler böylece aynı yaşam döngüsü durumunu kendi yöntemleriyle yeniden çıkarmak yerine ortak bir sinyali tüketebilecek.
Gelecekteki kullanım alanları
Paylaşılan sinyalin değeri, onu hangi bileşenlerin tüketeceğiyle ortaya çıkacak. İleride çekirdek kontrolcüler, yöneticiler ve ekosistemdeki yaşam döngüsü projeleri bu condition’lar üzerinden yeni davranışlar geliştirebilir.
Kaynakta verilen örneklerden biri DaemonSet dağıtımlarındaki kullanılabilirlik hesabı. Arızalı veya bakımda olan bir Node, yeni DaemonSet revizyonuyla ilgisi olmayan bir nedenle kullanılamaz durumda kalsa bile dağıtımın kullanılabilirlik bütçesini tüketebilir. Bu durum, sağlıklı Node’larda rollout sürecinin yavaşlamasına veya durmasına yol açabilir.
DaemonSet kontrolcüsü mevcut durumda Pod’un kullanılamaz olduğunu görebilir, ancak bunun yeni revizyonun başarısızlığından mı yoksa yöneticinin Node’u bilinçli olarak hizmet dışına almasından mı kaynaklandığını anlayamayabilir. MaintenanceInProgress, bu bağlamın yayımlanabileceği Kubernetes’e ait ortak bir alan sağlıyor. Bu condition’ın rollout sıralamasında, kullanılabilirlik hesabında ve durum raporlamasında nasıl kullanılacağı ise gelecekteki çalışmalarla netleşecek.
İlerleyen aşamalarda Graceful Node Shutdown, drain ve bakım senaryoları geliştirilebilir. Uzun vadeli yaşam döngüsü koordinasyonu için açık sahiplik, kilitleme ve özel bir API gibi ek mekanizmalar gerekebilir. Node Lifecycle Working Group, SIG Node ve SIG Apps bu çalışmalar için farklı ortam ve operasyon modellerindeki kullanım senaryolarını topluyor.
Kaynaklar ve İleri Okuma
- Kubernetes v1.37: Introducing Node Lifecycle Conditions
- KEP-5683: Node Lifecycle Conditions
- Kubernetes’te Node Shutdown
- Kubernetes Node Status referansı
- Taint ve toleration kavramları
- Node Lifecycle Working Group
- SIG Node
- SIG Apps
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.
4 comments