Kubernetes v1.37 "Garhwal"

4 września 2026 roku ukazał się Kubernetes v1.37, noszący kryptonim "Garhwal" — na cześć himalajskiego regionu Uttarakhand w Indiach, z którego pochodzi release lead Dipesh Rawat. Nazwa i logo nawiązują do tarasowych pól schodzących ku śnieżnym szczytom i rzeki zbierającej górskie strumienie — metafora wkładu wielu SIG-ów spływającego do jednego projektu.

Release składa się z 67 usprawnień: 16 osiągnęło status Stable, 23 przeszło do Beta, 27 weszło do Alpha i 1 jest przestarzałe lub usunięte. Cykl trwał 15 tygodni — od 18 maja do 26 sierpnia 2026 — z udziałem 1 754 kontrybutorów z 212 firm.

KYAML — ściślejszy dialekt YAML osiąga Stable

To główna zmiana v1.37 i temat, który będzie zdominował dyskusje w ekosystemie przez najbliższe miesiące.

Problem z klasycznym YAML

YAML jest czytelny dla człowieka, ale jego elastyczność jest jednocześnie jego największą słabością. Wcięcia definiują strukturę — błędnie wcisnięty plik może pozostać syntaktycznie poprawny, reprezentując zupełnie inny obiekt niż zamierzony. Wartości bez cudzysłowów mogą być interpretowane jako różne typy danych. Te problemy narastają gdy manifesty są generowane lub manipulowane przez systemy szablonowania jak Helm.

Co to jest KYAML

KYAML (Kubernetes YAML) to ściślejszy podzbiór standardowego YAML zaprojektowany dla konfiguracji Kubernetes, opisany w KEP-5295. Nie jest to nowy język ani nowy parser — to zbiór reguł zawężających dostępne wybory składniowe tak, by każdy pisał manifesty w ten sam, jednoznaczny sposób.

Kluczowe różnice od klasycznego YAML:

Obiekty używają {} — zamiast zagnieżdżania przez wcięcia, struktura jest wyrażona jawnie:

yaml

# Klasyczny YAML
metadata:
  name: my-pod
  labels:
    app: demo

# KYAML
metadata: {
  name: "my-pod",
  labels: {
    app: "demo",
  },
}

Tablice używają [] — zamiast myślników z wcięciem:

yaml

# Klasyczny YAML
containers:
  - name: nginx
    image: nginx:1.20

# KYAML
containers: [{
  name: "nginx",
  image: "nginx:1.20",
}]

Wszystkie wartości tekstowe w cudzysłowie — eliminuje niejednoznaczność typów (czy true to wartość logiczna czy ciąg znaków?).

Nie jest wrażliwy na wcięcia — struktura wynika z nawiasów, nie z odstępów. Zmiana wcięcia nie zmienia reprezentowanego obiektu.

Pełna kompatybilność wsteczna

Wszystko co jest poprawne w KYAML jest poprawne w standardowym YAML — istniejące parsery, kubectl i narzędzia ekosystemu przetwarzają KYAML bez żadnych zmian. Nie trzeba migrować istniejących manifestów — KYAML jest opcjonalny i można go adoptować stopniowo.

Jak używać KYAML

Od Kubernetes 1.35 KYAML jest dostępny jako format wyjściowy kubectl w fazie Beta, domyślnie włączonej. W v1.37 osiąga status Stable:

bash

# Pobierz manifest w formacie KYAML
kubectl get deployment my-app -o kyaml

# Ustaw KYAML jako domyślny format wyjściowy
kubectl kuberc set --section defaults --command get --option output=kyaml

Konwersja istniejących plików do KYAML przez yamlfmt:

bash

# Instalacja yamlfmt z pakietu sigs.k8s.io/yaml
go install sigs.k8s.io/yaml/cmd/yamlfmt@latest

# Konwersja pliku
yamlfmt --output-format kyaml deployment.yaml

Dlaczego to ważne dla pipeline'ów CI/CD

Dla środowisk z automatycznym generowaniem manifestów przez Helm lub własne skrypty, KYAML eliminuje całą klasę błędów: nieprawidłowe wcięcia w szablonach, nieoczekiwane konwersje typów i niespójny styl między plikami generowanymi przez różne narzędzia.

Jako krok lintingu w pipeline'ach GitLab CI lub GitHub Actions:

yaml

# .gitlab-ci.yml
lint-manifests:
  script:
    - yamlfmt --output-format kyaml --check manifests/

metrics.k8s.io API — Stable po prawie 9 latach w Beta

To jedna z najdłużej oczekujących graduacji w historii projektu.

API metrics.k8s.io dostarcza dane o użyciu CPU i pamięci dla podów i węzłów. Jest używane przez HorizontalPodAutoscaler (HPA), Vertical Pod Autoscaler (VPA) i polecenie kubectl top. Przez prawie dziewięć lat działało w fazie Beta — co oznaczało, że teoretycznie mogło zostać zmienione lub usunięte, choć w praktyce każdy z niego korzystał.

Graduated do Stable w v1.37 oznacza formalne zobowiązanie do stabilności API. Dla zespołów budujących własne narzędzia na tym API — ważny sygnał do usunięcia wszelkich workaroundów i traktowania go jako stabilnej podstawy.

HPA scale-to-zero — Beta, domyślnie włączone

HorizontalPodAutoscaler może teraz skalować workloady do zera replik — Beta osiągnięta w v1.37, domyślnie włączona.

Ustawienie spec.minReplicas: 0 pozwala workloadom napędzanym przez metryki zewnętrzne lub obiektowe spaść do zera podów gdy są bezczynne i powrócić gdy pojawi się taka potrzeba:

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-consumer
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-consumer
  minReplicas: 0  # Nowość w v1.37 Beta
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_ready
      target:
        type: AverageValue
        averageValue: "30"

Ważne ograniczenie: metryki CPU i pamięci wymagają działających podów do mierzenia — nie mogą być używane jako jedyne metryki z minReplicas: 0. Workloady skalowane do zera muszą używać metryk zewnętrznych (kolejki, zdarzenia) lub obiektowych.

Przypadki użycia z bezpośrednią oszczędnością: konsumenci kolejek (RabbitMQ, Kafka, SQS), zadania batch uruchamiane cyklicznie, workloady GPU czekające na żądania, środowiska staging i dev wyłączane poza godzinami pracy.

Dynamic Resource Allocation — rdzeń osiąga Stable

Cztery ulepszenia DRA osiągają Stable w v1.37, zamykając wieloletni cykl pracy nad tym obszarem.

ResourceClaim device status (KEP-4817)

Sterownik może teraz raportować status specyficzny dla urządzenia dla każdego przydzielonego urządzenia w .status.devices. Motywujący przypadek: sieć. Przed tym polem pod mógł żądać urządzenia sieciowego przez DRA i nic innego w systemie nie mogło poznać przypisanego mu adresu IP. Teraz sterownik sieciowy może zapisać adres IP w statusie ResourceClaim, skąd może go odczytać każdy komponent z odpowiednimi uprawnieniami RBAC.

Partitionable devices (KEP-4815)

Urządzenia mogą teraz raportować się jako podzielne na partycje (np. GPU z MIG). Sterownik deklaruje dostępne partycje i reguły partycjonowania, a scheduler przydziela partycje zamiast całych urządzeń. To bezpośrednio istotne dla środowisk AI/ML z GPU — współdzielenie GPU między workloadami bez nadmiernego provisioningu.

DRA dla workloadów AI — kontekst

Cztery usprawnienia DRA w v1.37 razem zamykają kluczowy scenariusz: pod żąda ułamka GPU przez ResourceClaim, scheduler znajduje węzeł z wystarczającą pojemnością partycji GPU, przydziela konkretną partycję, sterownik raportuje ID partycji i adres sieciowy w statusie, inne komponenty mogą to odczytać. Cały przepływ bez obejść, bez ręcznego zarządzania przydziałem GPU.

Networking — dalsze przejście z IPVS na nftables

v1.37 kontynuuje przejście infrastruktury sieciowej zapoczątkowane w v1.35, gdy IPVS kube-proxy zostało przestarzałe.

Tryb nftables kube-proxy jest teraz preferowaną ścieżką dla nowych klastrów. nftables oferuje lepszą wydajność przy dużej liczbie usług, prostszą diagnostykę i aktywne utrzymanie przez społeczność Linux — w przeciwieństwie do iptables i IPVS, które są w trybie konserwacji.

Dla istniejących klastrów — migracja z IPVS do nftables nie jest wymagana w v1.37, ale warto ją zaplanować przed v1.39 lub v1.40, gdy IPVS może zostać usunięte.

Scheduling dla workloadów AI/ML — nowe możliwości

v1.37 wprowadza nowe możliwości planowania zbudowane dla zadań treningowych AI i ML, które wymagają grup podów startujących i skalujących się razem.

Dla rozproszonych zadań treningowych PyTorch lub TensorFlow uruchamianych przez Kubeflow (który właśnie osiągnął status Graduated w CNCF) — nowe możliwości schedulera eliminują scenariusz częściowego uruchomienia: stan, gdzie część podów startuje i czeka na resztę, blokując zasoby bez robienia użytecznej pracy.

API serwera — koniec z przeciążaniem etcd przy starcie

API serwer nie przeciąża już etcd przy restarcie — zmiana Stable w v1.37.

Wcześniej przy starcie API serwer masowo odpytywał etcd o całą aktualną konfigurację klastra. Dla dużych klastrów z tysiącami obiektów powodowało to spike obciążenia etcd bezpośrednio po restarcie kube-apiserverа. W środowiskach z wieloma instancjami API serwera — równoczesne restarty (np. podczas upgrade'u płaszczyzny sterowania) mogły spowodować cascade: przeciążone etcd spowalniało odpowiedzi, co powodowało timeout-y, co powodowało kolejne restarty.

Deprecations i usunięcia

Jedna pozycja w kategorii przestarzałe/usunięte — szczegóły w oficjalnych notach wydania na github.com/kubernetes/kubernetes/releases/tag/v1.37.0.

Warto sprawdzić: jeśli Twój klaster używa specyficznych funkcji beta z v1.35 lub v1.36, które nie zostały promowane — mogły zmienić status lub zachowanie w v1.37.

Skala projektu

v1.37 to potwierdzenie stałego rytmu projektu Kubernetes: cztery release'y rocznie, stały wzrost liczby kontrybutorów, systematyczna praca nad zamykaniem wieloletnich długów technicznych.

1 754 kontrybutorów z 212 firm przez 15 tygodni. Graduation KYAML po dwóch latach iteracji od alpha w v1.34, graduation metrics.k8s.io API po prawie dekadzie w beta, graduation rdzenia DRA po wieloletniej pracy SIG-Node. To release, który dostarcza — nie przez pojedyncze przełomowe funkcje, ale przez konsekwentne domykanie tego co zostało zaczęte.

TL;DR — co zrobić po przeczytaniu

Przetestuj KYAML — uruchom kubectl get deployment <nazwa> -o kyaml i oceń czy nowy format pasuje do Twojego workflow. Rozważ yamlfmt jako krok lintingu w pipeline'ach CI.

Włącz HPA scale-to-zero dla workloadów batch i konsumentów kolejek w środowiskach staging — natychmiastowa oszczędność bez dodatkowych narzędzi.

Zaplanuj migrację z IPVS — jeśli używasz IPVS kube-proxy, zacznij planować przejście na nftables. v1.37 to dobry moment na testy w środowiskach nieprodukcyjnych.

Dla workloadów GPU — zbadaj możliwości DRA Stable w v1.37, szczególnie partitionable devices dla środowisk ML z GPU.