Kubernetes v1.36 „Haru” został wydany 22 kwietnia 2026 r., a w maju 2026 r. projekt opublikował serię technicznych omówień najważniejszych zmian. Dla administratorów Linuksa i zespołów platformowych jest to jedno z ciekawszych wydań od dłuższego czasu, bo wiele funkcji nie dotyczy wyłącznie API klastra, lecz bezpośrednio korzysta z mechanizmów jądra: przestrzeni nazw użytkowników, cgroups, Pressure Stall Information, NUMA, CPU Managera, Memory Managera i obsługi urządzeń przez Dynamic Resource Allocation.
Nie jest to wydanie, które zmienia sposób pisania zwykłego Deploymentu z dnia na dzień. Jest to raczej zestaw klocków dla zespołów utrzymujących klastry produkcyjne, klastry pod ML/AI, obciążenia niskolatencyjne oraz platformy wielodzierżawne. Kubernetes v1.36 zawiera 70 enhancements: 18 awansowało do Stable, 25 weszło do Beta, a 25 trafiło do Alpha. Najważniejsze z perspektywy linuxadmin.online są cztery obszary: bezpieczniejsze uruchamianie kontenerów z UID 0, lepszy sygnał o presji na CPU/pamięć/I/O, dojrzalsza alokacja GPU i innych urządzeń oraz polityki admission, które można załadować z dysku API serwera.
Co konkretnie się wydarzyło w Kubernetes 1.36?
Wydanie v1.36 nie jest „kosmetyką”. Projekt Kubernetes domyka kilka długo rozwijanych ścieżek, które przez lata były testowane jako Alpha lub Beta. Najbardziej praktyczna zmiana bezpieczeństwa to awans obsługi User Namespaces w Podach do General Availability. Równie ważna dla operatorów jest stabilizacja metryk PSI, czyli Pressure Stall Information, które pozwalają patrzeć na przeciążenie systemu nie tylko przez pryzmat procentowego użycia CPU albo RAM, ale przez czas, w którym zadania faktycznie czekają na zasoby.
W obszarze klastrów akceleratorowych Kubernetes v1.36 rozwija Dynamic Resource Allocation. To ma znaczenie wszędzie tam, gdzie Pod nie potrzebuje już tylko „cpu” i „memory”, ale konkretnego modelu GPU, partycji urządzenia, zasobu sieciowego, pamięci specjalizowanej albo innego sprzętu opisywanego przez sterownik. Dodatkowo 1 maja 2026 r. projekt opisał Alpha funkcję Pod-Level Resource Managers, która rozszerza Topology, CPU i Memory Managera kubeleta tak, aby mogły pracować na budżecie całego Poda, a nie tylko osobno na każdym kontenerze.
User namespaces są GA: root w kontenerze nie musi być rootem na hoście
Najważniejsza zmiana bezpieczeństwa w Kubernetes v1.36 to General Availability dla User Namespaces. Jest to funkcja wyłącznie linuksowa. Jej sens jest prosty: proces widzący siebie jako UID 0 w kontenerze nie musi być UID 0 z punktu widzenia hosta. Przy ustawieniu hostUsers: false Pod korzysta z osobnej przestrzeni nazw użytkowników, a uprawnienia są mapowane do zakresu UID/GID na hoście.
To nie jest magiczna tarcza przed każdą podatnością w jądrze lub runtime. Zmniejsza jednak promień rażenia błędów. Jeśli aplikacja koniecznie musi uruchamiać się jako root w kontenerze, można ją izolować lepiej niż w klasycznym modelu, w którym „root w kontenerze” nadal ma wiele właściwości roota widzianych przez kernel hosta. Ważny detal techniczny: w drodze do GA istotną rolę odegrały ID-mapped mounts, dostępne od Linuksa 5.12. Dzięki nim kubelet nie musi wykonywać kosztownego, rekurencyjnego chown na dużych wolumenach tylko po to, aby dopasować właścicieli plików do mapowania UID.
apiVersion: v1
kind: Pod
metadata:
name: isolated-workload
spec:
hostUsers: false
containers:
- name: app
image: registry.example.com/app:1.0
securityContext:
runAsUser: 0
allowPrivilegeEscalation: false
capabilities:
drop:
- ALLW praktyce zespoły platformowe powinny potraktować hostUsers: false jako kandydat do standardu dla nowych workloadów, ale nie jako przełącznik do masowego włączenia bez testów. Do sprawdzenia są obrazy kontenerów, init kontenery, wolumeny, sterowniki CSI, operacje na plikach oraz aplikacje, które robią założenia o rzeczywistym UID/GID. Warto zacząć od namespace’ów deweloperskich i usług stateless, a dopiero później przejść do baz danych oraz workloadów z trwałymi wolumenami.
PSI jako stabilny sygnał: mniej zgadywania, więcej informacji z jądra
Pressure Stall Information istnieje w Linuksie od 2018 r., ale Kubernetes v1.36 daje stabilny interfejs do obserwowania presji na zasoby na poziomie node, pod i container. To istotna różnica względem klasycznych metryk. Użycie CPU na poziomie 70% nie mówi, czy zadania regularnie czekają na scheduler. Wolna pamięć nie mówi, czy procesy stoją przez reclaim albo I/O. PSI odpowiada na inne pytanie: ile czasu zadania spędziły w stanie oczekiwania, bo CPU, pamięć albo I/O były wąskim gardłem.
Dla administratora Linuksa to bardzo znajomy model, bo źródłem prawdy jest kernel. Na hoście można szybko sprawdzić, czy PSI jest dostępne:
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io
# Szybka inspekcja cgroup v2 dla procesu lub kontenera wymaga mapowania ścieżki cgroup.
mount | grep cgroup2
systemd-cgls --no-pagerW klastrze produkcyjnym warto zestawić metryki PSI z danymi z Prometheusa, kubeleta, node-exportera i alertami SLO. Przykład praktyczny: Pod zgłasza opóźnienia, ale użycie CPU nie dochodzi do limitu. PSI może pokazać, że workload traci czas przez scheduling delay albo I/O pressure, a problemem nie jest sama wartość limitu, lecz umiejscowienie Poda, sąsiedztwo innych workloadów, oversubscription albo zachowanie storage’u.
To szczególnie przydatne przy usługach, które mają krótkie, ale intensywne piki: API gateway, broker komunikatów, bazy danych, systemy kolejkowe, inference modeli oraz zadania CI/CD. Administratorzy często widzą w takich przypadkach „wszystko wygląda dobrze”, dopóki nie spojrzą na latency. PSI daje dodatkowy sygnał do korelacji: jeżeli rośnie some lub full pressure dla pamięci albo I/O, problem może być widoczny wcześniej niż awaria procesu.
DRA dojrzewa: Kubernetes lepiej opisuje GPU, partycje urządzeń i fallbacki
Dynamic Resource Allocation jest ważny dla klastrów, w których sprzęt przestaje być jednorodny. Tradycyjny model extended resources sprawdzał się przy prostych przypadkach, na przykład „daj mi jedno GPU”. W praktyce klastry AI/ML, HPC i niskolatencyjne mają bardziej złożone wymagania: konkretna generacja akceleratora, możliwość podziału urządzenia, preferowany wariant i bezpieczny fallback, a czasem zasób, którego nie da się elegancko opisać jako liczby całkowitej.
W Kubernetes v1.36 DRA otrzymuje m.in. stabilną listę priorytetów dla żądań urządzeń. Oznacza to, że platforma może lepiej opisać preferencje: workload najchętniej użyje określonego typu akceleratora, ale jeśli nie jest dostępny, scheduler może przejść do kolejnej opcji. Dla administratora oznacza to wyższą utylizację drogiego sprzętu i mniej ręcznego przepinania kolejek zadań. Funkcje dotyczące zasobów rozszerzonych oraz urządzeń partycjonowalnych są w v1.36 rozwijane jako Beta, co warto traktować jako sygnał do testów w środowiskach staging i pre-production.
DRA nie rozwiązuje samodzielnie wszystkich problemów GPU w Kubernetes. Nadal trzeba utrzymywać sterowniki, runtime, device pluginy lub sterowniki DRA, wersje CUDA/ROCm, polityki bezpieczeństwa i monitoring. Zmienia się jednak warstwa kontraktu między aplikacją a platformą. Zamiast wymuszać na developerach znajomość fizycznej topologii węzłów, platform team może wystawić sensowne klasy zasobów i polityki przydziału.
Pod-Level Resource Managers: ciekawa Alpha dla NUMA i workloadów niskolatencyjnych
Funkcja Pod-Level Resource Managers, opisana 1 maja 2026 r., jest jeszcze Alpha, więc nie należy jej włączać bezkrytycznie na produkcji. Jest jednak bardzo interesująca technicznie. Dotychczas ekskluzywne CPU, pamięć i wyrównanie NUMA były mocno związane z kontenerami. Problem pojawia się w nowoczesnych Podach wielokontenerowych: główna aplikacja potrzebuje gwarantowanych, NUMA-aligned zasobów, ale obok działa lekki sidecar od logów, metryk, service mesha albo backupu.
Bez modelu pod-level łatwo marnować rdzenie, bo każdy kontener musiał dostać zasoby w sposób pasujący do klasy Guaranteed i polityk kubeleta. Nowy model pozwala patrzeć na budżet całego Poda. Kubelet może przydzielić ekskluzywne zasoby głównemu kontenerowi, a kontenery pomocnicze uruchomić w puli współdzielonej w ramach budżetu Poda. To brzmi niszowo, ale dla baz danych, inference, HFT, NFV i systemów wymagających przewidywalnej latencji jest to dokładnie ten poziom kontroli, którego często brakuje w standardowym Kubernetes.
- Do testów: klastry z cgroup v2, kontrolowaną topologią NUMA i jasną polityką pinning CPU.
- Do ostrożnego wdrożenia: wyłącznie środowiska, w których zespół rozumie kubelet configuration, CPU Manager, Memory Manager i Topology Manager.
- Nie jako szybki fix: jeżeli problemem są źle ustawione requests/limits, brak limitów albo hałaśliwi sąsiedzi, najpierw trzeba uporządkować podstawy.
Admission policies z dysku: mniej dziur podczas bootstrapu klastra
4 maja 2026 r. projekt Kubernetes opisał także Alpha funkcję manifest-based admission control. Jej cel jest bardzo praktyczny: umożliwić załadowanie wybranych polityk admission z plików na dysku API serwera, zanim API zacznie obsługiwać żądania. To odpowiada na znany problem bootstrapu: polityki admission są zwykle obiektami API, więc same muszą zostać utworzone dopiero po starcie klastra. W krótkim oknie czasowym mogą jeszcze nie działać. Dodatkowo użytkownik z wysokimi uprawnieniami może usuwać konfiguracje admission, których klasyczne webhooks nie zawsze są w stanie same ochronić.
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionPolicy
configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: ValidatingAdmissionPolicyConfiguration
staticManifestsDir: "/etc/kubernetes/admission/validating-policies/"Według modelu v1.36 manifesty ładowane z dysku muszą używać nazw zakończonych sufiksem .static.k8s.io. To rozdziela konfigurację statyczną od obiektów zarządzanych przez API. Dla zespołów SRE i SecOps szczególnie ciekawe jest to, że taka polityka może chronić krytyczne polityki API przed modyfikacją lub usunięciem. Innymi słowy: część reguł bezpieczeństwa można przenieść bliżej konfiguracji samego control plane, a nie zostawiać ich wyłącznie jako obiekty w etcd.
Co warto zrobić przed aktualizacją do 1.36?
Najgorszą reakcją na Kubernetes 1.36 byłoby włączenie wszystkich nowych opcji naraz. Najlepszą jest potraktowanie wydania jako okazji do przeglądu klastra na trzech poziomach: bezpieczeństwo kontenerów, obserwowalność systemu operacyjnego i zarządzanie zasobami specjalizowanymi.
- Zrób inwentaryzację wersji: sprawdź wersję control plane, kubeletów, runtime, kernela, dystrybucji node’ów i sterowników CSI/GPU.
- Przetestuj
hostUsers: false: zacznij od prostych workloadów stateless i sprawdź zachowanie wolumenów oraz init kontenerów. - Włącz analizę PSI w monitoringu: porównaj PSI z latency, throttlingiem CPU, OOM, restartami i metrykami storage.
- Oddziel Stable od Alpha: user namespaces i PSI są kandydatami do poważnych testów wdrożeniowych, ale Pod-Level Resource Managers i manifest-based admission control wymagają ostrożności.
- Przejrzyj deprecations i removals: przed aktualizacją sprawdź manifesty, polityki admission, Service oraz używane pluginy wolumenów.
- Dla GPU przygotuj plan DRA: oceń, czy obecny model device pluginów i extended resources wystarcza, czy warto zacząć budować ResourceClass i ResourceClaim pod przyszłe wdrożenia.
Podsumowanie praktyczne
Kubernetes v1.36 to wydanie mocno „linuksowe”: mniej abstrakcji dla samej abstrakcji, więcej używania mechanizmów jądra tam, gdzie faktycznie poprawiają izolację, diagnostykę i przydział zasobów. Administratorzy powinni w pierwszej kolejności sprawdzić User Namespaces oraz PSI, bo te funkcje mogą realnie poprawić bezpieczeństwo i troubleshooting. Zespoły utrzymujące klastry GPU/AI powinny rozpocząć testy DRA i obserwować Pod-Level Resource Managers. Funkcje Alpha warto traktować jako kierunek rozwoju platformy, nie jako domyślną konfigurację produkcji.
