Kubernetes v1.36 ile Gelen Değişiklikler ve Notlarım

Kubernetes’in her yeni sürümü çıkacak diye heyecanla beklediğim bir dönem oldu — sonra o heyecan yavaş yavaş şuna döndü: “Acaba bu sefer neleri kaldırdılar, hangi YAML’larım bozulacak?” Şaka gibi. Gerçek. v1.36 Nisan 2026 sonunda geliyor ve bu sürümde baya hareket var. Hem kaldırılan şeyler var, hem yeni özellikler, hem de “nihayet GA oldu be!” dedirten işler.

Bu yazıda kaynak duyuruyu birebir çevirmeyeceğim; kendi kurumsal projelerimde ve müşterilerde gördüğüm taraftan anlatacağım. Çünkü açık konuşayım, Kubernetes changelog okumak başlı başına iş gibi. Ben sizin yerinize okudum, süzdüm, yorumladım. Evet.

Ingress NGINX Emekliye Ayrıldı: Bu Büyük Olay

Bak şimdi, bu konu beni baya şaşırttı. Yani ingress-nginx projesinin bakımı zorlaşıyordu, güvenlik açıkları geç kapatılıyordu, tamam; ama tamamen emekli olacağını görünce insan bir duruyor. 24 Mart 2026’da SIG-Security resmi duyuruyu yaptı: artık yeni sürüm yok, güvenlik yaması yok, bug fix yok (evet, doğru duydunuz). Nokta.

Mevcut deployment’larınız çalışmaya devam edecek, Helm chart’ları ve container image’ları da hâlâ erişilebilir olacak. Ama — ve burası önemli — yeni bir CVE çıkarsa kimse gelip yamalamayacak. Logosoft’ta bir e-ticaret müşterimizde tam da bunu geçen ay gördük; adam ingress-nginx üzerinde koşuyor, WAF kuralları falan eklemiş, her şey güzel çalışıyor. “Niye değiştirelim ki?” diyor. Haklı gibi duruyor ama değil.

Bir dakika — bununla bitmedi.

Bi saniye — Peki neden? Çünkü sistemin bugün çalışması yetmiyor; yarın ne olacağı da var işin içinde (özellikle internet’e açık katmanda), bir de güvenlik tarafı patladı mı toparlaması tatsız oluyor. İşte burada alternatiflere bakmak gerekiyor.

Alternatif olarak nelere bakmalısınız? İşte kısa bir karşılaştırma:

Ingress Controller	Avantajı	Dikkat Edilecek Kısım
NGINX Gateway Fabric	Gateway API desteği, modern mimari	Henüz olgunlaşma sürecinde
Traefik	Otomatik sertifika, kolay konfigürasyon	Enterprise destek ücretli
Envoy (Contour/Emissary)	Yüksek performans, geniş ekosistem	Öğrenme eğrisi dik
HAProxy Ingress	Düşük latency, kanıtlanmış teknoloji	Topluluk desteği daha dar

Bir bankacılık projesinde Envoy tabanlı Contour’a geçiş yapmıştık 2024 sonunda. İlk hafta biraz sancılı oldu — annotation’ların çoğu farklı çalışıyor, rate limiting mantığı başka;. Alıştığınız düzen biraz dağılıyor. Ama 3 haftada oturdu ve sonrasında geri dönüşü düşünen olmadı.

Küçük ekipseniz Traefik ile başlayın derim; enterprise seviyede Envoy tabanlı çözümler daha sağlam duruyor gibi geliyor bana. Tabii her ortam aynı değil.

externalIPs Alanı Deprecated: Güvenlik Açısından Doğru Hamle

Service spec’indeki .spec.externalIPs alanı deprecated oluyor. Bunu duyan bazı arkadaşlar “ya ne olacak şimdi?” moduna girdi. Dur bir saniye; önce şunu söyleyeyim: bu alan zaten güvenlik açısından sorunlu bir şeydi.

Bak şimdi, Neden mi? Herhangi biri Service’ine rastgele bir external IP atayabiliyordu. Yani cluster içinden “ben şu IP’yim” diyebiliyordunuz ve trafik size akmaya başlıyordu. Man-in-the-middle saldırısı için biçilmiş kaftan gibi düşünün. Biz müşterilerimizde zaten externalip-webhook admission controller ile bunu kısıtlıyorduk; native olarak deprecated olması ise işi daha temiz hale getiriyor.

externalIPs alanını aktif olarak kullanıyorsanız, LoadBalancer tipi Service veya MetalLB gibi çözümlere geçişinizi şimdiden planlayın. Deprecation “bir gün kaldırılacak” demek — o gün geldiğinde hazırlıksız yakalanmak istemezsiniz.

Neyse uzatmayalım; Türkiye’deki şirketler açısından bakınca özellikle on-premise Kubernetes kuran firmalar bu alanı baya kullanıyor. Çünkü cloud load balancer yok, MetalLB kurmak ekstra iş gibi görünüyor, en kolay yol externalIPs oluyor (en azından benim deneyimim böyle)

Ve işler burada ilginçleşiyor.

Anladığım kadarıyla 1-2 sürüm daha çalışacak ama artık uyarı verecek. O uyarıyı gören mühendis “tamam sonra bakarım” demesin lütfen; sonra bakarım işleri hep son dakika paniğine dönüyor.

Yeni Özellikler: Neler Geliyor?

Nereden çıktı bu pod resize işi?

This one is actually good news diyebilirim. Türkçesiyle söyleyeyim: In-Place Pod Resource Resizing beni en çok heyecanlandıran şeylerden biri oldu.
Pod’unuzun CPU veya memory limitini değiştirmek istediğinizde eskiden ne yapıyorduk? Pod’u silip yeniden yaratıyorduk; yani ortada gerçekten “resource update” diye kullanılabilir bir şey yoktu.

Sorun şuydu: küçük değişiklik için bile rolling restart gerekiyordu (ve bazen sırf bunun için gece operasyonu açılıyordu). Artık pod çalışırken kaynak limitlerini güncelleyebileceksiniz.

Emin değilim ama sanırım çoğu ekip bunu ilk başta hafife alacak; sonra canlıda RAM sıkışınca değeri ortaya çıkacak.

Geçen yıl bir telekom müşterimizde Java uygulaması vardı — gece batch işleri çalışırken dört GB RAM yetmiyordu, gündüz ise 2 GB yeterliydi.
Adam ne yapsın? Ya hep 4 GB ayıracaksınız (israf), ya da gece restart atacaksınız (downtime); ikisi de can sıkıyor.
In-place resize ile bu dert baya azalıyor.

Aslında, Tabi henüz her container runtime tam desteklemiyor, containerd tarafında bazı edge case’ler var ama doğru yönde atılmış fena olmayan bir adım diyebilirim.

Bazı kurallar artık webhook’suz gelebiliyor mu?

Evet geliyor; CEL tabanlı ValidatingAdmissionPolicy iyice olgunlaşıyor.
Eskiden her admission kontrolü için ya OPA/Gatekeeper kuracaktınız ya da kendi webhook’unuzu yazacaktınız.
Şimdi CEL (Common Expression Language) ile doğrudan Kubernetes API’si üzerinden policy tanımlayabiliyorsunuz.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: deny-privileged-containers
spec:
matchConstraints:
resourceRules:
— apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
validations:
— expression: "!object.spec.containers.exists(c, c.securityContext.priviliged == true)"
message: "Privileged container'lar yasaklandı!"

Sıkça Sorulan Sorular

Kubernetes v1.36 ne zaman çıkıyor?

Nisan 2026’nın sonlarında geliyor. Kesin tarih henüz belli değil ama aslında genellikle ayın son haftasına denk geliyor. Release candidate sürümlerini şimdiden test edebilirsiniz — bence erken bakmanın zararı yok.

Ingress-nginx kullanıyorum, hemen değiştirmem şart mı?

Hayır, mevcut kurulumunuz çalışmaya devam ediyor, panikleyecek bir şey yok (kendi tecrübem). Ama şunu unutmayın: artık güvenlik yaması gelmeyecek. Tecrübeme göre bu — kendi adıma konuşayım — tür geçişleri erteledikçe daha da zorlaşıyor — yani 3-6 ay içinde bir alternatif ingress controller’a geçişi planlamaya başlayın. Gateway API destekleyen çözümlere yönelmek mantıklı olur (bizzat test ettim)

Hmm, bunu nasıl anlatsamdı…

In-place pod resizing production’da kullanılabilir mi?

v1.36’da beta aşamasında olacak. Yani varsayılan olarak açık geliyor ama production-critical workload’larda açıkçası dikkatli olmakta fayda var. Önce staging’de deneyin. Bir de containerd 1.7+ gerekiyor, container runtime uyumluluğunu mutlaka kontrol edin.

Sürüm atlayarak upgrade yapabilir miyim?

Şunu söyleyeyim, Resmi olarak desteklenen yol sıralı upgrade — mesela 1.34’ten 1.36’ya geçmek istiyorsanız önce 1.35’e çıkmanız gerekiyor. Sürüm atlamak teknik olarak bazen çalışıyor, ama desteklenmiyor. Production’da bence kesinlikle denemeyin.

AKS kullanıyorsam bu değişiklikler beni ne zaman etkiler?

Azure AKS genellikle upstream release’den 2-4 hafta sonra yeni sürümü desteklemeye başlıyor. Otomatik upgrade açıksa dikkat edin — hani staging channel’da preview olarak daha erken de gelebiliyor. Auto-upgrade policy’nizi bir gözden geçirin, sürprizle karşılaşmayın.

Kaynaklar ve İleri Okuma

İşin garibi, Kubernetes v1.36 Sneak Peek — Resmi Blog Duyurusu

Küçük bir detay: Kubernetes Deprecation Guide — Resmi Dokümantasyon

AKS Desteklenen Kubernetes Sürümleri — Microsoft Docs (en azından benim deneyimim böyle)