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.
İlginç olan şu ki, Kubernetes 1.36 ile beta’ya çıkan Mixed Version Proxy tam da bu yüzden önemli. Ben bunu ilk okuduğumda aklıma eski günler geldi; 2018’de İstanbul’da bir finans müşterisinde benzer bir yükseltme penceresinde “ama bu resource cluster’da var!” diye saatlerce log kovaladığımızı hatırlıyorum. Sorun çoğu zaman veri değil, yanlış node’a ya da yanlış versiyondaki bileşene düşen istek oluyor. İşin aslı şu ki, dağıtık sistemlerde doğru cevap kadar doğru yere yönlendirme de kritik.
Ha bu arada, burada konuştuğumuz şey sadece teorik bir zarafet meselesi değil. Büyük kurumsal yapılarda upgrade penceresi dar olur, rollback pahalıdır, ekip sayısı fazladır ve herkes kendi tarafında haklıdır. Küçük bir startup işe genelde “biraz risk alırız” diyebilir; ama enterprise tarafında o risk bazen direkt gece nöbeti demek oluyor. O yüzden MVP’nın Beta’ya çıkması bence baya iyi haber.
MVP ne yapıyor, neyi çözüyor?
Mantık basit: Bir API sunucusu kendisinde olmayan bir resource isteği alınca eli kolu bağlı kalmıyor. Eğer peer’lerinden biri o resource’u biliyorsa isteği ona proxy ediyor. Böylece istemci yanlışlıkla “bu yok” cevabı almıyor. Sanki apartmanda kapıcıya sordunuz; kapıcı bilmiyorsa — en azından ben öyle düşünüyorum — komşuya soruyor gibi düşünün… kaba ama iş görüyor.
Bir dakika — bununla bitmedi.
Alpha sürümde bu işin temeli vardı ama mimarı biraz eski kokuyordu desem yeridir. Mesela StorageVersion API bağımlılığı CRD ve aggregated API tarafında can sıkıyordu. Beta ile birlikte Kubernetes — en azından ben öyle düşünüyorum — ekibi bunu modernleştirmiş; artık peer yeteneklerini anlamak için Aggregated Discovery kullanılıyor. Bu bana 2024 başında Ankara’daki bir kamu kurumunda yaptığımız kontrol düzlemi iyileştirme çalışmasını hatırlattı: discovery katmanı ne kadar temizse operasyon da o kadar rahatlıyor.
MVP’nın asıl değeri şurada yatıyor: Hatalı görünen ama aslında cluster’da mevcut olan kaynaklar için yanlış negatif üretmeyi azaltıyor.
Bunu hafife almayın. Yanlış negatif dediğiniz şey bazen otomasyonun zincirleme şekilde bozulması demek oluyor. Bir controller gereksiz temizlik yapar, başka servis beklenmedik şekilde kapanır… sonra herkes birbirine bakar.
Durun, bir saniye.
Alpha’dan Beta’ya geçerken neler değişti?
Açık konuşayım, Alpha sürüm çoğu zaman “bakıyoruz işte” seviyesindedir; üretim güveni vermez ama yön gösterir. Beta işe başka hikâye. Kubernetes v1.36’da MVP artık varsayılan açık geliyor ve bu tek başına önemli bir eşik.
En büyük farklardan biri discovery yaklaşımı öldü dedim ya… bunun pratik etkisi büyük çünkü cluster içindeki farklı API sunucularının hangi kaynakları desteklediğini daha canlı. Doğru şekilde anlayabiliyorsunuz. Eski modelde bilgi daha statikti; yeni modelde kontrol düzlemi sanki birbirini daha iyi duyuyor gibi davranıyor.
Garip gelecek ama, Bende küçük bir hayal kırıklığı yaratan nokta şu öldü: Kağıt üstünde her şey çok temiz görünüyor ama gerçek dünyada discovery cache tutarlılığı yine dikkat istiyor. Peki bunu neden söylüyorum? Yanı feature güzel, hatta baya işe yarıyor; fakat “açtım bitti” kafasında değilsiniz hâlâ. Bu konuyla ilgili Handoff Orchestration: Ajanlar Topu Nasıl Devrediyor? yazımıza da göz atmanızı tavsiye ederim.
Neden Aggregated Discovery önemli?
Hani, Aggregated Discovery, özellikle heterojen control plane senaryolarında hayat kurtarıyor diyebilirim. Bir server yeni resource’u biliyor olabilirken diğeri henüz bilmiyor olabilir; discovery verisi sayesinde isteklerin körlemesine dolaşması yerine hedefe gitmesi sağlanıyor.
Ben bunu biraz trafik ışığına benzetiyorum: Her araba kendi kafasına göre gitmeye kalkarsa karmaşa çıkar, ışık varsa akış düzenleniyor (tabi şehir planlaması düzgünse). Burada da aynı mantık var; görünürlük arttıkça routing daha akıllı hâle geliyor.
Peki StorageVersion neden geride kaldı?
Doğrusu, Bunun cevabı biraz teknik ama net: StorageVersion bazı senaryolarda yeterli değilmiş gibi davranıyordu çünkü CRD’ler ve aggregated API’ler tam kapsanmıyordu. Kurumsalda sız buna “kapsam boşluğu” dersiniz; saha diliyle söyleyeyim, köşe bucak kaçan birkaç kaynak tipi bütün tasarımı zora sokabiliyor.
| Konu | Alpha yaklaşımı | Beta yaklaşımı |
|---|---|---|
| Pear bilgisi | StorageVersion tabanlı | Aggregrated Discovery tabanlı |
| CRD desteği | Sınırlı / problemli | Daha uyumlu |
| Mimarı esneklik | Daha eski mekanizmalar | Daha modern yapı |
| Kullanım kolaylığı | Daha çok manuel dikkat isterdi | Daha az sürpriz çıkarır |
| Tavsiye edilen durum | Sadece deneme ortamları | Kademeli üretim geçişleri için uygun |
Sahada bunu nasıl düşünürüm?
E tabi burada teoriyi bırakıp sahaya inmek lazım. Eğer küçük ekipseniz ve cluster sayınız azsa MVP size doğrudan nefes aldırabilir çünkü upgrade sırasında oluşan garip edge-case’leri azaltır. Ama büyük enterprise yapılarda konu sadece feature açmak değil; observability, audit trail ve rollback stratejisi de beraber yürümeli. Bu konuyla ilgili Microsoft Foundry Nisan 2026: Üretimde Dikkat Çeken Yenilikler yazımıza da göz atmanızı tavsiye ederim. Python ile Teams SDK artık GA: Benim Sahada Gördüklerim yazımızda bu konuya da değinmiştik.
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! Azure DevOps Server Mayıs Yamaları: Neyi, Neden, Nasıl Kontrol Etmeli? yazımızda bu konuya da değinmiştik.
# 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. Daha fazla bilgi için .NET 11 Preview 4: Sessiz Ama Dolu Gelen Sürüm yazımıza bakabilirsiniz.
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.
İ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