Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor?

⏱️ 9 dk okuma📅 14 Nisan 2026👁️ görüntülenme

Geçen hafta bir müşterimle oturmuştum — büyük bir e-ticaret firması, ismini vermeyeyim tabii — Kubernetes cluster upgrade planlaması yapıyorduk. Adam bana döndü, “Aşkın abi, biz daha 1.31’e geçemedik, sen 1.36’dan bahsediyorsun” dedi. Haklı aslında. Haksız değil. Ama işin gerçeği şu ki eğer bu sürümde gelen değişiklikleri şimdiden bilmezseniz, Nisan 2026 sonunda cluster’ınız canınızı gerçekten yakabilir — ve “biz bilmiyorduk” diye bir mazeretiniz kalmayacak, çünkü şu an okuyorsunuz.

Kubernetes v1.36, Nisan 2026 sonunda çıkacak. Dolu bir sürüm geliyor bu sefer — ciddi anlamda dolu. Hem kaldırılan şeyler var, hem deprecated olan API’ler var, hem de — açık konuşayım — beni gerçekten heyecanlandıran birkaç yenilik var. Gelin bir bakalım.

Önce Acı Haberleri Verelim: Kaldırılanlar ve Deprecation’lar

Kubernetes’in deprecation politikası aslında bayağı disiplinli bir süreç işliyor. Stable API’ler ancak yerine yenisi geldiğinde deprecated işaretleniyor, beta API’ler en az 3 sürüm daha destekleniyor, alpha API’ler işe — vay hâline — herhangi bir sürümde habersiz kaldırılabiliyor. Bunu bilmek önemli. Neden mi? Çünkü production’da alpha feature gate açık bırakan insanlar gördüm — cidden, hayali değil. 2024’te bir finans kuruluşunda tam olarak bu yüzden upgrade sonrası 4 saatlik kesinti yaşandı ve o toplantıya girmek hiç keyifli olmadı, inanın.

Service’lerdeki externalIPs Alanı Deprecated Oluyor

Bu beni şaşırtmadı açıkçası. .spec.externalIPs zaten yıllardır güvenlik açısından tartışmalıydı. Şöyle düşünün: herhangi bir namespace’teki herhangi bir kullanıcı, istediği harici IP’yi Service’ine yönlendirebiliyordu. MitM saldırılarına kapı açıyordu bu durum, hem de fena hâlde. Logosoft’ta bir bankacılık projesinde bu alanı zaten admission webhook ile bloke ediyorduk — artık Kubernetes kendisi diyor ki “bu iş bitti.”

Bunu biraz açayım.

Peki ne yapacaksınız? Birkaç alternatif var:

LoadBalancer tipi Service — cloud provider’ınız varsa en temiz yol
MetalLB veya benzeri bare-metal load balancer — on-prem’deyseniz
Gateway API — yeni nesil yaklaşım, buna birazdan değineceğim

Açıkçası, Hâlâ externalIPs kullanıyorsanız şimdilik çalışmaya devam edecek, loglarınızda warning göreceksiniz yalnızca. Ama ertelemeyin derim. Bir gün warning değil error olacak — o günü beklemek zorunda değilsiniz.

Ingress NGINX Emekliye Ayrıldı

Bak, bu büyük haber. 24 Mart 2026’da SIĞ Network ve Security Response Committee, Ingress NGINX projesini resmen emekliye ayırdı. Artık yeni release yok. Bugfix yok. Güvenlik yaması yok. Mevcut deployment’larınız çalışmaya devam edecek, Helm chart’ları ve container image’ları erişilebilir kalacak ama… yeni bir CVE çıkarsa kimse düzeltmeyecek. Kimse.

Çok konuştum, örnekle göstereyim.

Açıkçası, Dur bir saniye, şunu netleştireyim — bu Ingress kavramının ölmesi değil. Ingress NGINX projesi retire oluyor, yanı bakımı yapan ekip “biz artık yapmıyoruz” diyor. Alternatifler var ve bayağı olgun durumda:

Alternatif	Avantaj	Dikkat Edilecek
Traefik	Gateway API desteği iyi, dashboard güzel	Enterprise lisans gerekebilir
Envoy / Contour	CNCF projesi, yüksek performans	Konfigürasyon öğrenme eğrisi var
HAProxy Ingress	HAProxy güvenilirliği, düşük latency	Topluluk daha küçük
Cilium Gateway	eBPF tabanlı, network policy entegrasyonu	Kernel gereksinimleri yüksek

Benim tavsiyem şu: yeni bir proje başlıyorsanız direkt Gateway API’ye yönelin. Mevcut Ingress NGINX kurulumunuz varsa panik yapmayın ama 6 ay içinde geçiş planı yapın. Bir arkadaşım geçen ay Traefik’e geçti, 2 günde halletti — ama annotation’ları tek tek çevirmek zorunda kaldı. O kısım can sıkıcı, uyarıyorum.

Gateway API: Artık Tam Gaz

Kubernetes 1.36 ile Gateway API olgunlaşmaya devam ediyor. Nasıl desem… Ingress’in “yeni nesil versiyonu” gibi düşünebilirsiniz ama çok daha esnek. Role-based bir yapı var: altyapı ekibi Gateway’i tanımlıyor, uygulama ekibi HTTPRoute’u tanımlıyor. Sorumluluklar net ayrılıyor, tartışma azalıyor — bu ikinci kısım bence en güzel yanı.

2025 başında AKS üzerinde Gateway API’yi ilk test ettiğimde biraz ham bulduydum, itiraf edeyim. Ama son bir yılda ciddi yol kat etti. Mesela gRPC routing ve TLS passthrough konularında artık production-ready diyebiliyorum gönül rahatlığıyla.

Ingress NGINX’ten Gateway API’ye geçiş yapıyorsanız, annotation tabanlı konfigürasyonlarınızı Gateway ve HTTPRoute resource’larına çevirmeniz gerekecek. Bu birebir eşleme değil — bazı şeyleri yeniden düşünmeniz gerekiyor.

Node Lifecycle ve Graceful Shutdown İyileştirmeleri

Kubernetes 1.36’da node lifecycle tarafında güzel şeyler var. Graceful node shutdown mekanizması daha da iyileştirilmiş. Bu konu benim için özel bir yere sahip. 2023’te bir telekomda yaşadığımız olay hâlâ aklımda: rolling update sırasında pod’lar düzgün terminate olmadı, graceful shutdown süresi yetmedi, müşterinin real-time streaming servisi 12 dakika kesintiye girdi. On iki dakika. O günden beri terminationGracePeriodSeconds değerini her projede dikkatle ayarlıyorum — artık göz ardı edemiyorum. Daha fazla bilgi için Copilot Cloud Agent Doğrulama Araçları %20 Hızl… yazımıza bakabilirsiniz.

Bu sürümde gelen iyileştirmelerden biri, kubelet’in node shutdown sırasında pod’lara daha düzgün sinyal göndermesi. En çok da priority class’lara göre sıralı shutdown artık daha güvenilir çalışıyor. Küçük bir startup için bu çok kritik olmayabilir — 3-5 pod’unuz var, hepsi hızlı kapanıyor, tamam. Ama enterprise seviyede, yüzlerce pod’un koordineli şekilde kapanması gerektiğinde bu iyileştirme hayat kurtarıcı, gerçekten.

Güvenlik Tarafında Neler Var?

Hmm, bir düşüneyim… Evet, birkaç önemli şey var. Pod Security Standards tarafında sıkılaştırmalar devam ediyor. Restricted profili artık daha fazla edge case’i kapsıyor.

Structured Authorization Configuration

Bu feature 1.36’da GA oluyor. Stable yanı. Ne işe yarıyor? Authorization modüllerini — RBAC, — ki bu tartışılır — webhook, node authorizer — sıralı bir chain olarak tanımlayabiliyorsunuz. Tek bir --authorization-configuration dosyasıyla birden fazla authorizer’ı sıralı çalıştırabiliyorsunuz. Bu da şu anlama geliyor: mesela önce RBAC baksın, eğer karar veremezse custom webhook’a gitsin gibi senaryolar artık çok daha temiz yapılabiliyor, eskisi gibi yamalarla değil.

# Örnek authorization configuration (kısaltılmış)
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthorizationConfiguration
authorizers:
— type: Webhook
name: custom-authz
webhook:
timeout: 3s
subjectAccessReviewVersion: v1
matchConditionSubjectAccessReviewVersion: v1
failurePolicy: Deny
connectionInfo:
type: KubeConfig
kubeConfigFile: /etc/kubernetes/authz-webhook.kubeconfig
— type: RBAC
name: rbac

AZ-500 sınavına hazırlanırken Azure’daki conditional access policy zincirlerini çalışmıştım — bu yapı bana önü anımsattı. Benzer mantık: sıralı değerlendirme, ilk eşleşen kazanır. Ya da hepsi geçerse izin verilir. Güzel bir yaklaşım, sevinçle karşıladım. Bu konuyla ilgili GitHub Copilot CLI Nedir ve Nasıl Kurulur: İlk … yazımıza da göz atmanızı tavsiye ederim.

Bound Service Account Token İyileştirmeleri

Vallahi, Service account token’larının audience ve expiry kontrolü artık daha sıkı. Eskiden token bir kere (belki yanılıyorum ama) oluşturulur, süresiz kullanılırdı — büyük bir güvenlik açığıydı bu, açıkçası utanç vericiydi. Şimdi projected volume ile otomatik rotate eden, süreli token’lar standart hâle geliyor. İlginç, değil mi? Bunu zaten 1.33’ten beri kullanabiliyordunuz ama 1.36’da bazı edge case bugfix’leri gelmiş.

💡 Bilgi: Eğer hâlâ legacy service account token’ları (Secret tabanlı) kullanıyorsanız, Kubernetes 1.36 ile birlikte bunların auto-generation’ı neredeyse tamamen kaldırılmış olabilir. Kontrol edin ve projected volume’a geçin. Yoksa upgrade sonrası pod’larınız authenticate olamayabilir.

Scheduling ve Resource Management Yenilikleri

İşin garibi, Scheduler tarafında da ilginç şeyler var. Benim en çok ilgimi çeken konuya gelelim: Dynamic Resource Allocation, yanı DRA. Bu özellik 1.36’da beta’ya yükseldi. GPU, FPGA gibi özel donanım kaynaklarını pod’lara atamak için çok daha esnek bir mekanizma sunuyor.

Dürüst olmak gerekirse, Şimdiye kadar device plugin API’si ile bu işi yapıyorduk ama o sistem bayağı kısıtlıydı. Mesela “şu pod’a tam olarak şu modelden 2 GPU ver” gibi spesifik istekleri karşılamak zordu — gereksinimleri tam tutturmak neredeyse imkânsızdı bazen. DRA ile bu çok daha kolay hâle geliyor. Sız hiç denediniz mi? İşte, küçük bir startup için belki gereksiz, ama AI/ML workload’ları çalıştıran enterprise’lar için bu büyük bir adım.

Ha bu arada — scheduler performance tarafında da iyileştirmeler var. Büyük cluster’larda, yanı 5000+ node ortamlarında, scheduling latency’si düşürülmüş. Logosoft’ta genelde 50-200 node arası cluster’larla çalışıyoruz, o yüzden bu bizi doğrudan etkilemiyor. Neden önemli bu? Ama büyük bulut sağlayıcıları için önemli bir gelişme olduğu kesin. Bu konuyla ilgili .NET Agent Skills: Üç Yöntem, Tek Sağlayıcı yazımıza da göz atmanızı tavsiye ederim.

Durun, bir saniye. Bu konuyla ilgili ChatGPT ile Araştırma: Search ve Deep Research … yazımıza da göz atmanızı tavsiye ederim.

Observability: Daha İyi Görünürlük

Kubernetes 1.36’da tracing ve metrics tarafında da iyileştirmeler gelmiş. Bilhassa API server’ın OpenTelemetry tracing desteği artık daha olgun (evet, doğru duydunuz). Structured logging de stable’a yaklaşıyor, yavaş yavaş. GitHub Pages ile Ücretsiz Site Kurulumu: Tam Re… yazımızda bu konuya da değinmiştik.

Bir de şunu söyleyeyim: kubectl debug komutu artık daha yetenekli. Ephemeral container desteği genişletilmiş. Production’da debug yapmak hâlâ zor bir iş — bunu kimse inkâr etmesin. Ama en azından araçlar iyileşiyor. Geçen ay bir müşteride CrashLoopBackOff’a düşen bir pod’u debug etmek için 45 dakika uğraştık (şaşırtıcı ama gerçek). kubectl debug olmasaydı belki 2 saat sürerdi. Belki daha da fazla.

Bu konuda Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle yazımda bahsettiğim güvenlik tarama yaklaşımları, Kubernetes workload’ları için de geçerli. Container image scanning ve runtime güvenliği birlikte düşünülmeli — birini atlayınca diğeri tek başına yetmiyor.

Upgrade Stratejisi: Ne Zaman, Nasıl?

Küçük bir detay: Her Kubernetes sürümünde aynı soruyu alıyorum: “Hemen upgrade edelim mi?” Cevabım çoğu zaman aynı: hayır. En az 2-3 patch release bekleyin. Yanı 1.36.0 çıkınca atlayın, 1.36.3 veya 1.36.4’ü bekleyin — o versiyonlarda ilk dalgaların hataları temizlenmiş olur genelde.

Ama hazırlıklara şimdiden başlayın. Hele bir de şunları yapın:

externalIPs kullanan Service’lerinizi tespit edin
Ingress NGINX kullanıyorsanız alternatif değerlendirmesine başlayın
Deprecated API kullanımınızı kubectl api-resources ve audit log’lardan kontrol edin — ha pardon, kubectl deprecations diye resmî bir komut yok, bunu şimdiden söyleyeyim
Staging ortamında 1.36 beta’yı test edin

Az önce “hemen upgrade etmeyin” dedim ama aslında çok eski sürümlerde kalmak da tehlikeli — bunu da ekleyeyim (bizzat test ettim). Kubernetes sadece son 3 minör sürümü destekliyor. Yanı 1.36 çıktığında 1.33 altı artık destek dışı kalacak. Bu dengeyi iyi kurmak lazım. Eğer CI/CD pipeline’larınızı düzgün kurduysanız — mesela GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısında bahsettiğim gibi otomasyon sınırlarını biliyorsanız — upgrade süreciniz çok daha pürüzsüz olur.

Genel Değerlendirmem

Kubernetes 1.36 benim gözümde “temizlik + olgunlaşma” sürümü. Çığır açan yeni bir özellik yok belki. Ama mevcut özellikler stabilize oluyor, güvenlik sıkılaşıyor, eski borçlar temizleniyor — bu da az şey değil. Ingress NGINX’in retirement’ı büyük bir milestone, yıllardır herkesin kullandığı bir bileşen gidiyor. Ama yerine gelen Gateway API daha iyi bir çözüm. İlginç, değil mi? Buna itiraz edemiyorum.

Bunu biraz açayım.

Hayal kırıklığım mı? DRA’nın hâlâ GA olmaması. Beta’da kalması… Yanı anlıyorum, karmaşık bir özellik. Ama GPU workload’ları artık o kadar yaygın ki bu özelliğin stable olması gerekiyordu bence. Belki 1.37’de. Göreceğiz artık.

Neyse, uzatmayalım. Kubernetes dünyası durmadan dönüyor ve biz de dönmeye devam ediyoruz. Sız de upgrade planlamanızı şimdiden yapın, son dakikaya bırakmayın.

Sıkça Sorulan Sorular

Kubernetes 1.36 ne zaman çıkacak?

Bunu yaşayan biri olarak söyleyeyim, Nisan 2026 sonunda çıkması planlanıyor. Ama her zaman olduğu gibi birkaç hafta kayma olabilir. Release takvimini kubernetes.io üzerinden takip edin. İlk patch release’i bekleyip öyle upgrade etmenizi öneririm.

Ingress NGINX kullanıyorum, hemen değiştirmem gerekiyor mu?

Panik yapmayın, mevcut kurulumunuz çalışmaya devam edecek. Ama artık güvenlik yaması gelmeyecek, bu çok önemli. 3-6 ay içinde Traefik, Envoy veya Gateway API tabanlı bir çözüme geçiş planı yapmanızı şiddetle tavsiye ederim.

externalIPs deprecated oldu, ne kullanmalıyım?

Cloud ortamındaysanız LoadBalancer tipi Service kullanın. On-prem’deyseniz MetalLB iyi bir alternatif. Uzun vadede Gateway API’ye yönelmek en sağlıklısı (inanın bana). externalIPs şimdilik çalışacak ama gelecek sürümlerde kaldırılacak.

Kubernetes 1.36’ya upgrade etmeden önce ne kontrol etmeliyim?

İlginç olan şu ki, Öncelikle deprecated API kullanımınızı audit log’lardan kontrol edin. externalIPs ve Ingress NGINX bağımlılıklarınızı tespit edin. Staging ortamında test edin. Ve büyük ihtimalle etcd backup alın — bu her upgrade’de altın kural.

Dynamic Resource Allocation (DRA) production’da kullanılabilir mi?

1.36’da beta seviyesinde. Yanı kullanabilirsiniz ama API değişebilir. GPU/FPGA ihtiyacınız yoksa şimdilik beklemeniz mantıklı. AI/ML workload’ları çalıştırıyorsanız staging’de test edip değerlendirin ama production’da dikkatli olun.