Blog'a Dön

Kubernetes v1.37: Sıfıra Ölçekleme Artık Varsayılan Olarak Açık, Önce Yükseltme Notlarını Okuyun

Kubernetes v1.37 ile HPA'da sıfıra ölçekleme, Memory QoS ve etcd streaming varsayılan olarak açık geliyor. Platform ekiplerinin şimdi pilot olarak denemesi gerekenler ve yükseltme notlarında önce kontrol edilmesi gerekenler.

Umut Korkmaz

Yayın tarihi: 4 dk okuma

Adını Hindistan'ın Uttarakhand eyaletindeki bir Himalaya bölgesinden alan Garhwal kod adlı Kubernetes v1.37, 26 Ağustos'ta 67 iyileştirmeyle yayınlandı: 16'sı stable'a, 23'ü beta'ya geçti, 27'si yeni alpha ve bir adet de deprecation ya da kaldırma var. Sürüm duyurusunu v1.37 changelog'u ile yan yana okuduğunuzda öne çıkan şey tek bir manşet özellik değil; opt-in olmaktan çıkıp varsayılan olarak açık hale gelen şeylerin sayısı. Bu da yükseltme yaptığınız anda cluster'ın maliyet ve güvenlik temel çizgisini değiştiriyor.

HPA ile sıfıra ölçekleme sonunda açık

İlk olarak v1.16'da gelen HorizontalPodAutoscaler ile sıfıra ölçekleme, v1.37'de beta'ya geçiyor ve varsayılan olarak etkin. spec.minReplicas: 0 ayarladığınızda HPA, boşta kalan bir workload'u sıfır pod'a indirebiliyor ve talep geri geldiğinde yeniden ayağa kaldırıyor.

Buradaki kısıt önemli: yalnızca object veya external metriklerle çalışıyor. CPU ve bellek desteklenmiyor, çünkü bu metrikler aktif pod'lara bağlı. Dolayısıyla bu özellik kuyruk tüketicileri, batch job'lar ve GPU workload'ları için; yani "bekleyen iş var mı?" sorusunun pod'ların dışından cevaplanabildiği senaryolar için.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: invoice-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: invoice-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_messages_ready
        target:
          type: AverageValue
          averageValue: "20"

HPA bir workload'u sıfırda tuttuğu sürece True değerli bir ScaledToZero condition'ı kaydediyor; tekrar ölçeklendikten sonra bu condition NotScaledToZero reason'ı ile False oluyor. Controller, kendi yaptığı scale-down'ı birinin replica sayısını elle 0'a çekmesinden bu şekilde ayırt ediyor. "0 replica"yı "bozuk" olarak yorumlayan her alert veya runbook artık bu condition'ı okumalı.

Node tarafında: rootless kubelet ve memory QoS

KubeletInUserNamespace feature gate'i beta'ya yükseltildi. Dokümantasyon bunu kubelet, CRI, OCI ve CNI gibi node bileşenlerinin bir user namespace içinde root yetkisi olmadan çalıştırılması, yani rootless mod olarak tanımlıyor ve ön koşul olarak cgroup v2'yi listeliyor.

Memory QoS da beta'ya ulaşıyor ve MemoryQoS gate'i varsayılan olarak etkin. Request ve limit değerlerini memory.min, memory.low ve memory.high gibi cgroup v2 kontrollerine eşliyor. memoryThrottlingFactor artık varsayılan olarak nil ve memory.high açıkça yapılandırılmadıkça ayarlanmıyor; sürüm yazısına göre bunun amacı yükseltme sırasında sürpriz throttling'in önüne geçmek.

Ortak payda cgroup v2. v1.35'ten beri kubelet, failCgroupV1: false ayarlamadığınız sürece cgroup v1 node'larda başlatılamıyor ve sürüm yazısı memory QoS'un yalnızca cgroup v2'de çalıştığını belirtiyor. Bu override hâlâ node konfigürasyonunuzda duruyorsa kaldırılmasını planlayın.

Daha sakin bir control plane, daha az elle yazılmış script

metrics.k8s.io API'si yaklaşık dokuz yıl beta'da kaldıktan sonra stable'a geçiyor. Hiçbir değişiklik yapılmadan v1'e yükseltildi, geçiş sürecinde v1beta1 kullanılabilir kalıyor ve kubectl top bu sürümde v1 desteği kazanıyor.

Storage Version Migration stable oluyor ve varsayılan olarak açık geliyor (storagemigration.k8s.io/v1). kubectl get ve kubectl replace script'leri ya da out-of-tree migrator yerine bir StorageVersionMigration nesnesi oluşturuyorsunuz ve yerleşik bir controller saklanan kaynakları yeniden yazıyor. Encryption-at-rest değişikliğinden sonra verinin yeniden yazılmasını da kapsıyor ve CRD yazarları bunu bir CRD yükseltmesinin parçası olarak tetikleyebiliyor.

Büyük cluster'lar için EtcdRangeStream, kube-apiserver'da beta olarak ve varsayılan olarak açık geliyor. etcd 3.7+ gerektiriyor ve daha eski etcd sürümlerinde otomatik olarak eski davranışa dönüyor. Yine artık varsayılan olarak açık olan concurrent watch decode ile birlikte, proje 150 bin pod üzerindeki benchmark'larda cache başlatma süresinde yaklaşık %55 azalma raporluyor. Bedeli şu: cache init sırasında bir conversion webhook'a karşı artık aynı anda 10'a kadar conversion çalışabiliyor.

Önce yükseltme notlarını okuyun

Acil yükseltme notlarından ve deprecation'lardan, production'a kimse dokunmadan önce bir ekibin önüne koyacağım şeyler şunlar:

  • SELinuxMount GA oldu ve varsayılan olarak açık. SELinux etkin cluster'larda, aynı node üzerinde farklı SELinux label'larına sahip ve bir volume'u paylaşan pod'lar, CSI driver opt-in yaptığında başlatılamayabilir. Pod üzerinde seLinuxChangePolicy: Recursive eski davranışı korur.
  • scheduling.k8s.io v1alpha2 API'si kaldırıldı; yükseltmeden önce bu nesneleri silin.
  • kubelet'te eventRecordQPS: 0 artık sınırsız anlamına geliyor ve deprecated cAdvisor flag'leri ayarlıysa kubelet başlamayı reddediyor.
  • Static pod'lar artık Secret veya ConfigMap referans edemiyor.
  • kube-proxy ipvs modu bir deprecation uyarısı logluyor; v1.40'a kadar varsayılan olarak kapalı olması, v1.43'te ise kaldırılması bekleniyor. kube-dns de CoreDNS lehine deprecated oldu.
  • kube-apiserver, watch cache'i ısınırken istekleri HTTP 429 ile reddedebiliyor. Custom controller'lar Retry-After'a uymalı ve back off yapmalı.

Pazartesi ne yapardım

Yayına aldığım işlerin bir kısmı Kubernetes üzerinde değil, systemd ve nginx ile düz bir VPS'te çalışıyor; o yüzden bir platform ekibine vereceğim sıralama şu:

  1. kubelet konfigürasyonlarını acil notlar ve kaldırılan cAdvisor flag'leri listesiyle diff'leyin.
  2. Her node'un cgroup v2 üzerinde çalıştığını doğrulayın ve tüm failCgroupV1: false override'larını listeleyin.
  3. kube-proxy modunu kontrol edin ve ipvs'ten geçişi takvime bağlayın.
  4. Sıfıra ölçeklemeyi, cold start'ın kabul edilebilir olduğu tek bir kuyruk tüketicisinde pilot olarak deneyin; kullanıcıya dönük hiçbir şeyde değil.
  5. Rootless kubelet'i herhangi bir production node pool'dan önce bir dev veya CI cluster'ında deneyin.

Re-Shell, Docker ve Kubernetes scaffold'ları üretiyor ve minReplicas: 0'ı template varsayılanı yapmak cazip gelecek. Ben yapmazdım. Sıfıra ölçekleme, gecikme ve maliyet üzerine workload bazında verilmesi gereken bir karar; bir beta döngüsü de nerede can yaktığını öğrenmek için doğru zaman.

Kaynaklar

Bu yazıda yararlanılan birincil kaynaklar.

  1. kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release (yeni sekmede açılır)
  2. github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md (yeni sekmede açılır)
  3. kubernetes.io/docs/tasks/administer-cluster/kubelet-in-userns (yeni sekmede açılır)

Yazar hakkında

Umut Korkmaz

Lead Yazılım Mühendisi

İstanbul'da kıdemli yazılım mühendisi olarak çalışıyorum. Burada, bizzat canlıya aldığım araçları ve sürümleri, sahada öğrendiklerimle birlikte yazıyorum.

Ortak konulara göre seçildi.