Kubernetes 1.36, wydany 22 kwietnia 2026 roku pod nazwą kodową Haru, nie jest wersją efektowną w marketingowym sensie. Jest za to wydaniem, które powinno zainteresować administratorów utrzymujących klastry na Linuksie, zespoły platformowe oraz osoby budujące środowiska pod obciążenia AI, batch i HPC. Na 7 czerwca 2026 roku najnowszą wersją z gałęzi 1.36 jest Kubernetes 1.36.1, opublikowany 13 maja 2026 roku, a koniec życia tej gałęzi zaplanowano na 28 czerwca 2027 roku.
Najważniejsze jest to, że kilka funkcji dojrzewa dokładnie w obszarach, w których produkcyjne klastry zwykle bolą najbardziej: obserwowalność realnej presji zasobów na węzłach Linux, przydzielanie akceleratorów przez Dynamic Resource Allocation, bezpieczniejsze aktualizacje wieloinstancyjnego API servera oraz porządkowanie starych mechanizmów sieciowych. To nie są zmiany do obejrzenia w labie i zapomnienia. To jest lista rzeczy do wpisania w plan aktualizacji platformy.
Co konkretnie zmieniło się w Kubernetes 1.36?
Oficjalne wydanie Kubernetes 1.36 obejmuje 70 usprawnień: 18 funkcji awansowało do statusu Stable, 25 weszło do Beta, a 25 trafiło do Alpha. Dla zespołów operacyjnych ważniejsze od samej liczby KEP-ów jest jednak to, że kilka zmian dotyka bezpośrednio codziennej diagnostyki i eksploatacji klastrów Linux.
- Pressure Stall Information jako GA — kubelet może stabilnie eksportować metryki presji CPU, pamięci i I/O oparte o mechanizm PSI z kernela Linux.
- Dynamic Resource Allocation dojrzewa — Kubernetes 1.36 rozwija DRA dla specjalizowanego sprzętu, w tym GPU, urządzeń partycjonowalnych i bardziej złożonych scenariuszy alokacji.
- Mixed Version Proxy jest Beta i domyślnie włączony — aktualizacje HA control plane mają być mniej podatne na błędne odpowiedzi 404 podczas wersji mieszanych.
- Service .spec.externalIPs jest zdeprecjonowane — użycie tego pola zaczyna generować ostrzeżenia, a projekt wskazuje LoadBalancer i Gateway API jako ścieżki migracji.
- User Namespaces w podach są Stable — istotne w środowiskach wielodzierżawczych i tam, gdzie izolacja kontenerów jest elementem modelu bezpieczeństwa.
- Node log query jest GA — łatwiejsza diagnostyka kubelet i kube-proxy bez logowania się przez SSH na węzeł.
Z punktu widzenia administratora Linuxa szczególnie ważne są PSI, DRA i externalIPs. Pierwsze poprawia jakość sygnałów monitoringu, drugie wpływa na sposób używania GPU i innych akceleratorów, trzecie wymusza przegląd starych manifestów usług.
PSI w GA: koniec patrzenia tylko na procent użycia CPU
Pressure Stall Information jest mechanizmem kernela Linux, który pokazuje, ile czasu zadania tracą, czekając na CPU, pamięć albo I/O. To ważna różnica względem klasycznych metryk wykorzystania. Węzeł może mieć CPU użyte w 70 procentach, a mimo to część aplikacji może odczuwać wysokie opóźnienia, bo procesy stoją w kolejce do schedulerów, blokują się na pamięci albo czekają na dysk.
W Kubernetes 1.36 metryki PSI kubeleta awansowały do General Availability. Oznacza to stabilny interfejs dla monitoringu presji zasobów na poziomie node, pod i container. W praktyce jest to dobry moment, aby dodać PSI do dashboardów SRE, reguł alertowych i analiz capacity planning. Szczególnie sensowne jest to w klastrach z wieloma tenantami, workloadami batch, bazami danych, systemami kolejkowymi oraz inferencją modeli, gdzie sama średnia utylizacja CPU lub pamięci często maskuje realne problemy.
Warunki brzegowe są istotne: węzły muszą działać na Linuksie z kernelem 4.20 lub nowszym, używać cgroup v2, mieć kernel zbudowany z CONFIG_PSI=y i nie mogą być uruchomione z parametrem psi=0. W Kubernetes 1.36 nie trzeba już włączać osobnej bramki funkcji po stronie kubeleta, ale system operacyjny nadal musi wspierać PSI.
# Szybka kontrola na węźle Linux
uname -r
mount | grep cgroup2 || true
zgrep CONFIG_PSI /proc/config.gz 2>/dev/null || grep CONFIG_PSI /boot/config-$(uname -r)
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/ioW klastrze można też odpytać Summary API przez proxy API servera. To operacja uprzywilejowana, więc nie należy rozdawać do niej dostępu szeroko. Przydaje się jednak do szybkiej diagnostyki, gdy trzeba sprawdzić, czy kontener cierpi z powodu realnej presji zasobów, a nie tylko „wysokiego zużycia” widocznego w standardowym dashboardzie.
CONTAINER_NAME=example-container
NODE=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
kubectl get --raw /api/v1/nodes/${NODE}/proxy/stats/summary \
| jq '.pods[].containers[] | select(.name==env.CONTAINER_NAME) | {name, cpu: .cpu.psi, memory: .memory.psi, io: .io.psi}'Dobra praktyka po aktualizacji do 1.36: nie budować alertu wyłącznie na pojedynczym piku. PSI udostępnia wartości pozwalające rozróżniać krótkie skoki i utrzymującą się presję. Warto więc patrzeć na okna czasowe oraz korelować PSI z throttlingiem CPU, OOMKilled, restartami podów, latency aplikacji i saturacją dysków.
DRA i akceleratory: Kubernetes dojrzewa pod AI oraz HPC
Dynamic Resource Allocation w Kubernetes 1.36 kontynuuje przejście od prostych device pluginów do bardziej ekspresyjnego modelu zarządzania specjalizowanym sprzętem. To ma znaczenie tam, gdzie klastry Linux obsługują GPU, karty sieciowe, DPU, FPGA albo inne zasoby, których nie da się sensownie traktować jak zwykłego CPU i RAM.
Wydanie 1.36 rozwija DRA między innymi przez obsługę scenariuszy związanych z urządzeniami partycjonowalnymi, pojemnością konsumowalną, statusem urządzeń w ResourceClaim oraz lepszą obsługą cyklu życia przydziału. Z punktu widzenia operatora platformy celem jest prostsze wyrażenie wymagań workloadu: nie tylko „daj mi GPU”, ale „daj mi preferowany typ urządzenia, a jeśli nie ma, użyj alternatywy”, „uwzględnij stan zdrowia zasobu” albo „nie planuj poda, dopóki zasób nie jest faktycznie możliwy do podłączenia”.
To szczególnie ważne dla zespołów wdrażających obciążenia AI. W praktyce koszt błędnego planowania GPU jest wysoki: zadanie treningowe może czekać, mimo że w klastrze istnieje akceptowalny zasób zastępczy; pod może trafić na urządzenie z problemami; autoscaler może podjąć decyzję na podstawie zbyt ubogiego modelu zasobów. DRA nie usuwa konieczności testowania sterowników, runtime i integracji vendorów, ale daje Kubernetesowi lepszy język do opisu sprzętu.
Mixed Version Proxy: mniej ryzyka podczas aktualizacji control plane
W klastrach HA aktualizacja control plane rzadko dzieje się w jednej atomowej chwili. Przez pewien czas kilka instancji kube-apiserver może działać w różnych wersjach i obsługiwać różne zestawy Group, Version, Resource. Bez dodatkowego mechanizmu klient może trafić na starszy API server, który nie zna żądanego zasobu, i dostać 404 Not Found, mimo że inna instancja API servera w tym samym klastrze potrafi ten zasób obsłużyć.
Kubernetes 1.36 promuje Mixed Version Proxy do Beta i włącza go domyślnie. Mechanizm wykorzystuje peer-aggregated discovery, aby API serwery wymieniały informacje o obsługiwanych zasobach i mogły przekierować żądanie do właściwego peera. To ma praktyczne znaczenie dla większych środowisk, w których aktualizacja control plane trwa dłużej, jest wykonywana falami albo musi być skoordynowana z dodatkowymi komponentami platformy.
Przy klastrach zarządzanych przez kubeadm warto sprawdzić konfigurację peer-ca-file oraz przetestować aktualizację w środowisku stagingowym. Nie chodzi o to, aby traktować MVP jako wymówkę dla chaotycznych upgrade’ów. Chodzi o dodatkową warstwę bezpieczeństwa w scenariuszu, który i tak występuje w produkcji: przez pewien czas control plane jest mieszany wersjami.
externalIPs: czas posprzątać stare usługi
Jedna z bardziej operacyjnych zmian dotyczy pola .spec.externalIPs w obiekcie Service. W Kubernetes 1.36 zostało ono formalnie zdeprecjonowane, a użycie zaczyna generować ostrzeżenia. Według zapowiedzianej ścieżki najwcześniej w Kubernetes 1.40 obsługa może zostać wyłączona w kube-proxy z możliwością czasowego powrotu, a najwcześniej w Kubernetes 1.43 usunięta całkowicie bez opcji ponownego włączenia.
Dla administratorów oznacza to prosty, ale ważny audyt. Trzeba znaleźć usługi, które nadal używają externalIPs, ustalić, czy robią to świadomie, oraz zaplanować migrację. Najczęstsze alternatywy to Service typu LoadBalancer z kontrolerem odpowiednim dla środowiska, na przykład w chmurze publicznej albo na bare metal z rozwiązaniem takim jak MetalLB, oraz Gateway API dla ruchu warstwy L7 i nowszych modeli routingu.
# Wyszukanie Service korzystających z externalIPs we wszystkich namespace'ach
kubectl get svc -A -o json \
| jq -r '.items[] | select(.spec.externalIPs != null) | [.metadata.namespace, .metadata.name, (.spec.externalIPs | join(","))] | @tsv'Ten przegląd warto wykonać przed aktualizacją, a nie dopiero po pojawieniu się ostrzeżeń w CI/CD lub przy wdrożeniu aplikacji. W starszych klastrach externalIPs bywało używane jako szybki skrót sieciowy. W 2026 roku lepiej traktować je jako dług techniczny, zwłaszcza w środowiskach wielozespołowych, gdzie kontrola nad adresacją IP powinna należeć do platformy, nie do przypadkowego manifestu aplikacji.
Co zrobić przed aktualizacją do 1.36?
Najrozsądniejszy plan nie zaczyna się od komendy kubeadm upgrade, tylko od krótkiego audytu. Kubernetes 1.36 jest wydaniem, które premiuje zespoły mające porządek w wersjach komponentów, politykach RBAC, monitoringu i manifestach sieciowych.
- Sprawdź aktualną wersję klastra oraz zgodność komponentów: kubelet, kube-proxy, CNI, CSI, ingress controller i dodatki obserwowalności.
- Zweryfikuj, czy węzły Linux używają cgroup v2 i mają włączone PSI na poziomie kernela.
- Dodaj metryki PSI do środowiska testowego monitoringu i porównaj je z dotychczasowymi alertami CPU, memory oraz I/O.
- Przeskanuj wszystkie namespace’y pod kątem Service z
.spec.externalIPsi przygotuj migrację do LoadBalancer albo Gateway API. - Jeśli używasz GPU lub innych akceleratorów, przejrzyj roadmapę vendorów i sterowników pod kątem integracji z DRA.
- Przetestuj aktualizację HA control plane w stagingu, zwracając uwagę na zachowanie Mixed Version Proxy i konfigurację peer CA.
- Przejrzyj RBAC dla dostępu do kubeleta, node logs, metrics i Summary API; nowe możliwości diagnostyczne nie powinny oznaczać zbyt szerokich uprawnień.
Podsumowanie praktyczne
Kubernetes 1.36 Haru to dobre wydanie dla administratorów linuksowych klastrów, bo wzmacnia fundamenty: mierzenie presji zasobów przez PSI, dojrzalsze zarządzanie akceleratorami przez DRA, bezpieczniejsze upgrade’y control plane i wyraźny sygnał, że externalIPs należy usuwać z manifestów. Najlepszy następny krok to uruchomienie audytu PSI, externalIPs i ścieżki aktualizacji w środowisku testowym, zanim gałąź 1.36 stanie się domyślnym celem produkcyjnych upgrade’ów.
