Kubernetes 1.37 "Garhwal" Yenilikleri: KYAML, Pod Certificates, PVC Son Kullanım ve Yükseltme Rehberi

v1.37'de neler var? (Release highlights)

Kubernetes yılda üç sürüm çıkarıyor. Nisan'daki v1.36'nın ardından gelen v1.37, adını Hindistan'ın Uttarakhand eyaletindeki Himalaya bölgesi Garhwal'dan alıyor. Önceki sürümün öne çıkan teması yapay zekâ iş yükleri ve güvenlik varsayılanlarıydı. Bu sürüm ise operasyon tarafındaki küçük ama can sıkıcı sorunlara odaklanıyor: YAML hataları, sertifika yönetimi, unutulan diskler ve büyük kümelerde bellek kullanımı.

Aşama	Sayı	Öne çıkanlar
Kararlı (GA)	16	KYAML, Pod Certificates, Storage Version Migration, DRA cihaz taint'leri
Beta	23	PVC son kullanım zamanı, Pod-Level Resource Managers, Native Histograms, Memory QoS, rootless kubelet
Alfa	27	Yerinde boyutlandırma için önalım (preemption), CompositePodGroup, etcd RangeStream

KYAML: girinti hatasına son (KEP-5295, Stable)

YAML'ın en bilinen sorunu girintiye dayalı olması. Bir boşluk kayarsa alan başka bir nesnenin içine düşer ve hata vermeden yanlış çalışır. Tırnaksız yazılan no, on veya 0123 gibi değerler beklenmedik tiplere dönüşür. Ünlü "Norveç sorunu", ülke kodu NO'nun false olarak okunmasıdır.

KYAML, YAML'ın katı bir alt kümesi. Dizeler her zaman çift tırnaklı, iç içe yapılar girinti yerine süslü ve köşeli parantezle belirtiliyor. Yine de geçerli YAML olduğu için mevcut araçlarınız okumaya devam ediyor:

$ kubectl get service hostnames -o kyaml

{
  apiVersion: "v1",
  kind: "Service",
  metadata: {
    name: "hostnames",
  },
}

Sondaki virgüllere izin verildiği için satır ekleyip çıkarmak diff'te tek satırlık değişiklik olarak görünüyor. Helm şablonlarında ve kopyala-yapıştır ile çoğaltılan manifest'lerde girinti hatalarını büyük ölçüde ortadan kaldırıyor.

Pod Certificates: sidecar'sız mTLS (KEP-4317, Stable)

Pod'lar arasında karşılıklı TLS (mTLS) kurmak için genellikle bir servis ağı (service mesh) ya da cert-manager gibi ek bileşenler kuruluyordu. v1.37 ile kubelet, pod'a ait sertifikayı ve özel anahtarı projected volume üzerinden kendisi üretiyor ve süresi dolmadan yeniliyor:

volumes:
  - name: spiffe-creds
    projected:
      sources:
        - podCertificate:
            signerName: "mysigner.example/spiffe"
            keyType: ED25519
            credentialBundlePath: credentialbundle.pem

Sertifikayı imzalayacak bir imzalayıcı (signer) denetleyicisi hâlâ sizin sorumluluğunuzda. Kubernetes yalnızca isteği, dağıtımı ve rotasyonu standartlaştırıyor. Bununla birlikte gelen Cluster Trust Bundles, güvenilen kök sertifikaları kümeye dağıtmanın standart yolunu sunuyor.

PVC son kullanım zamanı: unutulan diskleri bulun (Beta)

Bulut faturalarında sık görülen kalemlerden biri, silinmiş uygulamalardan kalan ve hiçbir pod'un bağlı olmadığı kalıcı diskler. v1.37 ile PersistentVolumeClaim nesnesine standart bir Unused durumu ekleniyor:

status:
  conditions:
    - type: Unused
      status: "True"
      reason: NoPodsUsingPVC
      message: No pods are currently referencing this PVC
      lastTransitionTime: "2026-01-20T10:30:00Z"

lastTransitionTime diskin ne zamandan beri boşta olduğunu gösteriyor. Böylece "30 günden uzun süredir kullanılmayan PVC'leri listele" gibi bir temizlik betiği yazmak kolaylaşıyor. Silmeden önce yedek almayı unutmayın: bir PVC'nin kullanılmaması, içindeki verinin değersiz olduğu anlamına gelmez.

Pod seviyesinde kaynak yöneticileri (Pod-Level Resource Managers, Beta)

Kaynak istekleri ve sınırları bugüne kadar her konteyner için ayrı yazılıyordu. Pod seviyesinde kaynak tanımı (.spec.resources) önceki sürümlerde geldi. v1.37 ile kubelet'in Topology, CPU ve Memory yöneticileri de bu pod seviyesindeki tanımı kullanarak donanım yerleşimi yapabiliyor:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  resources:
    requests:
      memory: "1Gi"
      cpu: "500m"
    limits:
      memory: "2Gi"
      cpu: "1"
  containers:
  - name: app
    image: myapp:latest

Özellik beta olmasına rağmen v1.37'de varsayılan olarak kapalı. Kullanmak için PodLevelResources özellik kapısını açmanız ve kubelet'te CPU, Memory ve Topology yöneticilerini yapılandırmanız gerekiyor. Ana uygulama ile sidecar'ları arasında kaynağı esnek paylaştırmak isteyenler için kullanışlı. Sidecar konteynerler konusunu daha önce Kubernetes native sidecar rehberimizde anlatmıştık.

Diskten yüklenen admission politikaları (KEP-5793, Beta)

ValidatingAdmissionPolicy gibi politikalar normalde API nesnesi olarak etcd'de tutulur. Bu da API sunucusu ilk açıldığında, politikalar yüklenene kadar kısa bir korumasız pencere bırakır. Yeni özellikle politikalar API sunucusu başlamadan önce diskteki dosyalardan okunabiliyor:

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ValidatingAdmissionPolicy
    configuration:
      apiVersion: apiserver.config.k8s.io/v1
      kind: ValidatingAdmissionPolicyConfiguration
      staticManifestsDir: "/etc/kubernetes/admission/policies/"

"Privileged pod çalıştırılamaz" gibi temel kuralların küme ayağa kalkarken bile geçerli olmasını isteyen ekipler için önemli bir boşluğu kapatıyor.

Alfa özellikler: neler geliyor?

• Yerinde boyutlandırma için önalım (KEP-5836): Pod'u yeniden başlatmadan CPU/bellek artırılırken düğümde yer yoksa, zamanlayıcı daha düşük öncelikli pod'ları çıkarabilecek.
• CompositePodGroup (KEP-6012): Büyük model eğitimi gibi iş yüklerinde dört seviyeye kadar iç içe "hep birlikte ya da hiç" (gang) zamanlama.
• etcd RangeStream: Büyük liste okumalarında API sunucusunun bellek kullanımını azaltıyor. Binlerce pod'lu kümelerde fark edilir.
• Node Lifecycle Conditions: Düğümün bakım ve kapanma durumlarını standart koşullarla bildirme.

Alfa özellikler varsayılan olarak kapalıdır ve üretimde kullanılmaları önerilmez. Bir sonraki sürümlerde değişebilirler.

Yükseltme öncesi kontrol listesi (Upgrade checklist)

1. Sürüm atlamayın: Kontrol düzlemi bir seferde yalnızca bir alt sürüm yükseltilir: 1.35 → 1.36 → 1.37.
2. Kaldırılan API'leri tarayın: kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis ile kullanımdan kalkan API çağrılarını görün.
3. Sürüm notlarındaki "Urgent Upgrade Notes" bölümünü okuyun.
4. Önce test kümesinde deneyin, GitOps kullanıyorsanız (ArgoCD ya da Flux) senkron durumunu yükseltme sonrası kontrol edin.
5. etcd yedeği alın: etcdctl snapshot save ile anlık görüntü almadan kontrol düzlemine dokunmayın.
6. Yönetilen hizmet kullanıyorsanız (EKS, GKE, AKS) sağlayıcınızın v1.37'yi ne zaman sunduğunu kontrol edin. Genellikle birkaç hafta ile birkaç ay arası gecikme olur.

Konteyner altyapısı, sunucu kurulumu veya mevcut sisteminizin taşınması konusunda destek arıyorsanız Alesta WEB web yazılım ve sunucu hizmetlerine göz atabilirsiniz.

Sık sorulan sorular

Kubernetes 1.37 ne zaman çıktı?

26 Ağustos 2026'da, "Garhwal" kod adıyla yayımlandı.

v1.37'de kaç yeni özellik var?

67 iyileştirme: 16 kararlı, 23 beta, 27 alfa ve 1 kaldırma.

KYAML kullanmak zorunlu mu?

Hayır. KYAML isteğe bağlı bir çıktı biçimi ve yazım stili. Mevcut YAML dosyalarınız aynen çalışır; KYAML da geçerli YAML olduğu için araçlarınız onu okuyabilir.

Pod-Level Resource Managers varsayılan olarak açık mı?

Hayır. Beta olmasına rağmen v1.37'de varsayılan olarak kapalı; PodLevelResources özellik kapısıyla açılır.

Bir sonraki Kubernetes sürümü ne zaman?

Kubernetes yaklaşık dört ayda bir sürüm çıkarıyor. v1.38'in Aralık 2026 civarında gelmesi bekleniyor.

Kapak fotoğrafı: İsmail Enes Ayhan / Unsplash