Kubernetes v1.36 "Haru"

Kubernetes v1.36 wprowadza Pod-Level Resource Managers jako feature alpha, oferując bardziej elastyczny model zarządzania zasobami dla workloadów wrażliwych na wydajność. Rozszerza to możliwości kubeletu w zakresie Topology, CPU i Memory Managerów.

Release składa się z 70 usprawnień: 18 przeszło do Stable (GA), 25 weszło do Beta, a 25 do Alpha. W ciągu 15-tygodniowego cyklu swój wkład wniosło 491 kontrybutorów z 106 firm. Nazwa kodowa "Haru" (ハル) to japońskie słowo oznaczające jednocześnie wiosnę, czyste niebo i odległy horyzont — nie ma tu dramatycznego nowego paradygmatu — zamiast tego release wynosi lata nawarstwiającej się pracy do stadium production-ready.

Bezpieczeństwo — największe zmiany

User Namespaces → GA (KEP-127)

User Namespaces pozwalają mapować UID/GID wewnątrz kontenera na inne identyfikatory na hoście. Proces uruchomiony jako UID 0 wewnątrz kontenera jest mapowany na nieuprzywilejowany UID na hoście — nawet po ucieczce z kontenera nie ma żadnych uprawnień administracyjnych na nodzie. Kubelet przypisuje rozłączne zakresy UID poszczególnym podom, więc dwa pody działające jako root wewnątrz swoich kontenerów mają różne UID na hoście.

Aktywacja to dosłownie jedno pole w pod spec:

spec:
  hostUsers: false

Feature był po raz pierwszy wprowadzony w v1.25 w 2022 roku — zajęło cztery lata i wiele cykli releasowych, by dotrzeć do Stable. KEP-127 to prawdopodobnie jeden z najstarszych KEP-ów w historii projektu.

Fine-Grained Kubelet API Authorization → GA

Wcześniej każdy podmiot mający dostęp do API kubeleta miał szeroki dostęp do wszystkiego. Teraz autoryzację można ograniczyć do konkretnych endpointów — /metrics, /healthz, /pods, logów nodów — używając standardowego Kubernetes RBAC. Narzędzia monitoringowe mogą dostać dostęp do metryk bez dostępu do logów nodów ani endpointów exec. To dokładnie to, czego wymagają środowiska regulowane.

Mutating Admission Policies → GA (KEP-3962)

Mutating Admission Policies wprowadzają deklaratywną, in-process alternatywę dla serwerów webhook. Zamiast utrzymywać zewnętrzny serwer, definiujesz logikę mutacji bezpośrednio w YAML używając Common Expression Language (CEL). Trzy typy zasobów: MutatingAdmissionPolicy dla logiki mutacji, MutatingAdmissionPolicyBinding do aktywacji i zakresu, oraz opcjonalne param resources.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: "sidecar-policy.example.com"
spec:
  paramKind:
    group: mutations.example.com
    kind: Sidecar
    version: v1
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  matchConditions:
    - name: does-not-already-have-sidecar
      expression: "!object.spec.initContainers.exists(ic, ic.name == params.name)"
  failurePolicy: Fail
  reinvocationPolicy: IfNeeded
  mutations:
    - patchType: "ApplyConfiguration"
      expression: >
        Object{
          spec: Object.spec{
            initContainers: [
              Object.spec.initContainers{
                name: params.name,
                image: params.image,
                args: params.args,
                restartPolicy: params.restartPolicy
              }
            ]
          }
        }

# Policy Binding
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: "sidecar-binding-test.example.com"
spec:
  policyName: "sidecar-policy.example.com"
  paramRef:
    name: "meshproxy-test.example.com"
    namespace: "default"
---
# Sidecar parameter resource
apiVersion: mutations.example.com
kind: Sidecar
metadata:
  name: meshproxy-test.example.com
spec:
  name: mesh-proxy
  image: mesh/proxy:v1.0.0
  args: ["proxy", "sidecar"]
  restartPolicy: Always

Aby zobaczyć efekt, weź tego Poda przesyłanego do klastra:

kind: Pod
spec:
  initContainers:
    - name: myapp-initializer
      image: example/initializer:v1.0.0
  containers:
    - name: myapp
      image: example/myapp:v1.0.0

Ponieważ żądanie utworzenia jest zgodne z polityką, Kubernetes mutuje Poda przed jego przyjęciem, co powoduje:

kind: Pod
spec:
  initContainers:
    - name: mesh-proxy
      image: mesh/proxy:v1.0.0
      args: ["proxy", "sidecar"]
      restartPolicy: Always
    - name: myapp-initializer
      image: example/initializer:v1.0.0
  containers:
    - name: myapp
      image: example/myapp:v1.0.0

Zasoby i scheduling

In-Place Vertical Scaling dla Pod-Level Resources → Beta

Budując na in-place pod resize (który osiągnął GA w v1.35), v1.36 rozszerza to o specyfikacje zasobów na poziomie poda. Wcześniej resize był ograniczony do poziomu kontenera. Teraz można dynamicznie skalować CPU i pamięć na poziomie poda bez restartu. Przeznaczone dla środowisk cgroups v2.

HPA Scale-to-Zero → Beta (domyślnie włączone)

HPA może teraz skalować workloady do zera replik przy braku obciążenia. Dla środowisk stagingowych, workloadów batch czy serwisów event-driven eliminuje to koszty idle podów bez żadnych zewnętrznych narzędzi.

Dynamic Resource Allocation (DRA) — kolejne kroki

DRA osiąga dojrzałość produkcyjną. Nowe beta features obejmują: partitionable devices (dzielenie GPU), taints i tolerations dla hardware, śledzenie consumable capacity, oraz health status w pod conditions. To bezpośrednio istotne dla AI/ML workloadów na AKS z GPU.

Storage

OCI VolumeSource → Beta

Zamiast upychać artefakty do obrazu kontenera, używać init-containerów albo walczyć z limitami ConfigMap — teraz można wskazać dowolny obraz OCI jako wolumen. Kubernetes pobiera go i montuje zawartość jak zwykły wolumen. Najistotniejsze dla workloadów AI/ML.

Mutable CSINode Allocatable → Stable

CSI drivery mogą teraz dynamicznie aktualizować raportowaną maksymalną liczbę wolumenów , które node może obsłużyć. Kubelet dostosowuje limity na podstawie okresowych sprawdzeń lub w odpowiedzi na błędy resource exhaustion — bez restartu komponentów. Zapewnia to schedulerowi dokładny obraz dostępności storage.

Operacje i obserwowalność

SELinux Mount Label → GA

Na nodach z SELinux Kubernetes wcześniej rekurencyjnie przemianowywał zawartość woluminów przy montowaniu. Dla dużych woluminów powodowało to znaczące opóźnienia startu podów. v1.36 zastępuje to przez mount -o context=XYZ — etykieta SELinux jest nakładana przy mountowaniu, a nie plik po pliku.

PVC UnusedSince field → Alpha

Nowe pole unusedSince w PersistentVolumeClaim rejestruje dokładny czas, kiedy PVC przestało być używane przez poda. Wartość nil oznacza, że PVC jest aktualnie aktywnie używane. Przyszłe plany obejmują integrację z kube-state-metrics.

Deprecations i breaking changes — uwaga przed upgrade'em

Wolumen gitRepo został całkowicie usunięty — był wyłączony od v1.11, teraz nieodwracalnie. Service.spec.externalIPs jest oznaczony jako deprecated (poprawka CVE-2020-8554). Ingress-NGINX jest oficjalnie wycofany — brak nowych release, brak bugfixów, brak security patches.

Istniejące deploymenty Ingress-NGINX nadal działają — nic się nie psuje z dnia na dzień. Ale z perspektywy długoterminowej to ważny sygnał — warto już teraz zacząć planować migrację do Gateway API v1.5.