Kubernetes Image Promoter Yeniden Yazıldı: Sessiz Devrim
Şöyle düşünün: her gün milyonlarca container imajı çekiliyor ve bunların arkasında tek bir araç koşturuyor, inanın bana. O araç tökezlese? Kubernetes release süreci de sendeleyip kalıyor. Nokta. İşte tam burada, o hayatı (söylemesi ayıp) araç olan kpromo’yu baştan yazmışlar; kodun yüzde 20’sini çöpe atmışlar, sistemi belirgin biçimde hızlandırmışlar ve garip olan şu ki kimse fark etmemiş. Zaten hedef de biraz buydu.
Küçük Ekip mi Büyük Enterprise mı?
Tuhaf ama eğer üç-beş kişilik bir startup’sanız açık konuşayım bu kadar katmanlı faz planına ihtiyacınız yoktur büyük ihtimalle. Direkt yeniden yazarsınız, hafta sonu deploy edersiniz, eski kodu da silersiniz gider. Ama 50+ kişilik ekiplerde işler değişiyor; aynı pipeline’ı birkaç takım kullanıyorsa fazlı yaklaşım neredeyse şart oluyor.
Azure DevOps Güvenlik Taraması Tek Tıkla Başlıyor yazımda da söylemiştim — CI/CD pipeline güvenliği sadece tool meselesi değil bazen süreç meselesi de oluyor hani.
kpromo’nun cosign imzalama ve SLSA provenance desteği de supply chain security açısından baya iş görüyor.
%20 Kod Silmek Sandığınız Kadar Kolay Değil
Şunu fark ettim: Küçük bir detay:
“E ne var yani, sil gitsin” diyebilirsiniz belki. Production’daki kodun yüzde 20’sini silmek öyle hop diye olmuyor.
Hmm… biraz düşününce anlaşılıyor aslında neden zor olduğu;
her satırın en azından bir zamanlar iyi kötü bir sebebi olmuş oluyor çünkü artık kullanılmayan şeyler bile başka yerlere dolaylı bağlı çıkabiliyor.
2023’te benzer temizlik yaptığımız bir proje vardı;
Azure Functions üstünde çalışan event processing sistemiydi bu. Kodun yaklaşık yüzde 15’i dead code çıktı ama bunu anlamak iki hafta sürdü desek abartmış olmayız sanırım. Silme kararı bir gün aldı ama test etmek üç gün sürdü. Sonuçta deployment süresi yüzde 35 düştü,
build süresi yarıya indi;
yalnız o analiz döneminde epey terlediğimi söyleyebilirim. İşte,
Kpromo ekibinin yaptığı sıranın değeri burada ortaya çıkıyor bence —
önce interface’leri çıkarıyorsun,
sonra eski hayata geçirmeyi yenisiyle değiştiriyorsun,
en son artık referans edilmeyen kodu temizliyorsun;
sıra gerçekten önemliymiş meğersem.
Tersi olursa. Önce silmeye girişirseniz işler hızlıca karışır.
Performans Tarafında Gerçekten Ne Oldu?
Bunu yaşayan biri olarak söyleyeyim, Evet,
30 dakikayı aşan promotion job’ları artık çok daha hızlı çalışıyor gibi görünüyor;
rate limit kaynaklı fail oranı da belirgin şekilde düşmüş durumda deniyor.
Ama şunu dürüstçe söyleyeyim — kaynakta “dramatically faster” denince ben hep biraz temkinli yaklaşırım.
Çünkü dramatik kelimesi herkes için başka türlü çalışıyor;
30 dakikadan 15 dakikaya inmek mi,
yoksa beş dakikaya mı?
Somut rakam verilmediği için insan ister istemez beklemede kalıyor.
Açık konuşayım,
kağıt üstünde tablo güzel duruyor (inanın bana). Asıl sınav yüksek yük altındaki uzun vadeli stabilite olacak.
Kubernetes release dönemlerinde,
özellikle minör release çıktığında,
imaj sayısı artıyor,
mirror sayısı kabarıyor,
trafik sıkışıyor;
asıl performansı o zaman anlayacağız.
Buna rağmen adaptive backoff mekanizmasının tek başına bile ciddi fark yaratmış olma ihtimali yüksek.
Eski kod rate limit’e takılınca sabit süre bekliyordu;
bu da gereksiz uzun boşluklar yaratıyordu.
Yeni sistemde bekleme dinamik,
yani registry rahatladığı anda işlem devam edebiliyor.
Kubernetes 1_36 Ön İzleme Neler Geliyor Neler Gidiyor? yazımda Kubernetes ekosistemindeki başka değişikliklere de değinmiştim.
Bu yeniden yazım da
1_36 dönemine denk geliyor
ve supply chain security açısından fena olmayan bir adım sayılır.
Beni Biraz Düşündüren Tarafı
İşin garibi, Bir şey var ki beni hafif düşündürdü doğrusu. Bu kadar can alıcı bir araç,
bu kadar büyük etraflı bir yeniden yazımdan geçti. Blog postu dışında toplulukta çok yüksek ses çıkmadı. Belki de “kimse fark etmedi” mottosu gereğinden iyi çalıştı. Çünkü böyle mühendislik işleri biraz daha görünür olmayı hak ediyor bence;
yoksa emek gölgede kalıyor. Bir de sosyal tarafı var tabi:
42 katkıcının emeği üzerine yapılan rewrite hassas konuya dönüşebiliyor. Yıllar önce yazılmış kodu silmek teknik olarak doğru olsa bile insan ilişkileri açısından dikkat istiyor. Neden önemli bu? Kubernetes topluluğu bunu fena yönetmemiş gibi duruyor ama her açık kaynak projesi aynı şansa sahip değil,
onu da unutmamak lazım.
Kendi Pipeline’ın İçin Alabileceğin Dersler
Lafı gevelemeden söyleyeyim — bu rewrite’tan çıkarabileceğiniz birkaç somut ders var:
- Fazlı yaklaşım: Büyük değişiklikleri küçük ve bağımsız PR’lara bölün; her biri tek başına merge edilebilir olsun.
- Önce arayüzleri çıkarın:
}
Sıkça Sorulan Sorular
kpromo ne işe yarar?
kpromo (Kubernetes image promoter), container imajlarını staging registry’lerden production’a (registry.k8s.io) kopyalıyor, cosign ile imzalıyor. 20’den fazla bölgesel mirror’a replike ediyor. Yani aslında Kubernetes release sürecinin tam kalbinde duruyor — bu araç çalışmazsa yeni Kubernetes sürümü yayınlanamıyor. Bence bu kadar kritik bir araç olduğunu çoğu kişi fark etmiyor bile.
Bu yeniden yazım mevcut Kubernetes kullanıcılarını etkiler mi?
Hayır, doğrudan etkilemiyor. Yeniden yazım büyük ölçüde geriye dönük uyumlu şekilde yapılmış. registry.k8s.io’dan imaj çekmeye devam edebilirsiniz, hiçbir şey değişmedi. Zaten amaç da tam olarak buydu — kullanıcının fark etmemesi. Açıkçası, “kimsenin fark etmediği değişiklik” bence en başarılı değişikliktir.
Adaptive backoff nedir ve neden önemlidir?
Kısaca şöyle açıklayayım: bir servisten hata aldığınızda bekleme süresini dinamik olarak artıran bir strateji. Sabit bekleme yerine, hata sayısına göre üstel olarak artan bir gecikme uyguluyor. Böylelikle hem servisi boğmuyorsunuz hem de gereksiz yere uzun beklemiyorsunuz. Tecrübeme göre bu tür küçük detaylar, yük altında sistemin ayakta kalıp kalmayacağını belirliyor.
Kendi CI/CD pipeline’ıma bu yaklaşımı nasıl uygulayabilirim?
Vallahi, İlk adım olarak dış bağımlılıklarınızı — mesela registry, API çağrıları, auth servisleri — interface’lerin arkasına alın. Sonra her fazı ayrı bir PR olarak gönderin. Son olarak kullanılmayan kodu temizleyin. Azure DevOps veya GitHub Actions’ta bu yaklaşım, hani pipeline sürenizi ve bakım maliyetinizi ciddi şekilde düşürüyor.
SLSA provenance attestation ne demek?
SLSA (Supply-chain Levels for Software Artifacts), bir yazılımın nereden geldiğini ve nasıl build edildiğini kanıtlayan bir framework. Provenance attestation ise container imajının hangi kaynak koddan, hangi build sistemiyle, ne zaman üretildiğini kriptografik olarak doğrulanabilir şekilde belgeliyor. Yani aslında imajınız için bir “doğum belgesi” gibi düşünebilirsiniz. Bu ne anlama geliyor? Supply chain saldırılarının bu kadar yaygınlaştığı bir dönemde bence bu tür mekanizmalar artık lüks değil, zorunluluk.
Kaynaklar ve İleri Okuma
The Invisible Rewrite: Modernizing the Kubernetes Image Promoter — Kubernetes Blog
kubernetes-sigs/promo-tools — GitHub Repository
SLSA Framework — Supply-chain Levels for Software Artifacts
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.
3 comments