Kubernetes v1.36: Haru ile Gelen Sakin Güç
Kubernetes tarafında bazı sürümler var, ilk bakışta gösteriş yapmıyor ama iki hafta sonra “haa, işte fark buymuş” dedirtiyor (şaşırtıcı ama gerçek). v1.36 bende tam böyle bir his bıraktı. Dışarıdan bakınca sakın dürüyor, hatta biraz yumuşak; ama içeriğe girince stabilite, olgunluk ve operasyonda nefes aldıran ayrıntılar birikmiş hâlde karşınıza çıkıyor.
Açıkçası, Ben bu tarz sürümleri seviyorum. Çünkü kurumsal dünyada herkes büyük patlamaları konuşuyor, ama asıl para eden şey çoğu zaman küçük ve sessiz iyileştirmeler oluyor. 20+ yıllık sistemcilik geçmişimde bunu defalarca gördüm: upgrade sonrası gece yarısı telefon çaldırmayan değişiklikler, bazen en değerli olanlar oluyor. Bilhassa AZ-305. AZ-104 hazırlıkları sırasında da hep şunu düşündüm; bulut mimarisinde yeni özellik kadar, sorunsuz işletim de önemli. Hatta çoğu zaman daha önemli.
Bu yazıda Kubernetes v1.36’yı sadece release notu gibi anlatmayacağım. Biraz benim gözümden bakacağız; neyin gerçekten işe yaradığına, neyin kağıt üstünde güzel görünüp pratikte beklediğim kadar parlamadığına da değineceğim. Hani olur ya, sürüm notunu okuyorsun, her şey pırıl pırıl dürüyor… sonra prod ortamda tablo biraz değişiyor (buna dikkat edin). İşin aslı biraz da o.
Haru Ne Diyor? Sürümün Ruhunu Doğru Okumak
“Haru” kelimesi Japonca’da birkaç güzel anlam taşıyor: bahar, açık hava, uzak ufuklar… Bence bu işim seçimi boşuna değil. Kubernetes topluluğu yıllardır aynı şeyi yapıyor; sistemi daha temiz, daha öngörülebilir (bizzat test ettim). Daha taşınabilir hâle getirmek için küçük ama düzenli adımlar atıyor. Sız ne dersiniz? Gösteriş yok, tempo var.
İşte tam da bu noktada devreye giriyor.
İşin garibi, v1.36’da toplam 70 geliştirme varmış; bunların 18’i Stable’a çıkmış, 25’i Beta’ya girmiş, 25’i de Alpha aşamasına geçmiş. Bu sayı tek başına bile şunu söylüyor: proje hâlâ canlı. Bir platformun sağlıklı olup olmadığını anlamak istiyorsanız sadece yeni çıkan parlak özelliklere bakmayın; hangilerinin olgunlaşıp hangilerinin deneme alanına indiğine de bakın. Bazen orası daha çok şey anlatır.
Bir finans kurumunda 2024 sonlarında yaptığımız Kubernetes geçiş çalışmasında buna benzer bir şeyi birebir yaşadık. Ekip önce “yenilik” istiyordu ama sonra loglama ve ağ davranışı yüzünden operasyon ekibi aylarca uğraştı. O gün anladılar ki kurumsalda esas mesele feature sayısı değil; feature’ın nasıl davrandığıdır. Kağıt üstü ayrı, gece nöbeti ayrı.
Çok konuştum, örnekle göstereyim.
Neden Bu Sürüm Sessiz Ama Önemli?
Kubernetes v1.36’yı heyecanlı yapan şey tek bir devasa özellik değil; daha çok parçaların birbirini tamamlaması. Açık konuşayım, ben böyle sürümlere daha çok güveniyorum. Çünkü kurumsal tarafta devrim gibi görünen değişikliklerin bir kısmı iki ay sonra geri alınabiliyor ya da etrafında yamalar dolaşmaya başlıyor.
Geçen yıl Logosoft tarafında yürüttüğümüz bir Azure/Kubernetes danışmanlığında şunu net gördük: ekipler genelde ölçekten önce kararlılık istiyor. Bilhassa mikroservis sayısı arttığında API gateway’den ingress’e, network policy’den storage katmanına kadar zincirin herhangi bir halkası sorun çıkarabiliyor (ve işin kötüsü bazen sorun en görünmez halkadan geliyor). Küçük startup’larda bu kadar katman yok; dolayısıyla onlar yeniliği hızlı denerken enterprise ekipleri biraz daha temkinli davranmalı.
Bence v1.36’nın kıymeti burada yatıyor: platformun omurgasını güçlendiriyor ama bağırıp çağırmıyor. Biraz iyi yapılmış altyapı işi gibi… kimse alkışlamaz ama biri bozarsa herkes fark eder!
Sürüme nasıl yaklaşmalı?
Eğer küçük bir ekipseniz ve cluster sayınız azsa beta/alpha tarafını kontrollü şekilde deneyebilirsiniz. Ama regülasyon baskısı olan kurumlarda önce staging ortamında gözlem yapmak şart. Ben olsam kritik production cluster’da yeni sürümü doğrudan açmam; önce gerçek trafik simülasyonu yaparım, sonra adım adım ilerlerim. Acele edince fayda değil stres kalıyor. Bu konuyla ilgili Kubernetes’te ExternalIPs Neden Gidiyor: Güvenlik ve Geçiş yazımıza da göz atmanızı tavsiye ederim.
Şunu fark ettim: Bir diğer nokta da şu: yükseltme planı sadece Kubernetes versiyonu değildir, yan servisler de işin içine girer (CNI, CSI, ingress controller, monitöring stack). Hani araba lastiğini değiştirirken rot balansı unutulursa ne olur? Aynı hesap. Sonra herkes birbirine bakar. Daha fazla bilgi için Azure Cosmos DB Conf 2026: Benim Gözümden Asıl Mesaj yazımıza bakabilirsiniz. Bu konuyla ilgili VSLive! Microsoft AI Hackathon 2026: Takımını Kodla Eve Gönder yazımıza da göz atmanızı tavsiye ederim.
| Bölge | Küçük Startup | Enterprise |
|---|---|---|
| Sürüm denemesi | Daha hızlı pilot yapılabilir | Staging + change management şart |
| Maliyet hassasiyeti | Düşük trafik nedeniyle esnek olunabilir | Operasyon maliyeti ana konu olur |
| Risk toleransı | Daha yüksek olabilir | Daha düşük olmalı |
| Gözlemleme ihtiyacı | Temel metrikler yeterli olabilir | Ayrıntılı telemetry gerekir |
Sahada Ne Değişiyor? Operasyon Gözünden Bakınca
Kubernetes güncellemelerinde benim ilk baktığım yer hep aynı: ağ davranışı, gözlemlenebilirlik ve güvenlik etkisi. Çünkü teoride fena durmayan birçok değişiklik pratikte “latency neden arttı?” sorusuna dönüşebiliyor. İşin tatsız kısmı da bu zaten.
Mesela geçen mart ayında Ankara’daki bir müşteride external traffic akışıyla ilgili garip bir durum yaşamıştık; problem aslında uygulamadan çok ağ politikalarının birleşiminden çıkmıştı. Orada öğrendiğimiz ders şuydu: Kubernetes sürümü ne kadar modernleşirse modernleşsin, eski alışkanlıklarla yönetilen ortamlar hâlâ sorun çıkarıyor. Sistem yenileniyor ama refleksler aynı kalınca pek tatlı olmuyor.
Kubernetes yükseltmelerinde asıl soru “Yeni ne geldi?” değil; “Bende neyi bozabilir?” sorusu olmalı.
Açık söyleyeyim, release notlarını okurken en çok sevdiğim bölüm hep deprecation kısmı oluyor (evet, doğru duydunuz). çünkü orası görünmeyen borcu gösteriyor. Borcu erken görmek iyi iş; geç görmek pahalıya patlıyor.
Bir dakika — bununla bitmedi. sakın konusundaki yazımız yazımızda bu konuya da değinmiştik.
Maliyeti nasıl düşünmeli?
Doğrusu, Burası önemli. Türkiye’deki şirketlerde bulut maliyetleri artık teknik ekiplerin arka planda konuştuğu bir konu değil; doğrudan yönetimin masasına geliyor. Azure üzerinde çalışan Kubernetes iş yüklerinde upgrade kararını verirken yalnızca teknik uyumluluk değil, node verimliliği. Operasyon saati de hesaba katılmalı. Yoksa rapor başka konuşur, fatura başka konuşur. Daha fazla bilgi için Git ve GitHub: VS Code’da Başlarken İşin Püf Noktaları yazımıza bakabilirsiniz.
İnanın, Eğer bütçe kısıtlıysa tam kapsamlı enterprise observability stack yerine daha sade başlayabilirsiniz: temel metrics-server + Prometheus + uygun alarm seti çoğu ekip için yeterli. Sonradan büyütmek kolaydır ama baştan ağır kurarsanız hem maliyet hem karmaşa artar (bu ikisi genelde el ele gider). Ben açıkçası sade başlayan ekiplere daha çok saygı duyuyorum.
Bende oluşan genel kanaat şu: Kubernetes’e yatırım yapan kurumların yüzde sekseni aslında teknolojiye değil disipline yatırım yapıyor; versiyon yükseltme bunun sınavlarından biri oluyor.
Kullanıcı Deneyimi Değil Ama Operatör Deneyimi Var mı?
Kubernetes kullanıcıları çoğu zaman geliştiriciler olarak düşünülür ama operatör tarafını unutmamak lazım. Bilhassa platform ekipleri için sürüm kalitesi demek dashboard’da daha az kırmızı çizgi görmek demek. Baya düz bir tanım öldü ama doğru yanı. 2019’da kendi lab ortamımda ilk kez büyük ölçekli cluster upgrade senaryosu test ederken tek bir admission webhook yüzünden tüm rollout’u kilitlemiştim. O gün bugündür upgrade öncesi bağımlılık kontrolünü atlamam. Atlanmaz çünkü sonra can sıkıyor.
Bunu yaşayan biri olarak söyleyeyim, v1..36’nın bana hissettirdiği şey şu öldü: kullanıcıya bağırmayan ama operatöre huzur veren bir release bu.
Her şey mükemmel mi?
Değil tabiî.
Alpha alanındaki bazı yenilikler henüz ham dürüyor. Bunları üretime yakın ortamlarda fazla özgür bırakmak istemem.
Kağıt üstünde süper görünen bazı şeylerin sahada biraz pişmesi gerekiyor.
Neyi hemen denemeli?
- Deprecation kontrolü: Upgrade öncesi API kullanımınızı tarayın.
- Add-on uyumu: CNI/CSI/ingress bileşenlerini ayrı test edin.
- Trafik simülasyonu: Gerçek kullanıcı yüküne yakın senaryo üretin.
- Rollback planı: Geri dönüş yolunu yazmadan ilerlemeyin.
- Metrik doğrulama: Sadece pod hazır mı diye bakmayın; gecikmeye de bakın.
Türkiye’de Kurumsal Ekipler İçin Pratik Okuma
Bunu Türkiye’deki şirketler açısından değerlendirirsek iş biraz farklılaşıyor.
Birçok kurumda Kubernetes hâlâ yalnızca geliştirme ekibinin konusu sanılıyor.
Aslında değil.
Finans sektöründe çalışan biri olarak ya da telekom tarafıyla temas etmiş biri olarak şunu söyleyebilirim:
platform artık iş sürekliliğinin kalbi hâline geldi.
Yanı burada yapılan her iyileştirme doğrudan müşteri deneyimine dokunuyor.
Kubernetes’te ExternalIPs Neden Gidiyor: Güvenlik ve Geçiş
Sıkça Sorulan Sorular
Kubernetes v1.36’ya hemen geçmeli mıyım?
Kritik üretim yükünüz varsa önce staging’de test edin, direkt atlamayın.
Yanı sadece yeni özelliklere bakıp “geçeyim” demeyin.
Aslında add-on uyumu. Geri dönüş planı, sürümün kendisi kadar — hatta bazen daha fazla — önem taşıyor.
(inanın bana)
Alpha özellikleri production’da kullanılabilir mi?
Kural olarak hayır.
Alpha özellikler deneysel, yanı davranışları her an değişebilir.
Açıkçası üretimde kullanmak istiyorsanız ciddi bir riski göze almış oluyorsunuz — bence buna değmez.
Sürüm yükseltmeden önce ilk neyi kontrol etmeliyim?
Açık konuşayım, İlk bakacağınız şey deprecated API’ler. Controller uyumluluğu olmalı.
Neyse ki bunu otomatik tarayan araçlar var, hani birkaç dakikada görebiliyorsunuz.
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.
3 comments