Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor?
Geçen hafta bir müşterimle oturmuştum — büyük bir e-ticaret firması, ismini vermeyeyim tabiî — 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.
📋 İçindekiler
- Önce Acı Haberleri Verelim: Kaldırılanlar ve Deprecation’lar
- Gateway API: Artık Tam Gaz
- Node Lifecycle ve Graceful Shutdown İyileştirmeleri
- Güvenlik Tarafında Neler Var?
- Scheduling ve Resource Management Yenilikleri
- Observability: Daha İyi Görünürlük
- Upgrade Stratejisi: Ne Zaman, Nasıl?
- Genel Değerlendirmem
- Sıkça Sorulan Sorular
- Kaynaklar ve İleri Okuma
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ızlandı 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 Adımlar 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ş.
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 Rehberi 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 Rehber 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-resourcesve audit log’lardan kontrol edin — ha pardon,kubectl deprecationsdiye 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 öldü, 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.
Kaynaklar ve İleri Okuma
Kubernetes v1.36 Sneak Peek — Resmî Kubernetes Blog
Açıkçası, Kubernetes Deprecated API Migration Guide
Kubernetes Gateway API Resmî Dokümantasyonu
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