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
-
Bir de şunu söyleyeyim:
kubectl debugkomutu 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
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Oğuz L.
externalIPs’in deprecated olması biraz sürpriz oldu açıkçası, legacy sistemlerde kullananlar için geçiş süreci epey uğraştırıcı olabilir. Nisan 2026’ya kadar zaman var ama production ortamlarında bu değişiklikleri test etmek için erkenden başlamak lazım.
Berk N.
Service’lerde externalIPs’in deprecated olması beni biraz düşündürdü, özellikle on-prem kurulumlarında bunu yoğun kullananlar için geçiş süreci nasıl olacak acaba? Nisan 2026 çok uzak değil, migration planlamasına erkenden başlamak lazım.
Serkan D.
externalIPs’in deprecated olması beni biraz şaşırttı açıkçası, production ortamında kullanan ekipler için geçiş süreci sancılı olabilir. Nisan’a kadar mevcut cluster’ları gözden geçirmek lazım.
Yorumlar kapalı.
3 comments