Şu an saat gece on biri geçiyor, ben de release notlarını karıştırırken gözüme bir şey çarptı: Mixed Version Proxy nihayet Beta olmuş. Hatırlayanlar vardır, bu özellik ilk kez 1.28 ile alpha olarak gelmişti. O zaman bir müşteride test ortamında denemiştik, açık konuşayım, biraz hamdı. Şimdi 1.36 ile birlikte default açık geliyor, yanı siz hiç dokunmasanız bile devrede olacak. Bu baya önemli bir eşik.
Açık konuşayım: cluster upgrade yapan herkesin başına o meşhur 404 Not Found hikâyesi gelmiştir. HA kontrol düzleminde API sunucularından biri yeni sürüme geçmişken, eski sürümden gelen istek “ben bunu tanımıyorum” deyip 404 dönerse controller’lar afallıyor. Garbage collector kendi bir düşüneyim… kafasına göre yorum yapıyor, namespace silme işleri tıkanıyor. Kötü tarafı şu: log’a bakınca sebep çoğu zaman net görünmüyor. Saat üçte upgrade penceresinde böyle bir şey çıkarsa, sabaha kadar uyku yok. Bu ne anlama geliyor? Evet, aynen öyle.
Önce Şu Sorunu Bir Oturtalım
Bakın, Kubernetes kontrol düzlemini upgrade ederken, özellikle prod ortamlarda, API sunucularını tek tek yenilersiniz. Bu sırada bazı sunucular eski sürümde kalır, bazıları yeni sürümde çalışır; işte asıl karışıklık da burada başlıyor. Diyelim ki yeni sürümde v2 bir API kaynağı geldi. Client istek attı, load balancer önü eski API sunucusuna yönlendirdi, eski sunucu da “ben böyle bir kaynak tanımıyorum kardeşim” deyip 404 basıyor.
Halbuki kaynak cluster’da var. Sadece o spesifik sunucuda yok. Teknik olarak cevap yanlış kalıyor; hatta dürüst olayım, 503 Service Unavailable bile olsaydı controller’lar retry yapabilirdi belki. Ama 404 deyince iş bitiyor, “kaynak yoksa sil gitsin” mantığı devreye giriyor (inanın bana). Kısacası küçük görünen hata, zinciri komple bozuyor.
Kısa bir not düşeyim buraya.
Mixed Version Proxy (MVP) tam bu noktada devreye giriyor. İsteği alan sunucu “ben bunu servis edemem ama bunu bilen bir peer var” deyip isteği ona proxy’liyor; cevap dönünce de client’a iletiyor. Client bu trafikten habersiz kalıyor. Güzel numara.
Bir bankacılık projesinde 2024 sonunda 1.27’den 1.29’a geçerken tam bu yaşandı. Cert-manager ve external-dns’in webhook’ları arada birkaç dakika boyunca yanıltıcı 404 yedi. Sonradan bazı DNS kayıtlarını manuel temizlemek zorunda kaldık. MVP olsaydı yaşanmazdı — bu yüzden Beta haberi bana özel olarak iyi geldi.
Alpha’dan Beta’ya Neler Değişti?
1.28’deki ilk implementasyon daha çok PoC gibiydi; çalışıyordu ama bazı köşeleri eksikti. Şimdi Beta’ya gelirken iş biraz toparlanmış görünüyor.
StorageVersion API’sinden Aggregated Discovery’ye Geçiş
Araya gireyim: Alpha sürümünde MVP, hangı peer’ın hangı kaynağı servis ettiğini anlamak için StorageVersion API‘sine bakıyordu. Mantıklıydı ama sıkıntısı vardı: StorageVersion CRD’ler ve aggregated API’ler için desteklenmiyor. Yanı extension dolu cluster’larda MVP yarım yamalak çalışıyordu; operatör’lerle ve custom controller’larla iç içe yaşadığımız bugünün dünyasında bu ciddi bir boşluktu.
Kısa bir not düşeyim buraya.
Beta’da mekanizma Aggregated Discovery‘ye taşınmış durumda. Artık API sunucuları peer’larının yeteneklerini dinamik biçimde keşfedebiliyor ve bunu daha gerçekçi şekilde yapıyorlar. CRD’ler de bundan faydalanıyor; yoğun custom resource kullanan ekipler için bu iş görüyor diyebilirim.
Peer-Aggregated Discovery: Eksik Olan Parça
Bence, Alpha döneminde gözden kaçan kilit bir nokta vardı: kaynak isteklerini proxyleyebiliyorduk. Discovery istekleri hâlâ sadece o anki sunucunun bildiği API’leri gösteriyordu. Yanı kubectl api-resources dediğinizde hangı API sunucusuna düştüyseniz onun listesini görüyordunuz. Pek hoş değil; tutarlılık gidiyordu.
Yanı, Beta’da peer-aggregated discovery geldi. Artık bir API sunucusu discovery cevabını döndürürken peer’larının bilgisini de birleştirip tek parça ve tutarlı liste verebiliyor (bizzat test ettim). Otomasyon yazan ekipler için bunun değeri var. Peki bunu neden söylüyorum? Bizim pipeline’lardan bazılarında da kubectl api-resources çıktısına göre karar veren script’ler dönüyor.
Akışın Kendisi: Adım Adım Ne Oluyor?
Vallahi, Şimdi durun bir dakika, mekanizmanın sahada nasıl aktığını anlatayım; kabaca akış şu şekilde ilerliyor:
- Client (mesela
kubectlya da bir controller) v2 bir kaynak için istek atıyor. - Load balancer isteği API Server A’ya yönlendiriyor; A henüz eski sürümde ve v2’yi tanımıyor.
- A lokal tarafta servis edip edemeyeceğine bakıyor, sonra discovery cache’e soruyor: “Bunu kim biliyor?”
- API Server B uygun peer olarak bulunuyor ve istek B’ye proxy edilirken araya
x-kubernetes-peer-proxiedheader’ı ekleniyor (sonsuz döngüyü kesmek için önemli detay). - B isteği işleyip cevabı A’ya geri yolluyor.
- A da cevabı client’a iletiyor; client tarafında hiçbir şey olmamış gıbı görünüyor.
Bu header detayı ilk başta bana fazla ince gelmişti. Sonra oturdu kafamda: o header olmazsa B de aynı proxy mantığını çalıştırıp isteği başka bir peer’a atabilir, sonra o da başkasına… derken döngü patlardı. Basit gıbı duruyor ama aslında hayat kurtaran savunma katmanı bu (en azından benim deneyimim böyle)
Sahada Kullanım: Nasıl Etkinleştireceksiniz?
Madem Beta öldü ve 1.36’dan itibaren default açık geliyor, normal şartlarda sizin ekstra bir şey yapmanız gerekmiyor. Ama kapatmak ya da bilinçli biçimde yönetmek isterseniz feature gate üzerinden müdahale edebilirsiniz:
# API Server flag olarak
--feature-gates=UnknownVersionInteroperabilityProxy=true
# Devre dışı bırakmak için (önerilmez ama mümkün)
--feature-gates=UnknownVersionInteroperabilityProxy=falsePeki sadece bu mu? Değil tabii. Peer’lar arası iletişim için sertifika ayarları da gerekiyor; API sunucularının birbirine güvenmesi lazım sonuçta. Bunun için --peer-ca-file ve --peer-advertise-ip gıbı parametreler devreye giriyor. Kendi cluster’ınızı sıfırdan kuruyorsanız (kubeadm, kops falan) bunları elle düzenlemeniz gerekebilir; managed servislerde işe AKS, EKS ya da GKE tarafı bunları zaten kendisi toparlıyor.
Türkiye’deki Şirketler İçin Ne İfade Ediyor?
Bence, Açık söyleyeyim, Türkiye’deki kurumsal müşterilerimde Kubernetes upgrade işleri hâlâ kâbus gıbı yaşanıyor çoğu zaman. Sebep teknikten çok kültürel aslında: birçok kurum upgrade’i yılda bir-iki kez yapılan büyük operasyon gıbı planlıyor. Halbuki Kubernetes’in ruhu tam tersi; sık ama küçük adımlarla ilerlemek daha doğal geliyor bana.
Kendi deneyimimden konuşuyorum, Bunun altındaki en büyük korku şu klasik soru oluyor: “Upgrade sırasında bir şey kırılır mı?” MVP gıbı özellikler tam da bu korkuyu biraz yumuşatıyor; kontrol düzlemi upgrade’i sırasındaki garip davranışları törpülüyor diyeyim ben buna nedense daha doğru geliyor bu ifade yerine koyduğum şeylerden biri de bu değil mi? Yanı teknik feature olmanın ötesinde, Türkiye’deki kurumların upgrade’e daha rahat girebilmesi için ufak bir cesaret desteği gıbı duruyor bence.
Çok konuştum, örnekle göstereyim. Service Bus + Azure Functions: Backoff ve Circuit Breaker yazımızda bu konuya da değinmiştik. kubernetes ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
Bir de finans ve telekom tarafında 7/24 SLA baskısı var ki orası ayrı dert zaten hani… Bir devlet bankası müşterimizde upgrade penceresi gece 02:00-04:00 arası iki saatti; tüm kontrol düzlemini o aralıkta yenilemek demek ekibin nefesini tutması ve sonra saatlerce “her şey yolunda mı?” diye izlemesi demekti (inanın bana). MVP gıbı özellikler bu pencereyi biraz daha güvenli hâle getiriyor, stres seviyesini de aşağı çekiyor açıkçası. Daha fazla bilgi için Agent Framework + AGT: Üretimde Yönetişim Şart yazımıza bakabilirsiniz. Bu konuyla ilgili Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza da göz atmanızı tavsiye ederim.
E Enterprise vs Startup: Kim Ne Yapmalı?
Burası önemli çünkü herkesin senaryosu aynı değil. Bu konuyla ilgili GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza da göz atmanızı tavsiye ederim.
| Senaryo | Tavsiyem |
|---|---|
| Tek API server, küçük ekip | MVP zaten devreye girmez (peer yok). Bilmenize bile gerek yok aslında. |
| 3-node HA cluster, orta ölçek | Statüs’u default açık bırakın; upgrade sırasında farkını hissedersiniz. |
| Multi-region, kritik prod | Peer sertifikalarını ve advertise IP’leri didik didik kontrol edin; önce test cluster’da deneyin. |
| Managed (AKS/EKS/GKE) | Kendiniz uğraşmayın; provider halleder zaten. Sadece release notlarını takıp edin. |
Laf Arasında Bir Test Hikâyesi Vereyim mi?
İşin garibi, Sadece teoriden konuşmuyorum yanı geçen hafta kişisel lab ortamımda — kubeadm cluster, 3 control plane node’u ve beş worker ile — manuel olarak 1.35’ten 1.36’ya geçtim.. Hatta bilerek control plane düğümlerinden birini önce yükselttim, diğerlerini eski sürümde bıraktım ki karışıklık net görünsün.. Sonra wkubectl getode get
Sıkça Sorulan Sorular
Mixed Version Proxy 1.36’da varsayılan olarak açık mı?
Evet, açık. Beta’ya taşındığı için UnknownVersionInteroperabilityProxy feature gate’i artık default olarak true geliyor. Kapatmak isterseniz --feature-gates ile false yapabilirsiniz,. Bence özel bir sebebiniz yoksa açık bırakmak çok daha mantıklı.
AKS, EKS veya GKE’de bu özelliği elle açmak zorunda mıyım?
Şahsen, Hayır, gerek yok. Managed servisler kontrol düzlemini zaten kendileri yönetiyor. Ne zaman destekleneceğini provider’ın release notlarından takıp edin. Mesela AKS için 1.36 desteği henüz GA olmadı, takvim açıklanınca otomatik olarak gelecek.
MVP latency’yi etkiler mi?
Aslında biraz etkiliyor. Proxy edilen istekler ekstra bir network hop yaşıyor, yanı birkaç milisaniye ek gecikme söz konusu. Ama şunu da belirteyim: bu sadece skewed upgrade dönemlerinde devreye giriyor. Steady state’te etkisi sıfır, kalıcı bir performans yükü değil.
CRD’lerim için de çalışıyor mu?
Evet! Açıkçası bu en güzel haberlerden biri. Alpha’da CRD’ler kapsam dışıydı ama Beta’da Aggregated Discovery sayesinde CRD’ler ve aggregated API’ler de destekleniyor. Operatörlerle dolu cluster’lar için bence gerçekten büyük bir kazanım bu.
Peer sertifika hatası alırsam ne yapmalıyım?
Önce --peer-ca-file parametresinin doğru CA’yı işaret edip etmediğini kontrol edin. Sonra --peer-advertise-ip ve --peer-advertise-port değerlerinin diğer control plane node’larından erişilebilir olduğundan emin olun. Tecrübeme göre sorun genelde network policy ya da firewall’dan kaynaklanıyor.
Kaynaklar ve İleri Okuma
Kubernetes Resmî Blog: Mixed Version Proxy Beta Duyurusu
Kubernetes Resmî Dokümantasyonu: Mixed Version Proxy
KEP-4020: Unknown Version Interoperability Proxy
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.
