Kubernetes SIG Apps: Workload Dayanıklılığında Yeni Odak

⏱️ 5 dk okuma📅 23 Eylül 2026

Kubernetes’te bir uygulamayı ayağa kaldırmak artık tek başına konu değil; asıl mesele o uygulamanın yükseltmeler, ölçekleme olayları ve altyapı arızaları sırasında ayakta kalması. Deployment, StatefulSet, DaemonSet, Job ve CronJob gibi API’lerin sahibi olan SIG Apps, tam da bu katmanda çalışıyor. Kubernetes blogunda yayımlanan SIG Apps söyleşisi, grubun bugün hangi dayanıklılık sorunlarına odaklandığını, geriye dönük uyumluluk ile “daha doğru davranış” arasındaki gerilimi nasıl yönettiğini ve AI ile dağıtık iş yükleri için hangi yeni desenleri denediğini anlatıyor. Aşağıda bu söyleşinin teknik özeti var.

SIG Apps tam olarak neyi sahipleniyor?

SIG Apps, Kubernetes’in workload API’lerinden sorumlu Special Interest Group. CronJob ve Job batch iş yüklerini çalıştırmaya yararken; DaemonSet, Deployment, ReplicaSet ve StatefulSet diğer uygulamaların büyük bölümüne hizmet ediyor.

Söyleşide SIG Apps Co-Chair’lerinden Maciej Szulik’in tarifiyle SIG Apps, geliştiricilerin günlük olarak fiilen dokunduğu katmanın sahibi: bir workload tanımını çalışan ve kendi kendini iyileştiren pod’lara dönüştüren controller’lar. Deployment’ların nasıl rollout edileceği, Job’ların nasıl yeniden deneyeceği, DaemonSet’in her düğüme nasıl bir pod yerleştireceği bu grupta kararlaştırılıyor.

Diğer Co-Chair Janet Kuo ise rolün genişlediğini vurguluyor: dağıtık AI eğitimi, batch computing ve dinamik agent ortamları gibi klasik olmayan iş yüklerine yönelik talep arttıkça, SIG Apps yalnızca mevcut workload API’sini sürdürmüyor, aynı zamanda yeni desenler de kuruyor. Kuo, 2015’ten bu yana Kubernetes maintainer’ı olduğunu, Deployment, ReplicaSet, StatefulSet ve DaemonSet controller’larını geliştirip rollout davranışlarını tanımlayarak GA’ya taşıdığını ve 2019’dan beri SIG Apps’te Co-Chair ve Tech Lead olarak görev yaptığını söylüyor. Szulik ise Kubernetes’e 2014’te katkı vermeye başladığını; controller’lar, kubectl ve apimachinery alanlarında çalıştığını, SIG CLI Tech Lead ve Steering Committee rollerini de sürdürdüğünü belirtiyor.

Bugünün odağı: serving iş yükleri ve node lifecycle

Szulik’e göre batch iş yüklerinin Kubernetes üzerinde sorunsuz çalışmasına odaklanılan uzun bir dönemin ardından dikkat, serving iş yüklerine (DaemonSet, StatefulSet vb.) kaydı. Bu da rollout ve ölçekleme davranışında performans ile yüksek ölçek iyileştirmeleri, ayrıca kullanıcıların bildirdiği sorun birikiminin kullanıcı tabanından en çok destek gören maddelerden başlanarak ele alınması anlamına geliyor.

Dayanıklılık tarafında öne çıkan başlık ise düğüm yaşam döngüsü. Szulik, node lifecycle sorunlarının SIG Apps, SIG Node ve SIG Autoscaling tartışmalarında tekrar tekrar gündeme geldiğini anlatıyor. DaemonSet ve Job’lar, düğüm durumuna en doğrudan bağlı iş yükleri oldukları için acının en görünür olduğu yer. Bu yüzden sorunu tek bir SIG içinde parça parça çözmek yerine, konuya odaklanacak ayrı bir Node Lifecycle Working Group kurulmasına karar verilmiş; amaç tek seferlik yamalar yerine uzun vadeli çözümler üretmek.

AI iş yüklerinde tek düğüm arızasının bedeli

Kuo, dayanıklılığın AI perspektifinden kritik olduğunu söylüyor: yüzlerce GPU’ya yayılan büyük bir dağıtık LLM eğitim işinde tek bir düğüm arızası tüm hattı durdurabiliyor. Benzer biçimde logging veya GPU izleme agent’ını çalıştıran bir DaemonSet bozuk bir düğümde takılı kalırsa, bu tüm cluster’ın sağlığını etkiliyor.

Altyapı seviyesindeki bozulmayı Node Lifecycle WG ele alırken, SIG Apps aynı sorunu orkestrasyon katmanında alt projelerle çözmeye çalışıyor: dağıtık eğitim için JobSet, sharded LLM çıkarımı için LeaderWorkerSet (LWS). Bu API’ler “all-or-nothing” hata yönetimi gibi desenler getiriyor; tek bir pod veya job hatası, takılı iş yüklerinin tutarsız durumda asılı kalmasına izin vermek yerine koordineli bir grup düzeyi yeniden başlatmayı tetikleyerek son temiz checkpoint’ten devam etmeyi sağlıyor.

Üretim ekipleri için pratik karşılığı

Bu çalışmaların sahaya yansıması ne olur sorusuna Szulik, Node Lifecycle Working Group içindeki kişilerin daha net cevap vereceğini belirterek temkinli yanıt veriyor. Kendi beklentisi, “X düğümü kararsız olduğu için bir DaemonSet rollout’u takıldı ve birinin elle cordon/delete/restart yapması gerekti” ile sonuçlanan gece yarısı çağrılarının azalması.

Kuo bu beklentiye katılarak manuel müdahalenin azalmasının ötesinde kaynak öngörülebilirliği ve maliyet verimliliğinde de iyileşme beklediğini söylüyor. GPU boşta kalma süresinin son derece pahalı olduğu AI iş yüklerinde, Kubernetes’in bozulan bir düğümü otomatik tespit edip eğitim koordinatörünü veya agent’ı iş çökmeden yeniden planlaması, daha az boşa giden hesaplama ve daha kararlı iş yürütümü anlamına geliyor.

En zor ödünleşim: geriye dönük uyumluluk

Çekirdek workload controller’larını evriltirken karşılaşılan teknik ve operasyonel ödünleşimler sorulduğunda iki isim de aynı noktada buluşuyor.

Szulik’e göre tekrar eden gerilimler şunlar: bir controller takılı pod’lardan ne kadar hızlı vazgeçmeli ve bu kararı doğru verebilmek için hangi sinyallere ihtiyaç duyuyor? Aynı anda geriye dönük uyumluluğu da düşünmek gerekiyor; Deployment, DaemonSet ve Job davranışına on yıldır kullanıcılar, araçlar, otomasyonlar ve üst düzey controller’lar bağımlı. Bu nedenle açıkça “daha doğru” olan bir değişiklik bile, insanların eski davranış etrafında kurduğu otomasyonu istemeden bozabiliyor.

Kuo bunu “zarif” tasarım değişikliği yapma dürtüsüne direnmek olarak tanımlıyor. Bunun yerine, kullanıcıların yeni davranışları eski iş yüklerine zorlamadan benimseyebileceği opt-in özellikler tasarlanıyor. Tamamen yeni paradigmalar gerektiğinde ise çekirdek API’leri şişirmek yerine önce CRD olarak sunmak tercih ediliyor; Agent Sandbox, JobSet ve LWS bu yaklaşımın örnekleri.

KEP-4443: Job hata nedenlerini ayırt edilebilir kılmak

Söyleşide ele alınan somut başlıklardan biri, hedef sürüm olarak Kubernetes 1.38 konuşulan KEP-4443. Bu KEP, Job API’sindeki küçük ama gerçek bir boşluğu kapatıyor: bir PodFailurePolicy, JobFailed koşuluna bir condition reason ekleyecek şekilde yapılandırılabiliyor; ancak farklı container çıkış kodlarını hedefleyen farklı pod failure policy kuralları aynı genel reason değerini üretiyor.

Öneri basit: her PodFailurePolicyRule üzerinde opsiyonel bir Name alanı bulunacak ve bu alan JobFailed koşulunun reason değerine eklenecek. Böylece JobSet gibi üst düzey araçlar, hatayı hangi kuralın tetiklediğine göre farklı tepki verebilecek.

Zamanlamaya gelince, Szulik’in yanıtı açık sözlü: bu çalışmayı yürüten ilk katkıcı kaybedilmişti; şimdi konuyu devralmak isteyen yeni biri çıktığı için bir sonraki sürüm hedefleniyor.

Katkıya nereden başlanır?

Kubernetes maintainer’ı olmadan SIG Apps’e katkı vermek isteyenler için iki farklı giriş noktası öneriliyor.

Topluluk kanalları: Szulik’e göre başlangıç için en iyi yer #sig-apps Slack kanalı ve düzenli SIG Apps toplantıları. Ürkütücü gelmesi ya da ilk mesaja hemen yanıt gelmemesi tamamen normal; herkes meşgul, kişisel bir durum değil.
Yeni alt projeler: Kuo, Deployment veya StatefulSet gibi kararlı API’lere katkı vermenin geriye dönük uyumluluk nedeniyle çıtayı çok yükselttiğini ve kolay iş sayısının az olduğunu hatırlatıyor. Topluluğa yeni katılanlar için Agent Sandbox gibi aktif olarak gelişen, maintainer grubu ilgili ve greenfield geliştirme fırsatı sunan projeleri öneriyor.

Özetle

SIG Apps, projenin ilk günlerinden bu yana Kubernetes uygulamalarının nasıl dağıtıldığını ve işletildiğini şekillendiriyor. Kullanıcılar çoğu zaman Deployment, StatefulSet, Job ve DaemonSet ile arkadaki controller’ları düşünmeden çalışsa da, bu grubun kararları ekosistem genelinde iş yüklerinin güvenilirliğini ve ölçeklenebilirliğini doğrudan belirliyor. Workload dayanıklılığı ve node lifecycle davranışının iyileştirilmesinden AI ile dağıtık hesaplamaya yönelik yeni desenlere kadar uzanan gündem, projenin temel ilkelerinden biriyle birlikte yürütülüyor: kullanıcıların bağımlı olduğu kararlılığı ve geriye dönük uyumluluğu korumak.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102