Kubernetes tarafında tempo hiç düşmüyor, bunu zaten hepimiz biliyoruz. Nisan 2026 sonunda gelecek v1.36 sürümü de, kaldırılan parçalarıyla. Yeni eklenen şeyleriyle baya konuşulacak gibi duruyor. Ben bu release cycle’ı başından beri izliyorum, hatta geçen ay Logosoft’ta bir finans müşterimizin AKS kümelerini yükseltme planını yaparken tam da bu listeyle uğraştım; yani işin teorisiyle pratiği aynı masaya oturdu diyebilirim. Şimdi size “bu sürümde ne var, ne yok” diye anlatayım, ama düz çeviri gibi değil, biraz da sahada gördüklerimle harmanlayarak.
Deprecation ve Removal Meselesi: Neden Bu Kadar Önemli?
Kubernetes’in bir deprecation policy’si var ve açık konuşayım, bu projenin en toparlanmış taraflarından biri. Stable API’ler ancak yerine yenisi gelince deprecated oluyor, beta API’ler en az 3 release boyunca destekleniyor, alpha API’ler ise — şey yani — bir anda ortadan kaybolabiliyor. Kağıt üstünde basit geliyor ama pratikte işler bazen ters köşe yapıyor.
Mesela 2024 sonunda bir telekom müşterimizde v1.28’den v1.31’e geçiş planlarken, deprecated olmuş bir beta API’nin çoktan kaldırıldığını fark etmemiştik. CI/CD pipeline çalışıyor, testler yeşil görünüyor, ama staging’e deploy edince pod’lar kalkmıyor. Neden? Çünkü API endpoint artık yok. Şimdi dönüp bakınca o gece 3’e kadar ofiste oturmamızın sebebi tam buydu; ufak bir detay gibi duran şey bütün planı bozdu.
Bak şimdi, İşin aslı şu: Kubernetes’in deprecation guide’ını her major upgrade öncesinde satır satır okumak lazım. Evet, sıkıcı. Evet, kimse hevesle açmıyor. Ama diğer seçenek production’da gece 3’te debugging yapmak — siz olsanız hangisini seçersiniz?
Ingress NGINX Emekliye Ayrılıyor: Bu Büyük Olay
Bak şimdi, burada biraz durup altını çizmek lazım. 24 Mart 2026’da SIG-Security ve SIG-Network, Ingress NGINX projesini resmen emekliye ayırdı. Yeni release yok. Bugfix yok. Güvenlik yaması yok. Mevcut deploy’larınız çalışmaya devam edecek, Helm chart’lar ve container image’lar erişilebilir kalacak ama… artık bakım işi bitmiş durumda.
Bu haber beni biraz üzdü doğrusu (ciddiyim). Ingress NGINX, Kubernetes çevreinin neredeyse “default” ingress controller’ı gibiydi; hani cluster kuran herkes ilk iş “helm install ingress-nginx” yapardı ya — o alışkanlık artık geride kaldı. Türkiye’deki kurumsal müşterilerimde hâlâ Ingress NGINX kullanan epey cluster var; geçen hafta saydım, sadece benim danışmanlık verdiğim projelerde 14 tane aktif deployment çıktı karşıma.
Peki ne olacak? Birkaç seçenek var:
- Traefik: Hafif duruyor, config’i nispeten kolay, middleware tarafı da fena değil. Küçük-orta ölçek için bence gayet makul.
- HAProxy Ingress: Performans odaklıysanız iş görüyor; özellikle yüksek throughput senaryolarında göz atılır.
- Envoy tabanlı çözümler (Contour, Emissary): Enterprise tarafta duruyorlar; service mesh entegrasyonu düşünüyorsanız mantıklı olabilir.
- Azure Application Gateway Ingress Controller (AGIC): AKS kullanıyorsanız ve Azure-native kalmak istiyorsanız ciddi bir aday. Ben bunu iki bankacılık projesinde denedim ve sonuçlar beklediğimden daha iyi çıktı.
Ingress NGINX emekliliği bir “eyvah” anı değil aslında; Kubernetes ortaminin büyüdüğünün işareti gibi duruyor. Ama geçiş planınızı BUGÜN başlatın — yarına bırakınca iş uzuyor.
Küçük bir detay: Türkiye’deki şirketler açısından bakınca durum biraz daha netleşiyor: birçok kurum hâlâ “çalışıyorsa dokunma” kafasında ilerliyor. Ama güvenlik yaması almayan bir ingress controller’ı production’da tutmak… Bunu KVKK denetiminde nasıl anlatırsınız? Açık konuşayım, bu geçiş için bütçe ayırın, planlayın (ciddiyim). Q3 2026 bitmeden tamamlamaya çalışın; daha fazla beklemek pek akıllıca değil.
externalIPs Alanı Deprecated: Küçük Ama Kritik
Aslında, .spec.externalIPs alanı deprecated oluyor. Hmm… şöyle düşününce bunu aktif kullanan çok kişi kalmadı belki ama kullananlar için risk tarafı baya gerçek.
İtiraf edeyim, externalIPs size herhangi bir IP adresini Service’e yönlendirme imkanı veriyor — doğrulama olmadan. Yani cluster içindeki biri — itiraz edebilirsiniz tabi — dışarıdaki herhangi bir IP’yi kendi Service’ine bağlayabiliyor; bu da man-in-the-middle saldırıları için gereksiz bir kapı açıyor. Ben AZ-500 sınavına hazırlanırken bu tip “kolaylık mı güvenlik mi” ikilemlerini epey kurcalamıştım; Kubernetes de sanırım aynı sonuca varmış gibi görünüyor. Daha fazla bilgi için GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza bakabilirsiniz.
Eğer externalIPs kullanıyorsanız alternatifler kabaca şunlar: Daha fazla bilgi için Docker Compose İçin 7 Şablon: Kurulum Kafası Karışmasın yazımıza bakabilirsiniz.
| Mevcut Kullanım | Alternatif Çözüm | Zorluk Seviyesi |
|---|---|---|
| externalIPs ile doğrudan trafik yönlendirme | LoadBalancer tipi Service + MetalLB | Orta |
| On-prem ortamda external IP atama | MetalLB veya kube-vip | Düşük-Orta |
| Cloud ortamda external IP | Cloud provider LoadBalancer | Düşük |
| Spesifik IP’ye bağlama ihtiyacı | Ingress controller + annotation | Orta |
GA’ya Terfi Eden Özellikler: Artık Stable
Bakın, Kubernetes sürümlerinde benim en merakla baktığım kısım burası oluyor: hangi özellikler GA oldu? Çünkü GA demek “artık production’da kullanabilirsiniz” demek değil de ne demek olsun? v1.36 içinde gözüme çarpan birkaç parça var. Bu konuyla ilgili Ddev’e Aljibe Eklemek: Kurulu Projede Sürprizler yazımıza da göz atmanızı tavsiye ederim.
POD Disruption Budget (PDB) Iyileştirmeleri
PDB tarafında artık daha granüler kontrol geliyor. Küçük ekipseniz “ne fark eder” diyebilirsiniz ama enterprise ölçekte, 200+ node olan bir cluster’da rolling update sırasında PDB’nin düzgün davranması gerçekten önemli oluyor; aksi halde işler gereksiz yere uzuyor veya takılıyor bile diyebilirim.
Bunu boşuna söylemiyorum: Bir bankacılık projesinde node drain işlemi PDB yüzünden tam 4 saat sürmüştü; evet dört saat! Yeni iyileştirmelerle böyle senaryoların azalacağını düşünüyorum ama yine de kenarda köşede garip edge case çıkar mı, çıkar tabii.
Sidecar Container’lar Için Native Destek
Sana önce şunu söyleyeyim: sidecar pattern’i Kubernetes’te yıllardır kullanılıyordu ama ortada resmi anlamda oturmuş bir sidecar kavramı yoktu. Init container’ın restartPolicy: Always yaklaşımıyla gelen çözüm şimdi neredeyse tamamen stable hale geldi; yani sidecar container ana container’dan önce başlıyor. Sonra kendi lifecycle’ını düzgün şekilde sürdürüyor.
Bunu Türkiye’deki şirketler açısından düşünürsek Istio. Linkerd gibi service mesh çözümleri kullanan herkes direkt fayda görecek gibi duruyor. Geçen yıl bir e-ticaret müşterimizde Istio — kendi adıma konuşayım — sidecar injection sırasında race condition yaşamıştık; pod ayağa kalkıyor. Envoy proxy hazır olmuyordu, uygulama da dış servislere bağlanamıyordu. Böyle dertler artık azalabilir diye umuyorum.
Dynamic Resource Allocation (DRA) Gelismeleri
Kendi deneyimimden konuşuyorum, GPU ve özel donanım kullanan workload’lar için DRA baya önemli hale geliyor. Hele bir de AI/ML çalışan ekiplerde buna ihtiyaç artıyor; Türkiye’de bu alana olan ilgi de açıkçası hızlı yükseldi. Ben AZ-104 ve DP-203 hazırlıkları sırasında Azure tarafında GPU node pool yönetiminin zaten kolay olmadığını görmüştüm; Kubernetes’te DRA ile en azından kaynak tahsisi biraz daha derli toplu hale geliyor gibi.
İşte tam da bu noktada devreye giriyor.
DRA’yı device plugin mekanizmasının biraz evrimleşmiş hali gibi düşünebilirsiniz.
GPU, FPGA veya başka akseleratörleri pod’a dağıtırken daha esnek davranıyor.
Eğer AI workload’unuz varsa buna mutlaka bakın.
Dikkat Ceken Yeni Beta Ozellikler
beta
GA özellikleri güzel de beta tarafı bize biraz gelecek kokusu veriyor
v1
36
da beta
ya geçen birkaç şey var ki bunları bilmekte fayda var
Bu bölümde işler biraz değişiyor
In Place Pod Vertical Scaling
Bak şimdi pod’un CPU ya da memory limiti yetmiyor diyelim ne yapıyorsunuz genelde Pod’u öldürüp yeniden yaratıyorsunuz Bu kabul edilir mi Pek değil In Place Pod Vertical Scaling sayesinde pod’u yeniden başlatmadan kaynak limitlerini değiştirebileceksiniz Henüz beta ama baya umut verici duruyor
Bir arkadaşım bunu internal cluster’
ında test etti Java uygulamalarında heap memory artırmak için pod restart gerekmeden ölçekleme yapabilmiş
3 dakikalık downtime sıfıra inmiş Ben ilk duyduğumda pek inanmadım açıkçası ama çalışmış
CBORSerializer API Performansı İçin Yeni Format
Kubernetes API’si şu an JSON kullanıyor biliyorsunuz CBOR Concise Binary Object Representation desteği beta olarak geliyor Bu ne anlama geliyor API çağrıları daha az bant genişliği tüketebilir serialization deserialization kısmı da hızlanabilir Kağıt üstünde güzel pratikte bakalım büyük cluster’
larda mesela
500+
node civarında API server yükünü hissedilir biçimde azaltabilir
Türkiye’deki Kurumsal Müşteriler Için Pratik Tavsiyeler
pratik tavsiyeler
Gelelim asıl meseleye Bu değişiklikler bizi nasıl etkiliyor Türkiye’
deki kurumsal yapılarda Kubernetes kullanımı son
3 yılda ciddi biçimde arttı AKS EKS GKE ya da on premise Rancher OpenShift fark etmiyor her yerde Kubernetes var Ama upgrade disiplini konusunda maalesef hâlâ eksiklerimiz var
Enterprise ile startup ayrımı yapalım
Küçük ekipseniz startup SMB
Ingress NGINX’ten Traefik’e geçin basit ve hızlı externalIPs kullanıyorsanız MetalLB’
ye bakın Sidecar desteğini hemen aktif edin özellikle service mesh kullanıyorsanız Ve en önemlisi Kubernetes sürümünüzü güncel tutun
2 sürüm geride kalmayın
Enterprise seviyedeyseniz önce upgrade impact analysis yapın Deprecated API’
leri tarayan araçlar var
kubent
( Kube No Trouble ) veya
pluto
gibi Bunları CI CD pipeline'a entegre edin Ingress NGINX geçişini proje olarak planlayın minimum
2 sprint ayırın DRA'yı AI ML ekibine tanıtın
# Deprecated API kullanımlarını taramak için:
# kubent kurulumu
curl -sSL https://git.io/install-kubent | sh
# Cluster'inizi tarayın
kubent
# Ornek ciktI:
# >>>
Deprecated APIs found <<
# SERVICE networking.k8s.io/v1beta1 Ingress — v1.22.0
# SERVICE v1 Service externalIPs deprecated v1.36.0
\end{verbatim}Maliyet analizi tarafından da kısa not düşeyim Ingress NGINX'ten AGIC'e geçerseniz Azure Application Gateway maliyeti devreye giriyor Standard_v2 tier'da aylık yaklaşık
200-300 dolar arası sabit maliyet plus kapasite birimi TL bazında düşününce hesap sizin ben rakamın kurdan bağımsız olmadığını biliyorum ama bütçe planlamasında bu kalemi atlamayın
Eğer bütçeniz kısıtlıysa Traefik veya HAProxy Ingress Community Edition ücretsiz sayılır Enterprise support isterseniz Traefik Enterprise ayrı konu ama Community sürümü çoğu senaryoda yeterli olur
v1.36 Için Genel Degerlendirmem
Açık konuşayım v1.36 oyun değiştiren bir sürüm değil Ama doğru yönde atılmış sağlam adımlar barındırıyor Ingress NGINX emekliliği cesur bir karar bazıları kızacak ama güvenlik açısından mantıklı olan bu externalIPs depreciation'u da aynı çizgide uzun süredir bilinen riski kapatıyor
Sidecar native desteğinin GA olması beni en çok sevindiren şeylerden biri oldu Service mesh kullanan herkes bilir sidecar lifecycle management tam anlamıyla baş ağrısıydı Artık değil En azından kağıt üstünde Pratikte birkaç edge case daha çıkar mı Büyük ihtimalle evet Ama yine de ciddi ilerleme
Ha bu arada Kubernetes'te Testi Sola Çekmek: Geçici Ortamlar
ış yazımızda geçici ortamlar konusuna değinmiştik v1.36 upgrade'
ını yapmadan önce mutlaka staging ephemeral ortamda test edin Bu tavsiyeyi ne kadar tekrarlasam az
Bir deDocker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için SQL’e Dönüşün İlk Günü: Konsantrasyon, Notlar, İnat yazımıza bakabilirsiniz.
Ingress NGINX emekli oldu, mevcut deployment'larım çalışmaya devam eder mi?
Evet, mevcut deploy'larınız sorunsuz çalışmaya devam ediyor (ben de ilk duyduğumda şaşırmıştım). Helm chart'lar ve container image'lar erişilebilir kalıyor. Ama artık yeni güvenlik yaması ya da bugfix gelmiyor — açıkçası bu ciddi bir risk. Bu yüzden Traefik, HAProxy veya AGIC gibi alternatif bir ingress controller'a geçişi bir an önce planlamanızı tavsiye ederim.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
externalIPs deprecated olunca yerine ne kullanabilirim?
Cloud ortamdaysanız LoadBalancer tipi Service kullanın, yani cloud provider zaten otomatik olarak external IP atıyor (yanlış duymadınız). On-prem'deyseniz MetalLB veya kube-vip ile LoadBalancer tipi Service'i simüle edebilirsiniz. Bence her iki durumda da geçiş düşündüğünüzden çok daha basit.
v1.36'ya yükseltmeden önce hangi kontrolleri yapmalıyım?
Önce kubent veya pluto ile deprecated API kullanımlarınızı tarayın. Sonra release notes'taki breaking change listesine mutlaka göz atın. Tecrübeme göre staging'de test etmeden geçmeyin — özellikle ingress, service ve RBAC manifest'lerinizi iyi doğrulayın. Bu ne anlama geliyor? Ve son olarak, etcd backup'ını almayı sakın atlamayın.
Sidecar container native desteği tam olarak ne işe yarıyor?
Artık logging agent, proxy veya service mesh sidecar gibi container'ların pod lifecycle'ında resmi bir yeri var. Ana container'dan önce başlıyorlar, ana container kapandıktan sonra da düzgünce sonlanıyorlar. Bu özellikle Istio ve Linkerd gibi service mesh çözümlerindeki race condition sorunlarını büyük ölçüde çözüyor — aslında uzun zamandır beklenen bir şeydi bu.
Kaynaklar ve İleri Okuma
Açıkçası, Kubernetes v1.36 Sneak Peek — Kubernetes Blog
Kubernetes Deprecation Policy — Resmi Dokümantasyon
kubent (Kube No Trouble) — GitHub
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.
