Kubernetes topluluğu, kümelerin değil doğrudan iş yüklerinin çalışma zamanı davranışını tanımlayan bir standart üzerinde çalışmaya başladı. Yeni kurulan Workload Conformance Working Group, bir uygulamanın Kubernetes üzerinde nasıl davranması gerektiğini ortak bir spesifikasyona bağlamak ve bu gereksinimleri tekrarlanabilir testlerle ölçmek istiyor. Böylece küme operatörleri her bakım penceresinden önce uygulamaları tek tek elden geçirmeyecek, uygulama bakımcıları da destekledikleri her ortamda aynı soruları baştan yanıtlamak zorunda kalmayacak.
Neden iş yükleri için ayrı bir standart gerekiyor?
Bugün Kubernetes ekosistemindeki uyumluluk testleri kümeyi hedefliyor. Certified Kubernetes programı kümenin kendisini sınıyor, Kubernetes AI Conformance ise bir kümenin yapay zeka ve makine öğrenmesi iş yüklerini çalıştırmaya uygun olup olmadığını ölçüyor. İş yüklerinin kendisi için benzer bir mekanizma yok.
Bu boşluğun sonuçları operasyon tarafında tanıdık:
- Rutin bir node drain işlemi, çoğu zaman bir uygulamanın kesintiye dayanamadığını ortaya çıkaran an oluyor.
- Bir yükseltme, hala kaldırılmış bir API sürümüne bağımlı olan uygulamayı bozabiliyor.
- Günlük işleyişte ise ihtiyacı olmayan ayrıcalıkları isteyen ya da hiç kullanmadığı kaynakları rezerve eden iş yükleri çıkıyor.
Kubernetes dokümantasyonu bu konuların önemli bir bölümünü zaten kapsıyor, güvenlik ve kesintilerin ele alınması başlıkları bunun örneği. Yine de her küme operatörü aynı değerlendirmeyi kendi başına tekrarlıyor. Ortak bir spesifikasyon ve ona eşlik eden testler iki tarafa da aynı başlangıç çizgisini verecek.
Çalışma grubunun üreteceği üç çıktı
Grubun charter belgesi üç somut teslimat tanımlıyor:
- Her Kubernetes minor sürümü için iş yükü davranışını tanımlayan bir spesifikasyon.
- Her bir gereksinimin, çalışan bir iş yükü üzerinde nasıl test edileceğini belirleyen bir yöntem.
- Bu testleri hayata geçiren upstream conformance araçları.
İlk iş, spesifikasyonun hangi iş yüklerini ve hangi davranışları kapsayacağına karar vermek. Belirlenen kapsam alanları arasında güvenlik, kesintiler sırasındaki dayanıklılık, kaynak kullanımı, ağ, depolama, API kullanımı ve gözlemlenebilirlik var. Grup, bu alanlardaki belirli gereksinimler ve bunların nasıl test edileceği konusunda henüz uzlaşmış değil.
Daha baştan netleşen kurallar
Kapsam tartışması sürüyor ama bazı sınırlar şimdiden çizilmiş durumda:
- Her gereksinim objektif bir teste bağlanacak. Bir test ikilisinin (test binary) çalıştırabileceği ölçülebilir bir karşılığı yoksa madde spesifikasyona girmeyecek, öznel ifadeler böylece dışarıda kalacak.
- Spesifikasyon, iş yükünün nasıl çalıştığını tanımlar, ne yaptığını değil. Uygulama mantığı workload conformance kapsamı dışında kalıyor.
- Tekrar yok. Test aracı, Certified Kubernetes kapsamında zaten sınanan şeyleri yeniden test etmeyecek.
- Belirli bir paketleme biçimi veya satıcı aracı dayatılmayacak. Politika motoru, güvenlik tarayıcı gibi özel araçlar zorunlu tutulmuyor.
Grubun organizasyonu ve zaman ölçeği
Çalışma grubunun iki sponsor SIG’i var. SIG Architecture spesifikasyonu ve araçları bir subproject üzerinden sahiplenecek; bu subproject, çalışma grubu ilk çıktıları önerdiğinde oluşturulacak. SIG Apps ise uygulama perspektifini masaya taşıyacak.
Bir gereksinim node davranışı ya da ağ gibi başka bir SIG’in alanına dokunduğunda, çalışma grubu ilgili SIG’lerle görüşmeyi kendisi başlatacak. Grup kendini, spesifikasyon yazılırken SIG’lerin sürece dahil olup yönü şekillendirebileceği bir forum olarak konumlandırıyor.
Hedef, iki ila üç Kubernetes sürüm döngüsü içinde kararlı bir ilk spesifikasyona ve çalışır testlere ulaşmak.
Katkı vermenin yolları
Spesifikasyonun gerçek örneklerden inşa edilmesi gerekiyor, grup da bu yüzden saha deneyimlerini açıkça istiyor:
- Küme işletiyorsanız: iş yüklerini bugün nasıl değerlendirdiğinizi ve son yükseltme ya da bakım pencerenizde neyin bozulduğunu paylaşın.
- Uygulama bakımcısıysanız: uygulamanızın kümeden tam olarak neye ihtiyaç duyduğunu ve mevcut rehberliğin sizi nerede belirsizlikte bıraktığını anlatın.
- İnceleyici veya katkıcı olarak: önerilen gereksinimleri gözden geçirebilir, testleri ve araçları yazabilirsiniz.
- Erken test edici olarak: testlerin ilk sürümleri hazır olduğunda ikiliyi kendi iş yüklerinize karşı çalıştırıp sonuçların çalıştırmalar veya ortamlar arasında nerede farklılaştığını bildirebilirsiniz.
- SIG temsilcisiyseniz: alanınıza dokunan bir gereksinimin kapsamını ve arkasındaki testi doğrulamaya yardımcı olabilirsiniz.
- Uzun vadeli bakım için: subproject çalışma grubundan daha uzun ömürlü olacağı için, onu sürdürecek kişiler aranıyor.
İletişim kanalları Kubernetes Slack üzerindeki #wg-workload-conformance kanalı ve grubun e-posta listesi. Toplantılar iki haftada bir çarşamba günleri 15:00 UTC’de yapılıyor, Zoom bağlantısı ve gündem toplantı notlarında duruyor. Gündeme konu eklemek isteyen doğrudan notlara yazabiliyor; e-posta listesine katılmak ise genellikle toplantı davetini takviminize ekliyor. Kanalların güncel bağlantıları çalışma grubunun kubernetes.dev sayfasında.
Kaynaklar ve İleri Okuma
- Announcing the Workload Conformance Working Group (Kubernetes Blog)
- WG Workload Conformance — topluluk sayfası
- Çalışma grubu charter belgesi
- Kubernetes Workloads dokümantasyonu
- Kubernetes AI Conformance: AI İş Yüklerinde Standart
- Kubernetes SIG Apps: Workload Dayanıklılığında Yeni Odak
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.
