Kubernetes v1.36: Mixed Version Proxy ile Yükseltme Korkusu Azalıyor
Bir 404, bazen sandığınızdan daha büyük bir mesele
Kubernetes tarafında en can sıkıcı şeylerden biri şu: Cluster aslında işi yapıyor,. Araya giren bir API sunucusu “Ben bunu tanımıyorum” deyip 404 Not Found dönüyor. Dışarıdan bakınca küçücük hata gibi dürüyor. Ama upgrade sırasında iş büyüyor, namespace silinmiyor, garbage collection şaşıyor, bazı controller’lar boş yere takılıyor… Tahmin eder mısınız? yanı ufak bir sürtünme değil.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
}
Bunu Türkiye’deki şirketler açısından değerlendirirsek (bizzat test ettim). çoğu kurumda upgrade projeleri hâlâ “gece yarısı bakım penceresi + dua + hızlı rollback planı” üçlüsüyle ilerliyor. MVP gibi özellikler işe o operasyonel stresi baya azaltabilir ama tek başına mucize yaratmaz.
Küçük ekip mi, kurumsal yapı mı?
- Küçük ekipteyseniz: feature gate yönetimiyle fazla uğraşmadan Beta varsayılanını takip etmek mantıklı olabilir.
- Büyük kurumdaysanız: önce staging’de mixed-version testleri yapın, sonra prod’a kontrollü geçin. (bu kritik)
- Sık CRD kullanan yapılarda: discovery davranışlarını özellikle gözlemleyin.
- Ağ politikaları sertse: proxy trafiğinin loglarını ayrı izleyin. (bence en önemlisi)
- Audit gereksinimi yüksekse: proxied request header’larını raporlamayı unutmayın.
İtiraf edeyim, Neyse uzatmayayım; benim görüşüm şu yönde: Bu özellik doğru yönde atılmış ciddi bir adım ama operasyonel disiplin olmadan tek başına yetmez. Azure danışmanlığı yaptığım projelerde en sık gördüğüm hata şu oluyor — insanlar yeni özelliği açınca problemi çözmüş sanıyorlar… halbuki asıl iş izleme tarafında başlıyor.
Sahada karşılaşabileceğiniz ince ayarlar ve riskler
MVP’nın güzel yanı şeffaf olması; kötü yanı işe şeffaflığın bazen sizi çıplak bırakmasıdır! Eğer discovery veriniz kirliyse veya peer’ler arasında beklenmeyen farklar varsa sorun hemen görünür hâle gelir.
Bu kötü mü? Değil.
Ama hazırlıksızsanız can sıkar.
Aslında durun — şöyle anlatayım:
Bende ilk denediğimde kafa karıştıran hata mesajlarından biri proxy zinciri boyunca kaybolan header davranışıydı.
Bunu Mayıs 2025’te Ankara’daki lab ortamımızda gördük.
Çözüm gayet basitti:
log seviyesini yükselttik,
peer discovery cache’i temizledik,
sonra isteğin hangi hop’tan geçtiğini net biçimde izledik.
Yanı mesele çoğu zaman feature’ın bozuk olması değil,
sizin önü nasıl gözlediğiniz oluyor.
İşte burası kritik!
# Kontrol ederken bakılabilecek alanlar
kubectl get apiservices
kubectl get --raw /apis | head
kubectl logs -n kube-system kube-apiserver-xxx | grep -i proxy
# Upgrade öncesi not:
# — API server versiyonlarını listele
# — CRD / aggregated API envanteri çıkar
# — Discovery yanıtlarını doğrula
# — Audit log'larda proxied request'leri izle
Eğer bütçe kısıtlıysa ya da takımınız çok küçükse önce gözlem araçlarına yatırım yapmanızı öneririm; çünkü böyle özelliklerde sorun genelde kodda değil görünürlükte çıkıyor.
Azure Monitör,
Prometheus,
ve mümkünse merkezî loglama…
bunlar lüks değil artık.
Kurumsalda mecburiyet gibi düşünün.
Bir arkadaşım İzmir’deki SaaS girişiminde sadece iyi loglama kurarak upgrade süresini iki hafta içinde yarıya indirdi — şaşırtıcı değildi aslında, çünkü görünmeyeni yönetemezsiniz.
Kubernetes yolculuğunda neden önemsemelisiniz?
MVP bana göre Kubernetes’in olgunlaşma çizgisinde küçük ama etkili taşlardan biri.
Bir yanda PSI GA gibi node baskısını daha iyi anlamamızı sağlayan geliştirmeler var,
öbür yanda mixed-version proxy gibi control plane’i daha akıllı yapan parçalar…
Toplamda resim netleşiyor:
daha az kırılgan,
daha az panik yaratan,
daha fazla öngörülebilir cluster yönetimi.
Zamanlama neden manidar?
İşin garibi, Kubernetes ekibi son sürümlerde özellikle operasyona yakın konulara ağırlık veriyor gibi geliyor bana.
Bu kötü mü?
Hayır.
Tam tersine çok yerinde.
Çünkü üretimdeki kullanıcıların derdi yeni isimli parlak özelliklerden önce mevcut sistemin sessizce çökmeden devam etmesi.
Ben AZ-305 sınavına hazırlanırken de hep aynı şeyi düşündüm:
mimarinin güzelliği ancak dayanıklılıkla birleşirse anlam kazanıyor.
Bir bankacılık projesinde bunu açıkça gördük;
upgrade sırasında hatalı routing yüzünden çıkan minicik bir problem bile batch işlemlerini geciktirebiliyordu.
MVP tarzı mekanizmalar tam burada değer üretiyor.
Son olarak şunu söyleyeyim:
Eğer elinizde multi-version control plane varsa,
bu özelliği hafife almayın;
önemsiz görünen ağrılar büyüyebilir (ben de ilk duyduğumda şaşırmıştım)
Sıkça Sorulan Sorular
Kubernetes Mixed Version Proxy ne işe yarıyor?
Mixed Version Proxy (MVP), hani yerel API sunucusu bir kaynağı tanımıyorsa isteği doğru peer API sunucusuna yönlendiren bir mekanizma. Yanı yanlış yere 404 Not Found almak yerine istek doğru yere gidiyor ve upgrade süreci çok daha az stresli hâle geliyor. Bence bu, özellikle büyük cluster’larda gerçekten hayat kurtarıcı bir özellik.
Kubernetes v1.36’da MVP varsayılan açık mı geliyor?
Evet! Kubernetes v1.36 ile Mixed Version Proxy Beta aşamasına çıktı ve artık varsayılan olarak etkin. Yanı aslında ekstra bir feature gate ayarıyla uğraşmana gerek kalmıyor, kutudan çıktığı gibi kullanabiliyorsun.
Neden StorageVersion yerine Aggregated Discovery kullanılıyor?
Çünkü Aggregated Discovery, mesela CRD’ler ve aggregated API’lar dahil olmak üzere peer yeteneklerini çok daha doğru yansıtıyor. Peki bunu neden söylüyorum? StorageVersion bazı alanlarda yetersiz kalıyordu açıkçası, bu yüzden daha geniş bir çözüme ihtiyaç vardı.
Hangi ortamlarda dikkatli olmalıyım?
Bilhassa de de rolling upgrade yapılan HA control plane ortamlarında dikkatli olmak gerekiyor. CRD yoğunluğu yüksek kurulumlarda işe tecrübeme göre önce staging’de test etmek çok mantıklı, direkt production’a geçmemek iyi olur.
Kaynaklar ve İleri Okuma
Kubernetes v1.36 Blog Yazısı: Mixed Version Proxy Beta
Bir şey dikkatimi çekti: Kubernetes Control Plane Communication Dokümantasyonu
Şöyle söyleyeyim, Kubernetes API Concepts Resmî Dokümanı
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.
4 comments