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.
📋 İçindekiler
-
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
💡 Bilgi: İlk adım olarak önce control plane bileşenlerinizin sürüm dağılımını çıkarın, ardından aggregated discovery davranışını test edin ve son olarak upgrade senaryosunu staging ortamında birebir tekrar edin.
}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 izleEğ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ı
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Cenk B.
Upgrade sırasında 404 yiyen istek yüzünden saatler harcadım, o yüzden bu özelliği çok anlamlı buluyorum. Peki mixed version proxy devreye girdiğinde gecikme/latency üzerinde gözlemlenebilir bir etkisi oluyor mu merak ettim? Bu arada şu yazınız da güzeldi: Python ile Teams SDK artık GA: Benim Sahada Gördüklerim — https://www.askinkilic.com.tr/python-ile-teams-sdk-artik-ga-benim-sahada-gorduklerim/
Berk N.
Tam da geçen ay production cluster’ımızı yükseltirken bu 404 sorunuyla boğuştuk, epeyce zaman kaybettik. 1.36’yı bekleyip beklememe konusunda kararsız kaldık ama Mixed Version Proxy tam bu ihtiyaca yönelik görünüyor, gerçekten iyi bir ekleme.
Koray M.
Upgrade sırasında 404 yiyen istekler gerçekten baş belası oluyordu, özellikle rollback anında tam ihtiyaç duyduğun anda. Bu özellik production ortamında cluster yükseltme sürecini çok daha az stresli hale getirecek gibi görünüyor. 1.36 ne zaman stable oluyor acaba?
İrem B.
Upgrade sırasında 404 yemek gerçekten sinir bozucu bir şeydi, özellikle rollback yaparken. Bu özellik production ortamları için çok kritik, ne zaman stable’a geçer acaba? Bu arada Microsoft tarafında da benzer altyapı yenilikleri var, şu yazı da ilgini çekebilir: Microsoft Foundry Nisan 2026: Üretimde Dikkat Çeken Yenilikler — https://www.askinkilic.com.tr/microsoft-foundry-nisan-2026-uretimde-dikkat-ceken-yenilikle/
Yorumlar kapalı.
4 comments