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ı araç olan kpromo’yu baştan yazmışlar; kodun yüzde 20’sını çö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 yanı. E peki, sonuç ne öldü? Neyse, Kubernetes tarafı bu duvarı aşmış ve sonuç da baya iş görmüş.
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. SLSA provenance attestation’ları üretiyor. Yanı şey… Kubernetes’in lojistik ekibi gibi; görünmüyor ama ortadan kalksa herkes bunu hemen hisseder.
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. 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ş, önü da söyleyeyim.
Sonra proje büyüyor, hâliyle karmaşa da geliyor. 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 işe 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
Ama işte burada can sıkıcı taraf başlıyor: yedi yıl boyunca farklı SIĞ’lerden ve alt projelerden gelen katkılarla kod tabanı ağırlaşıyor. README’de bunu saklamamışlar bile:
“Tekrarlanan kod, aynı işi yapmanın birden fazla yöntemi ve bir sürü TODO göreceksiniz.”
Aslında 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ı. Core promotion mantığı test edilmesi zor tek parça bir monolite dönmüştü. Provenance ya da güvenlik taraması gibi yeni şeyler eklemek işe açık konuşayım, epey sınır bozucu hâle gelmişti.
SIĞ Release yol haritasında iki konu uzun süre beklemişti: “Artifact promoter’ı yeniden yaz” ve “Artifact doğrulamayı daha sağlam hâle getir.” KubeCon oturumlarında ve SIĞ 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 işe şu öldü — işi tek seferde gömmemişler; yeniden yazımı bilinçli olarak fazlara bölmüşler. Her adımın ayrı ayrı review edilebilmesi, merge edilebilmesi ve doğrulanabilmesi hedeflenmiş.
Şöyle ki, Bak şimdi, bu önemli nokta. 2021’de bir e-ticaret müşterisinde monolitik — ki bu tartışılır — 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. Büyük patlama yerine küçük parçalarla ilerlerseniz risk azalıyor, geri dönüş de kolaylaşıyor.
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 yanı — bence çok yerinde bir karar —. 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.
İnanın, İ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 dürüyor ama etkisi ciddi.
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 ve 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, 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, süreç meselesi de oluyor bazen 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
Küçük bir detay: “E ne var yanı, sil gitsin” diyebilirsiniz belki ama production’daki kodun yüzde 20’sını silmek öyle hop diye olmuyor (evet, doğru duydunuz). 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. 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çirmeu yenisiyle değiştiriyorsun, en son artık referans edilmeyen kodu temizliyorsun; sıra gerçekten önemliymiş meğersem. Tersi olursa yanı önce silmeye girişirseniz işler hızlıca karışır.
Performans Tarafında Gerçekten Ne Öldü?
Eh, 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 dürüyor ama 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, yanı 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ı
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 tabii : 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. Kubernetes topluluğu bunu fena yönetmemiş gibi dürüyor ama her açık kaynak projesi aynı şansa sahip değil, önü 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: Dış bağımlılıkları interface katmanının arkasına alın; test edilebilirlik belirgin şekilde artar. (bence en önemlisi)
- Rate limiting’i ciddiye alın: Registry veya API ile konuşan kodlarda adaptive backoff kullanın.
- Dead code’u acımasızca silin: Ama önce interface katmanını çıkarın, sonra yeni implementasyonu koyun, en son eski kodu temizleyin ; sıra burada kritik.
- “Kimse fark etmesin” prensibi: Production’daki değişikliğin en iyi hali çoğu zaman kullanıcıya hissettirmeyendir.
Eğer Azure DevOps ya da GitHub Actions kullanıyorsanız ve pipeline’larınız şişmeye başladıysa — ki iki yılı geçen her pipeline biraz şişer, bu doğanın kanunu gibi — geri çekilip “burada interface ayırabilir mıyım?” diye sormakta fayda var. GitHub’da Deployment Context Repo ve Alert Yönetimi, deployment süreçlerini nasıl daha yönetilebilir hâle getirebileceğinize dair iyi örnekler içeriyor. # Basit adaptive backoff örneği (Python pseudocode)
import time
import random
def adaptive_backoff(attempt, base_delay=1, max_delay=60):
delay = min(base_delay * (2 ** attempt), max_delay)
jitter = random.uniform(0, delay * 0_3) # %30 jitter
total = delay + jitter
print(f"Attempt {attempt}: waiting {total:.1f}s")
time.sleep(total)
return total
# Kullanım
for i in range(5):
adaptive_backoff(i)
# registry_call() burada olacak
]
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) kopyalayan, cosign ile imzalayan. 20’den fazla bölgesel mirror’a replike eden bir araç. Yanı aslında Kubernetes release sürecinin tam ortasında dürüyor — 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 — ki bu tartışılır — 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?
İ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 — valla güzel iş çıkarmışlar —. 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?
Bunu yaşayan biri olarak söyleyeyim, 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 işe container imajının hangi kaynak koddan, hangi build sistemiyle, ne zaman üretildiğini kriptografik olarak doğrulanabilir şekilde belgeliyor. Yanı aslında imajınız için bir “doğum belgesi” gibi düşünebilirsiniz. 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
Size bir şey söyleyeyim, kubernetes-sigs/promo-tools — GitHub Repository
Ne yalan söyleyeyim, SLSA Framework — Supply-chain Levels for Software Artifacts
İçeriği paylaş:
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.
Yorum gönder