Kubernetes 1.36, wydany 22 kwietnia 2026 roku pod nazwą Haru, nie jest tylko kolejną wersją orkiestratora z długą listą zmian API. Dla zespołów utrzymujących klastry na Linuksie to wydanie szczególnie ciekawe, bo kilka istotnych funkcji przesuwa ciężar z „ufamy użytkownikom i runtime’owi” w stronę bardziej jawnej izolacji, twardszych domyślnych decyzji bezpieczeństwa i lepszej diagnostyki presji zasobów. Dodatkowo 13 maja 2026 roku gałąź 1.36 otrzymała wydanie poprawkowe 1.36.1, więc planowanie testów migracji warto opierać już na aktualnej wersji patch, a nie na samym 1.36.0.
Najważniejsze z perspektywy administratora: User Namespaces w Podach są już General Availability, pole .spec.externalIPs w obiekcie Service zostało formalnie oznaczone jako deprecated, PSI z kernela Linuksa stało się stabilnym elementem obserwowalności w Kubernetes, a Dynamic Resource Allocation dojrzewa w kierunku sensowniejszej obsługi GPU, FPGA, kart sieciowych i innych akceleratorów. To zestaw zmian, który dotyka zarówno bezpieczeństwa wielodostępnych klastrów, jak i praktycznej pracy z obciążeniami AI/ML.
Co dokładnie wydarzyło się w Kubernetes 1.36
Oficjalny komunikat projektu Kubernetes z 22 kwietnia 2026 roku podaje, że wersja 1.36 zawiera 70 usprawnień: 18 funkcji awansowało do Stable, 25 weszło do Beta, a 25 trafiło do Alpha. Sama liczba nie mówi jednak najważniejszego. W tej wersji widać wyraźnie, że Kubernetes nadrabia techniczny dług wokół bezpieczeństwa kontenerów, kontroli dostępu do kubeleta, walidacji API, zasobów sprzętowych i obserwowalności na poziomie jądra.
Dla admina Linuksa szczególnie ważne są cztery obszary:
- User Namespaces GA — izolacja użytkowników w Podach staje się stabilnym mechanizmem, a nie eksperymentalnym dodatkiem.
- Deprecacja Service
.spec.externalIPs— projekt Kubernetes formalnie odchodzi od funkcji, która zakłada zbyt wysoki poziom zaufania do użytkowników klastra. - PSI Metrics GA — Pressure Stall Information z kernela Linuksa staje się stabilnym sygnałem do diagnozowania realnej presji CPU, pamięci i I/O.
- DRA dla akceleratorów — Dynamic Resource Allocation dojrzewa w kierunku bardziej elastycznej i bezpiecznej obsługi GPU oraz wyspecjalizowanego sprzętu dla AI/HPC.
To nie są zmiany kosmetyczne. Każda z nich dotyczy typowych problemów operacyjnych: jak uruchamiać mniej zaufane workloady, jak wykrywać przeciążenie zanim użytkownicy zgłoszą awarię, jak nie pozwolić zwykłym użytkownikom klastra na przejmowanie adresów IP oraz jak rozsądnie współdzielić drogie akceleratory.
User Namespaces GA: root w kontenerze nie musi być rootem na hoście
23 kwietnia 2026 roku projekt Kubernetes opublikował osobny opis User Namespaces w wersji 1.36. Najważniejszy konkret: wsparcie dla User Namespaces w Kubernetes osiągnęło status General Availability i jest funkcją linuksową. W praktyce oznacza to możliwość uruchomienia Poda tak, aby użytkownik root widziany wewnątrz kontenera nie odpowiadał bezpośrednio UID 0 na hoście.
To ważne, bo przez lata „root w kontenerze” był tolerowany jako kompromis kompatybilności. Obraz aplikacji często startuje jako UID 0, instaluje pliki w czasie startu, potrzebuje pewnych capability albo zakłada standardowe prawa do katalogów. Jednocześnie z punktu widzenia bezpieczeństwa kontener z rootem zwiększa skutki błędnej konfiguracji wolumenu, podatności kernela lub nieszczelności runtime’u. User Namespaces nie rozwiązują całego problemu izolacji, ale zmniejszają znaczenie jednego z najbardziej nieprzyjemnych założeń: że root w kontenerze jest zbyt blisko roota hosta.
W Kubernetes 1.36 włączenie tej izolacji dla konkretnego Poda jest czytelne:
apiVersion: v1
kind: Pod
metadata:
name: isolated-workload
spec:
hostUsers: false
containers:
- name: app
image: fedora:42
securityContext:
runAsUser: 0Kluczowe jest hostUsers: false. Dla zespołów platformowych to dobry moment, aby przygotować politykę adopcji: najpierw dla nowych aplikacji, potem dla mniej krytycznych workloadów, a dopiero po testach dla systemów z nietypowymi wolumenami i wymaganiami capability. Warto też rozdzielić dwie sprawy: User Namespaces nie zastępują seccomp, AppArmor/SELinux, Pod Security Standards ani ograniczeń capability. To dodatkowa warstwa, która dobrze pasuje do podejścia defense in depth.
Praktyczny plan testów powinien obejmować runtime kontenerów, typy wolumenów i obrazy bazowe. Szczególną uwagę trzeba zwrócić na aplikacje, które zapisują na trwałych wolumenach, korzystają z plików z konkretnymi UID/GID lub uruchamiają procesy pomocnicze zakładające mapowanie użytkowników hosta. Jeżeli w organizacji funkcjonuje własny baseline manifestów, warto dodać do niego wariant z hostUsers: false i wymusić testy w środowisku staging.
Service externalIPs: deprecacja funkcji z niebezpiecznym modelem zaufania
14 maja 2026 roku projekt Kubernetes opisał formalną deprecację pola .spec.externalIPs w obiektach Service. To jedna z tych zmian, które mogą wydawać się niszowe, dopóki ktoś nie sprawdzi manifestów w starszym klastrze bare metal albo w środowisku budowanym bez klasycznego cloud load balancera.
Problem polega na tym, że .spec.externalIPs historycznie pozwalało dodać do Service adresy IP, na które usługa ma odpowiadać. API powstało w czasach innych założeń o zaufaniu w klastrze. W środowisku wielodostępnym zwykły użytkownik z prawem tworzenia lub modyfikowania Service może próbować wskazać adres, który nie powinien należeć do jego aplikacji. Kubernetes od wersji 1.21 rekomendował wyłączanie tej funkcji przez admission controller DenyServiceExternalIPs, ale w 1.36 projekt poszedł dalej i oznaczył pole jako deprecated.
Pierwsze zadanie po lekturze release notes jest proste: znaleźć, czy w klastrze w ogóle istnieją Service używające tego pola.
kubectl get svc -A -o json \
| jq -r '.items[]
| select(.spec.externalIPs != null and (.spec.externalIPs | length) > 0)
| [.metadata.namespace, .metadata.name, (.spec.externalIPs | join(","))]
| @tsv'Jeżeli wynik jest pusty, warto mimo to rozważyć blokadę przyszłego użycia. W klastrach zarządzanych zależy to od dostawcy, natomiast w instalacjach kontrolowanych przez zespół platformowy można uwzględnić admission controller w konfiguracji kube-apiservera. Przykładowy kierunek konfiguracji dla własnego control plane wygląda następująco:
# fragment konfiguracji kube-apiservera; nie wklejać bez sprawdzenia istniejącej listy pluginów
--enable-admission-plugins=NodeRestriction,DenyServiceExternalIPsW praktyce nie należy ślepo nadpisywać listy admission pluginów. Trzeba sprawdzić aktualną konfigurację, sposób instalacji klastra i wymagania dystrybucji. Ważny jest cel: nowi użytkownicy nie powinni móc wprowadzać externalIPs, a istniejące przypadki trzeba przepisać na bezpieczniejszy model, na przykład LoadBalancer zarządzany przez kontroler, MetalLB, Gateway API albo rozwiązanie sieciowe dostawcy infrastruktury.
PSI Metrics GA: mniej zgadywania, więcej sygnału z kernela
12 maja 2026 roku projekt Kubernetes opisał awans PSI Metrics do General Availability. PSI, czyli Pressure Stall Information, istnieje w jądrze Linuksa od 2018 roku i odpowiada na pytanie, którego zwykłe metryki wykorzystania zasobów często nie potrafią dobrze pokazać: ile czasu zadania tracą, bo czekają na CPU, pamięć lub I/O.
Dla SRE i administratorów to bardzo konkretna różnica. Wykorzystanie CPU na poziomie 70% nie musi oznaczać komfortowej sytuacji, jeżeli procesy stale czekają na scheduler. Podobnie pamięć może wyglądać „jeszcze dobrze” w klasycznym dashboardzie, ale aplikacje mogą już wpadać w opóźnienia przez reclaim, swap albo presję cgroup. PSI pomaga zobaczyć koszt oczekiwania, a nie tylko stan licznika.
Na pojedynczym hoście linuksowym można zacząć od najprostszego sprawdzenia:
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/ioW środowisku Kubernetes sens tej funkcji jest większy: administrator chce wiedzieć, czy problem dotyczy całego node’a, konkretnego Poda, czy grupy kontenerów w tej samej klasie workloadów. Awans do GA oznacza, że można bezpieczniej budować alerting i dashboardy wokół tego typu sygnałów, zamiast traktować je jako eksperyment. W praktyce dobrym krokiem jest dodanie PSI do runbooków dla incydentów typu „aplikacja ma losowe latency”, „node nie jest pełny, ale Pody zwalniają” albo „GPU stoi, bo pipeline czeka na I/O”.
DRA i AI: Kubernetes dojrzewa do świata drogich akceleratorów
7 maja 2026 roku zespół Kubernetes DRA opisał zmiany w Dynamic Resource Allocation w wersji 1.36. To szczególnie ważne dla klastrów używanych pod AI/ML, rendering, HPC, sieciówkę wysokiej przepustowości lub FPGA. Klasyczny model „pod żąda zasobu rozszerzonego, scheduler znajduje node” jest zbyt prosty, kiedy sprzęt jest heterogeniczny, dzielony, kosztowny i czasem wymaga przygotowania poza samym kubeletem.
W Kubernetes 1.36 część funkcji DRA awansowała do Stable i Beta. Priorytetowe listy wyboru urządzeń pomagają opisać preferencje zamiast sztywno kodować jeden model akceleratora. Partycjonowanie urządzeń w wersji Beta umożliwia dzielenie fizycznego sprzętu na logiczne instancje, co ma duże znaczenie przy drogich GPU. Device taints i tolerations pozwalają oznaczać konkretne urządzenia jako zarezerwowane, eksperymentalne lub wadliwe. Resource health status daje natomiast widoczność stanu urządzenia w statusie Poda, co upraszcza diagnozę crash loopów wynikających z problemów sprzętowych.
Dla admina oznacza to przesunięcie akcentu: GPU przestaje być tylko „etykietą na nodzie”, a zaczyna być zasobem zarządzanym podobnie jak infrastruktura produkcyjna. W klastrach AI warto przygotować osobną politykę dla akceleratorów: kto może żądać pełnego urządzenia, kto może korzystać z partycji, jak oznaczać sprzęt podejrzany o błędy, jak raportować health status do monitoringu i jak rozliczać wykorzystanie między zespołami.
Co sprawdzić przed migracją klastra
Kubernetes 1.36 nie powinien być wdrażany metodą „podbij wersję i obserwuj”. Lepiej potraktować go jako okazję do uporządkowania bezpieczeństwa i obserwowalności. Minimalna lista zadań dla zespołu platformowego powinna wyglądać następująco:
- Sprawdź aktualną gałąź klastra i okno wsparcia. Według strony wydań Kubernetes 1.36 ma aktualne wydanie 1.36.1 z 13 maja 2026 roku, a projekt utrzymuje najnowsze trzy gałęzie minor: 1.36, 1.35 i 1.34.
- Wyszukaj użycie
.spec.externalIPswe wszystkich namespace’ach i przygotuj migrację do bezpieczniejszego rozwiązania sieciowego. - Przetestuj
hostUsers: falsena wybranych workloadach, szczególnie tam, gdzie kontenery nadal startują jako UID 0. - Dodaj PSI do diagnostyki node’ów i incydentów wydajnościowych. Nie zastępuj nim klasycznych metryk, tylko uzupełnij o informację o czasie traconym na oczekiwanie.
- Jeżeli klaster obsługuje GPU lub inne akceleratory, przejrzyj roadmapę DRA, sterowniki urządzeń i zgodność z używaną dystrybucją Kubernetes.
- Sprawdź polityki RBAC wokół Service, Podów uprzywilejowanych, dostępu do kubeleta i namespace’ów zespołowych.
Warto też pamiętać o zależnościach od dystrybucji. Managed Kubernetes, kubeadm, Talos, RKE2, k3s, OpenShift czy własne klastry budowane z komponentów upstream mogą różnić się tempem udostępniania funkcji, domyślnymi feature gate’ami i sposobem konfiguracji control plane. Artykuły upstream mówią, co jest dostępne w projekcie Kubernetes; decyzja operacyjna musi uwzględnić konkretną platformę.
Krótkie podsumowanie praktyczne
Kubernetes 1.36 Haru jest ważny dla administratorów Linuksa nie dlatego, że dodaje efektowną pojedynczą funkcję, ale dlatego, że wzmacnia kilka miejsc, które realnie bolą w produkcji: izolację roota w kontenerach, ryzykowne Service externalIPs, diagnozowanie presji zasobów i zarządzanie akceleratorami AI. Najlepszy pierwszy krok to audyt manifestów pod kątem externalIPs, pilotaż User Namespaces na stagingu oraz włączenie PSI do runbooków wydajnościowych. Dopiero potem warto planować pełną migrację na gałąź 1.36.x.
