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.
İlk okuyunca ben de kendi kendime “hah, cesur iş” dedim. Çünkü production’ın göbeğinde duran, release pipeline’ını sırtlayan bir aracı yeniden yazmak öyle dışarıdan bakınca kolay görünmüyor; dokunmaya kalksanız bir yerden ses geliyor. Geçen yıl bir finans kuruluşunda buna benzer bir modernizasyon işiyle uğraşmıştık: hayatı bir deployment aracına el atmamız gerekiyordu, ekipten kimse ilk adımı atmak istemiyordu. “Çalışıyorsa kurcalama” refleksi yani. E peki, sonuç ne oldu? Neyse, Kubernetes tarafı bu duvarı aşmış ve sonuç da baya iş görmüş.
Bir dakika — bununla bitmedi.
kpromo Nedir, Neden Bu Kadar Baş Ağrıtıyor?
registry.k8s.io’dan çektiğiniz container imajlarının oraya ulaşmasında kpromo’nun eli var. Araç, staging registry’lerden production’a imajları kopyalıyor, cosign ile imzalıyor, 20’den fazla bölgesel mirror’a dağıtıyor ve SLSA provenance attestation’ları üretiyor. Yani şey… Kubernetes’in lojistik ekibi gibi; görünmüyor ama ortadan kalksa herkes bunu hemen hisseder.
Şahsen, Eh, hikâye 2018’in sonlarına gidiyor. Linus Arver, Google içinde manuel yürüyen ve Google çalışanlarına bağımlı olan imaj kopyalama işini topluluk merkezli bir GitOps akışına çevirmek için projeyi başlatıyor — dürüst olayım, biraz hayal kırıklığı —. Mantık basit: staging registry’ye push et, YAML manifest ile PR aç, review al, merge et, gerisini otomasyon halletsin. KEP-1734 ile bu fikir resmileşiyor. Basit dedim ama işin içine girince pek de basit değilmiş, onu da söyleyeyim.
Hmm, bunu nasıl anlatsamdı…
Sonra proje büyüyor, hâliyle karmaşa da geliyor (ciddiyim). Stephen Augustus birden fazla aracı (cip, gh2gcs, krel promote-images, promobot-files) tek bir CLI altında toplayıp kpromo adıyla birleştiriyor. Adolfo Garcia Veytia cosign imzalama ve SBOM desteği ekliyor. Tyler Ferrara güvenlik açığı taramasını getiriyor. Carlos Panato ise projeyi ayakta tutuyor, release edilebilir hâlde bırakıyor. Toplamda 42 katkıcı, yaklaşık 3.500 commit ve 60’tan fazla release var; hani öyle kenarda köşede kalmış bir araç değil.
Şimdi gelelim işin can alıcı noktasına.
Yedi Yılda Biriken O Tanıdık Kargaşa
İtiraf edeyim, Ama işte burada can sıkıcı taraf başlıyor: yedi yıl boyunca farklı SIG’lerden. Alt projelerden gelen katkılarla kod tabanı ağırlaşıyor. README’de bunu saklamamışlar bile: (ki bu çoğu kişinin gözünden kaçıyor)
“Tekrarlanan kod, aynı işi yapmanın birden fazla yöntemi ve bir sürü TODO göreceksiniz.”
Aslında — hayır dur, daha doğrusu bu cümle tek başına yeterli. Proje kendi derdini açık açık anlatıyor. Ben böyle sahneleri danışmanlık projelerinde sık görüyorum; özellikle beş yılı geçmiş sistemlerde teknik borç öyle birikiyor ki yeni özellik eklemek bazen mevcut kodu anlamaktan daha kısa sürüyor. Trajikomik biraz.
Somut Dertler
Production promotion job’ları düzenli olarak 30 dakikayı geçiyordu. Rate limit hataları yüzünden pat diye fail oluyorlardı (kendi tecrübem). Core promotion mantığı test edilmesi zor tek parça bir monolite dönmüştü. Provenance ya da güvenlik taraması gibi yeni şeyler eklemek ise işe açık konuşayım epey sınır bozucu hâle gelmişti.
Çok konuştum, örnekle göstereyim.
SIG Release yol haritasında iki konu uzun süre beklemişti: “Artifact promoter’ı yeniden yaz”. “Artifact doğrulamayı daha sağlam hâle getir.” KubeCon oturumlarında ve SIG Release toplantılarında bunlar defalarca konuşulmuştu; proje board #171 üzerinde de sekiz tane araştırma sorusu cevap bekliyordu.
Peki Yeniden Yazım Nasıl Yapılmış?
Şubat 2026’da issue #1701 açılıyor: “Artifact promoter pipeline’ını yeniden yaz.” Sekiz sorunun tamamı tek tracking issue içinde toparlanıyor. Beni en çok çarpan detay şu oldu — işi tek seferde gömmemişler; yeniden yazımı bilinçli olarak fazlara bölmüşlerdi. Her adımın ayrı ayrı review edilebilmesi, merge edilebilmesi ve doğrulanabilmesi hedeflenmiş.
Şöyle ki, Şöyle ki, bak şimdi, bu önemli nokta: 2021’de bir e-ticaret müşterisinde monolitik uygulamayı mikroservislere bölerken biz de buna benzer davranmıştık; adına “strangler fig pattern” diyorduk ama isimden çok yaklaşım işe yarıyordu aslında. Mantıklı değil mi? Büyük patlama yerine küçük parçalarla ilerlerseniz risk azalıyor, geri dönüş de kolaylaşıyor.
Ve işler burada ilginçleşiyor.
Fazların Özeti
| Faz | Konu | Ne Yapıldı? | PR |
|---|---|---|---|
| 1 | Rate Limiting | Tüm registry işlemlerinde adaptive backoff ile throttling | #1702 |
| 2 | Interfaces | Registry ve auth işlemleri temiz arayüzlerin arkasına alındı | #1704 |
| 3 | Pipeline Engine |
İlk fazdaki rate limiting kısmına özellikle bakın. Eski kod registry API’lerine gelişi güzel istek atıyordu; rate limit’e takılınca da dümdüz retry yapıyordu — exponential backoff bile adam akıllı değildi yani — bence çok yerinde bir karar bu — yeni versiyon adaptive backoff kullanıyor (ciddiyim). Hata geldikçe bekleme süresi akıllıca uzuyor, pencere açılınca da tekrar hızlanıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Daha fazla bilgi için VS Live! Las Vegas 2026 İzlenmesi Gereken 20 Oturum yazımıza bakabilirsiniz.
Evet.
İkinci faz bence daha kilit bile olabilir.
Registry ve auth işlemlerini arayüzlerin arkasına almak demek test yazabilmenin önünü açmak demekti.
Eskiden gerçek registry olmadan kodu doğru düzgün test edemiyordunuz; şimdi mock ile yürütülebiliyor.
Küçük gibi duruyor ama etkisi ciddi.
Azure DevOps pipeline’larınızda da benzer şekilde servis bağımlılıklarını soyutlayarak işleri daha yönetilebilir hâle getirebilirsiniz.
Türkiye’deki Kurumsal Dünyaya Ne Söylüyor?
Bir dakika durup bunu Türkiye tarafından okuyalım biraz.
Kubernetes kullanan Türk şirketlerinin çoğu — özellikle bankacılık (ben de ilk duyduğumda şaşırmıştım). Telekom tarafındakiler — container imajlarını ya kendi private registry’lerinden ya da Azure Container Registry (ACR) gibi managed servislerden çekiyor.
registry.k8s.io’dan doğrudan çeken kurumsal müşteri sayısı az değil ama çoğu zaten mirror kullanmayı tercih ediyor.
Ha bu arada kpromo’nun yeniden yazımı sizi birebir etkilememiş olabilir.
Ama yaklaşımın kendisi önemli; fazlı yeniden yazım, sıfır downtime hedefi.
Geriye dönük uyumluluk gibi şeyleri kendi projelerinize taşıyabilirsiniz.
Geçen ay bir telekomda tam bunu tartıştık mesela; adam diyor ki “monolitik CI/CD pipeline’ımız var, tek Jenkins job her şeyi yapıyor, dokunmaya korkuyoruz.”
Ben de dedim ki bakın Kubernetes ekibi yedi yıllık can alıcı aracı yeniden yazdı.
Kimse fark etmedi; sizde de olur ama strateji şart (bizzat test ettim).
Azure Local ve Armada Edge’de Egemen AI Dönemi yazımızda bu konuya da değinmiştik.
GitHub CLI ile Agent Skill Yönetimi Tam Rehber yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili VS Debugger Agent Bug Avı Artık Ajan İşi yazımıza da göz atmanızı tavsiye ederim.
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ı;
Functions" data-glossary-term="Azure Functions">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, bu konuyla ilgili Foundry Fine-Tuning Nisan Güncellemesi RFT Artık Ucuz yazımıza da göz atmanızı tavsiye ederim.
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 Actions" data-glossary-term="GitHub Actions">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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments