Kubernetes v1.37 Ön İzleme: Kaldırılanlar ve Yenilikler

⏱️ 4 dk okuma📅 1 Ağustos 2026

Kubernetes v1.37 sürümünün yayın tarihi yaklaşırken projede planlanan kaldırma, kullanımdan kaldırma (deprecation) ve yeni yeteneklere dair bir ön izleme paylaşıldı. Aşağıdaki notlar sürümün mevcut durumunu yansıtıyor ve resmi yayına kadar değişebilir. Küme yöneticileri açısından ayar geçişlerini önceden planlamak, sürüm çıktığında sürprizle karşılaşmamak için belirleyici.

v1.37 ile gelen kullanımdan kaldırmalar

kubectl run için –filename bayrağı

kubectl run komutundaki --filename (kısaca -f) bayrağı kullanımdan kaldırılıyor. Gerekçe basit: Bu komutun ürettiği Pod her durumda NAME ve --image gibi CLI argümanlarından oluşturuluyor, dolayısıyla dosyadan okuma seçeneğinin anlamlı bir işlevi yoktu. Tartışmanın ayrıntıları için kubernetes/kubernetes#138671 numaralı konuya bakılabilir.

Static Pod’lar artık Secret ve ConfigMap referansı veremez

Static Pod’lar tanım gereği API server üzerinden oluşturulmadıkları için API kaynaklarını doğrudan okumamalıydı. Ancak bir hata nedeniyle configMapRef veya secretRef gibi alanlar üzerinden Secret ya da ConfigMap referansı verilebiliyordu. v1.37 ile bu davranış kesin biçimde yasaklanıyor; kısıtlamayı devre dışı bırakmayı sağlayan PreventStaticPodAPIReferences özellik kapısı (feature gate) da kaldırıldı. Ayrıntılar için kubernetes/kubernetes#140226 konusuna göz atın.

kube-proxy’nin ipvs modu kullanımdan kaldırılıyor

kube-proxy için ipvs desteği v1.8’de, iptables tarafındaki performans darboğazlarını gidermek amacıyla eklenmişti. Ne var ki çekirdeğin ipvs API’si tek başına Kubernetes Service semantiğini karşılamaya yetmediğinden, ipvs modu arka planda yine iptables kullanmaya devam ediyor. Bu durum KEP-3866 içinde “ipvs modu bizi kurtarmayacak” biçiminde ifade ediliyor.

v1.37 itibarıyla ipvs modunda çalışan (veya KubeProxyConfiguration içinde mode: ipvs tanımlı) kümeler başlangıçta bir deprecation uyarısı yazacak. Planlanan takvim şöyle:

v1.40’ta ipvs modunun varsayılan olarak devre dışı bırakılması (feature gate ile seçilebilir kalacak) bekleniyor.
v1.43’te ipvs desteğinin tamamen kaldırılması hedefleniyor.

Hangi modda çalıştığınızı kontrol etmek için:

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

Kararın gerekçelerini KEP-5495 içinde bulabilirsiniz.

Devam eden büyük değişiklikler

cgroup v1 desteğinin kaldırılması yaklaşıyor

Modern Linux dağıtımları ve konteyner çalışma zamanları varsayılan olarak cgroup v2 kullandığı için eski cgroup v1 desteği aşamalı olarak kaldırılıyor. v1.35 sürümünden itibaren failCgroupV1 ayarı varsayılan olarak true. Bu nedenle cgroup v1 üzerinde çalışan düğümlerde kubelet, açık bir yapılandırma geçersiz kılınmadıkça başlatılamıyor.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false  # geçici geçersiz kılma

Bu geçici çözüm v1.37’de hala mevcut ama kalıcı bir çözüm değil. In-Place Pod Resizing ve Tiered Memory Protection gibi ileri kaynak yönetimi yetenekleri tamamen cgroup v2’ye dayanıyor. Cgroup v1 desteğinin gelecek bir sürümde tamamen kaldırılması planlanıyor; ayrıntılar KEP-5573 içinde.

v1.37’deki kırıcı değişiklik: SELinuxMount GA

SELinux volume relabeling özelliğinin (“SELinuxMount”) v1.37’de GA seviyesine ulaşması ve varsayılan olarak etkinleşmesi bekleniyor. Bu durumda birimler, özyinelemeli olarak yeniden etiketlenmek yerine -o context=<label> mount seçeneğiyle bağlanacak. Ancak bu davranış, yalnızca ilgili CSI sürücüsünün CSIDriver nesnesinde .spec.seLinuxMount: true ayarını açıkça etkinleştirmesi durumunda geçerli olacak.

Tek bir mount tek bir SELinux bağlamı taşıyabildiğinden, farklı SELinux etiketlerine sahip Pod’ların aynı düğümde aynı volume’u paylaştığı senaryolar (özyinelemeli etiketleme sayesinde önceden çalışabiliyordu) artık başlatılamayabilir. Belirli bir iş yükü için eski davranışı korumak istiyorsanız Pod spec içinde seLinuxChangePolicy: Recursive tanımlayabilirsiniz. SELinux etkin olmayan kümeler bu değişiklikten etkilenmiyor. Konunun daha ayrıntılı ele alındığı yazı için SELinux Volume Label Changes goes GA makalesine bakabilirsiniz.

Öne çıkan yeni yetenekler

Metrics API GA seviyesine ulaşıyor

metrics.k8s.io API’sinin, Beta aşamasında yaklaşık dokuz yıl kaldıktan sonra Kubernetes v1.37 ile Stable (GA) seviyesine yükselmesi bekleniyor. Bu API, Pod ve düğümlerin CPU ile bellek kullanımlarını almak için standart bir yol sağlıyor; Horizontal Pod Autoscaler (HPA) ile kubectl top gibi yaygın kullanılan özelliklerin altında da bu API çalışıyor.

Geçişte işlevsel bir değişiklik beklenmiyor; hem v1 hem de v1beta1 kullanılmaya devam edilebilecek. Böylece geliştiriciler kendi hızlarında stabil sürüme geçebilecek. Daha fazla bilgi için KEP-5207 incelenebilir.

Kubelet User Namespace (Rootless) modu Beta’ya yükseliyor

Geleneksel olarak kubelet gibi Kubernetes düğüm bileşenleri host üzerinde root ayrıcalıklarıyla çalışıyor. Bu da bileşenlerdeki bir açığın alt sistemi geniş biçimde etkileme olasılığını beraberinde getiriyor.

Kubernetes v1.37’de kubelet’in Linux user namespace içinde, host üzerinde ayrıcalıksız bir kullanıcı olarak çalışıp namespace içinde root gibi davranmasını sağlayan Rootless Mode’un Beta’ya yükselmesi bekleniyor. Bu yaklaşım host seviyesindeki root ihtiyacını azaltıyor, düğüm bileşenlerini etkileyebilecek olası açıkların etkisini sınırlamayı hedefliyor. Ayrıntı için KEP ile birlikte konuyla ilgili KEP-2033 belgesine başvurulabilir.

Volume Health Monitor

Kubernetes tarihsel olarak CSI sürücülerinin depolama arızalarını raporlayabileceği bir API’den yoksundu; sorunlar yalnızca başarısız mount’lar veya asılı I/O ile fark edilebiliyordu. İyileştirme kontrolörlerinin makinece okunabilir bir veri kaynağı olmadığı için kök neden analizi, Kubernetes nesneleri ile harici satıcı panolarını çapraz okumayı gerektiriyordu.

Kubernetes v1.37 ile bu KEP, v1.21’deki ilk uygulamanın ardından Alpha aşamasına yeniden başlatılıyor ve dört yeni CSI RPC’si tanıtılıyor. Kontrolör tarafındaki eklenti, birimlerin sağlığını ControllerListVolumeHealth (sağlıksız birimleri listeler) ve ControllerGetVolumeHealth (belirli bir birimi denetler) üzerinden raporluyor. Kontrolör tarafındaki bir sağlık izleyici bu CSI kontrolörlerini yokluyor ve sonuçları PersistentVolumeClaim.status.healthStatus alanında saklıyor.

Düğüm tarafında ise kubelet, o düğümdeki tekil birimlerin sağlığını NodeGetVolumeHealth ile alıp Pod.status.volumeHealth alanına yazıyor. NodeGetStorageHealth ise düğüme kayıtlı sürücülerin sağlığını CSINode.status.storageHealth içinde raporluyor.

Hata sözlüğü sade, genişletilebilir ve makinece ayrıştırılabilir tutulmuş (Inaccessible, Degraded gibi); sürücüye özgü açıklamalar için reason ve message alanları kullanılabiliyor. Kontrolör ve düğüm tarafı raporları birbirinden bağımsız tutuluyor ve ayrı ayrı gösteriliyor; böylece depolama sağlığına daha bütüncül bakılabiliyor. Daha fazlası için KEP-1432: Volume Health Monitor belgesine göz atabilirsiniz.

Kaynaklar ve İleri Okuma

kubernetes.dev

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ÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102