Kubernetes 1.36.1, opublikowany 13 maja 2026 r., nie jest tylko rutynową łatką po wydaniu 1.36 „Haru” z 22 kwietnia 2026 r. Dla administratorów Linuksa i zespołów platformowych to dobry punkt kontrolny: sprawdzić wersje komponentów, przyjrzeć się uprawnieniom do API kubeleta, zaplanować migrację z przestarzałych mechanizmów ekspozycji usług i ocenić, czy node’y oparte o cgroup v2 oraz SELinux są już skonfigurowane pod nowe możliwości.
Najważniejsza zmiana nie polega na jednej spektakularnej funkcji. Kubernetes 1.36 składa się z wielu elementów, które razem przesuwają ciężar z „działa w klastrze” na „da się to bezpiecznie operować w produkcji”. W praktyce dotyczy to szczególnie klastrów linuksowych: kubelet, namespaces, SELinux, cgroup v2, CSI, DRA dla GPU i urządzeń specjalizowanych oraz polityki admission są bliżej codziennej administracji niż marketingowych slajdów o cloud native.
Co dokładnie się wydarzyło
W gałęzi 1.36 najnowszą wersją stabilną jest Kubernetes 1.36.1 z datą wydania 13 maja 2026 r. Projekt utrzymuje obecnie wspierane gałęzie 1.36, 1.35 i 1.34, a dla wersji 1.36 podaje koniec życia na 28 czerwca 2027 r. To ważne dla planowania okien serwisowych: klastry na 1.33 zbliżają się do końca wsparcia, a środowiska pozostające na starszych wydaniach powinny trafić na listę ryzyk operacyjnych.
Sama łatka 1.36.1 obejmuje poprawki regresji i błędów, między innymi w obszarze kubeleta, kube-proxy, kubeadm oraz Dynamic Resource Allocation. Z punktu widzenia admina istotne jest to, że pierwsza łatka po wydaniu minor często bywa rozsądniejszym celem produkcyjnego upgrade’u niż samo x.y.0. Jeżeli organizacja nie ma twardej potrzeby wejścia w 1.36.0 natychmiast po premierze, 1.36.1 daje lepszy punkt startowy do testów stagingowych.
Dlaczego to jest ważne dla Linuksa
Kubernetes jest warstwą orkiestracji, ale jego bezpieczeństwo i przewidywalność w dużej mierze opierają się na mechanizmach jądra Linuksa. W 1.36 widać to bardzo wyraźnie. User Namespaces w podach osiągnęły status Stable, eksport metryk Pressure Stall Information opartych o cgroup v2 również trafił do Stable, a Memory QoS dla node’ów z cgroup v2 rozwija się dalej. Do tego dochodzi szybsze etykietowanie wolumenów SELinux, które w 1.36 stało się GA.
W praktyce oznacza to trzy rzeczy. Po pierwsze, izolacja kontenerów może być mocniejsza bez polegania wyłącznie na runtime i profilach seccomp/AppArmor. Po drugie, obserwowalność zasobów na node’ach może pokazywać nie tylko zużycie CPU czy RAM, ale też realne zatory: kiedy procesy czekają na CPU, pamięć albo I/O. Po trzecie, klastry działające na dystrybucjach z SELinux w trybie enforcing — na przykład RHEL, Rocky Linux, AlmaLinux, Fedora CoreOS czy pochodne — dostają bardziej praktyczny model obsługi etykiet wolumenów.
User Namespaces: root w kontenerze to nie root na hoście
Stabilizacja User Namespaces w podach jest jedną z najważniejszych zmian bezpieczeństwa w Kubernetes 1.36. Mechanizm mapuje użytkownika root widocznego wewnątrz kontenera na nieuprzywilejowanego użytkownika po stronie hosta. To nie jest magiczna tarcza przeciw wszystkim ucieczkom z kontenera, ale bardzo sensowna warstwa defense-in-depth.
Dla zespołów utrzymujących klastry multi-tenant albo platformy CI/CD oznacza to konieczność przejrzenia workloadów, które zakładają bezpośredni dostęp do UID/GID hosta, montują wolumeny z konkretną własnością plików albo działają jako privileged. Największa wartość pojawia się tam, gdzie można konsekwentnie ograniczać uprawnienia podów, usuwać capability Linuksa i unikać hostPath.
- sprawdź pody z
securityContext.privileged: true; - znajdź workloady z
hostPID,hostIPCihostNetwork; - przejrzyj użycie
hostPath, szczególnie dla ścieżek/var/run,/var/libi/etc; - porównaj wymagania aplikacji z politykami Pod Security Admission;
- testuj User Namespaces najpierw na mniej krytycznych namespace’ach.
KubeletFineGrainedAuthz: koniec z nadmiernym nodes/proxy
Drugą zmianą, która zasługuje na osobny przegląd, jest GA dla fine-grained kubelet API authorization. Dotychczas część scenariuszy monitoringu i diagnostyki wymuszała przyznawanie szerokiego uprawnienia nodes/proxy. To wygodne, ale słabe z perspektywy least privilege: narzędzia obserwowalności nie powinny dostawać więcej niż realnie potrzebują.
Kubernetes 1.36 umożliwia dokładniejsze ograniczanie dostępu do HTTPS API kubeleta. To szczególnie istotne w środowiskach, gdzie wiele narzędzi pobiera metryki, logi albo informacje o podach z poziomu node’a. Po upgrade’zie warto wykonać audyt ról i bindingów, które używają nodes/proxy, nodes/log, nodes/stats lub podobnych zasobów. Celem nie jest masowe usuwanie uprawnień w ciemno, ale zmniejszenie blast radius w razie przejęcia konta serwisowego.
kubectl get clusterrole -o yaml | grep -nE 'nodes/(proxy|log|stats)|nodes:'
kubectl get clusterrolebinding -o wide
kubectl auth can-i get nodes/proxy --as=system:serviceaccount:monitoring:agent
kubectl auth can-i get nodes/log --as=system:serviceaccount:monitoring:agentJeżeli monitoring działa przez konto serwisowe z bardzo szeroką rolą klastrową, Kubernetes 1.36 jest dobrym momentem, aby rozdzielić uprawnienia: osobno metryki, osobno logi, osobno dostęp administracyjny. Takie porządki często są odkładane, dopóki nie pojawi się incydent. Warto zrobić je przed incydentem.
PSI i cgroup v2: obserwowalność bliżej jądra
Pressure Stall Information nie zastępuje klasycznych metryk CPU, pamięci i I/O, ale dodaje kontekst, którego często brakowało podczas analizy „wolnego” node’a. Wysokie użycie CPU nie zawsze oznacza problem; problemem jest sytuacja, w której workloady aktywnie czekają na zasób. PSI pomaga odróżnić node obciążony od node’a, który zaczyna się dławić.
Dla administratora Linuksa to bardzo praktyczna zmiana. Jeśli organizacja używa cgroup v2, warto sprawdzić, czy pipeline metryk — Prometheus, agent observability, dashboardy SRE — potrafi pokazać sygnały presji. To może pomóc w decyzjach o requests/limits, autoskalowaniu, rozdzielaniu hałaśliwych sąsiadów i identyfikacji workloadów powodujących I/O wait.
SELinux i wolumeny: mniej rekurencyjnego relabelingu, więcej odpowiedzialności
Kubernetes 1.36 wprowadza GA dla szybszego etykietowania wolumenów SELinux. Zamiast kosztownego rekurencyjnego przechodzenia po plikach, mechanizm może używać montowania z kontekstem SELinux. Zysk jest oczywisty: szybszy start podów, szczególnie przy dużych wolumenach. Ryzyko też jest konkretne: niewłaściwie dobrane etykiety albo współdzielenie wolumenu między podami uprzywilejowanymi i nieuprzywilejowanymi może powodować trudne do diagnozy błędy.
Przed upgrade’em należy sprawdzić workloady z własnym seLinuxOptions, sterowniki CSI oraz aplikacje, które współdzielą PVC między różnymi profilami bezpieczeństwa. Jeśli zespół korzysta z dystrybucji z SELinux enforcing, nie należy traktować tej zmiany jako „tylko optymalizacji”. To temat do testów regresyjnych aplikacji stanowych.
kubectl get pods -A -o json \
| jq -r '.items[] | select(.spec.securityContext.seLinuxOptions != null) | [.metadata.namespace,.metadata.name] | @tsv'
kubectl get csidriver -o yaml | grep -nE 'seLinuxMount|fsGroupPolicy'
kubectl get pvc -AIngress NGINX i CVE feed: sygnał ostrzegawczy dla starych instalacji
W komunikacie Kubernetes 1.36 znalazła się również informacja, że Ingress NGINX został wycofany 24 marca 2026 r. Od tej daty projekt nie przewiduje kolejnych wydań, poprawek błędów ani łatek bezpieczeństwa dla nowych podatności. Jednocześnie oficjalny Kubernetes CVE feed, zaktualizowany 3 czerwca 2026 r., wymienia kilka wpisów dotyczących ingress-nginx, między innymi CVE-2026-4342 oraz starsze problemy z wstrzykiwaniem konfiguracji nginx.
To nie oznacza, że każdy klaster natychmiast przestaje działać. Oznacza natomiast, że pozostawienie ingress-nginx jako domyślnej warstwy wejściowej bez planu migracji staje się decyzją ryzyka. Zespoły powinny zinwentaryzować kontrolery ingress, wersje chartów Helm, własne adnotacje oraz mechanizmy autoryzacji na brzegu klastra. Rozsądnym kierunkiem jest ocena Gateway API albo wspieranych kontrolerów ingress utrzymywanych przez konkretnego dostawcę.
Deprecacje i usunięcia: externalIPs oraz gitRepo
Kubernetes 1.36 deprecjonuje pole Service.spec.externalIPs, którego pełne usunięcie zaplanowano na wersję 1.43. To pole od lat jest problematyczne bezpieczeństwowo, bo może prowadzić do nieoczekiwanego przechwytywania ruchu w klastrze. Jeżeli w repozytoriach manifestów wciąż występuje externalIPs, należy przygotować migrację do Service typu LoadBalancer, NodePort albo Gateway API — zależnie od architektury.
Drugą istotną zmianą jest trwałe wyłączenie wolumenu gitRepo, który był zdeprecjonowany od Kubernetes 1.11. Workloady, które nadal klonują kod przez ten typ wolumenu, powinny zostać przeniesione na init container, sidecar typu git-sync albo proces budowania obrazu, w którym kod jest dostarczany przed uruchomieniem poda. Dla administratorów to dobry pretekst, aby przeskanować manifesty i stare Helm charty.
grep -R "externalIPs:" ./manifests ./charts
grep -R "gitRepo:" ./manifests ./charts
kubectl get svc -A -o json \
| jq -r '.items[] | select(.spec.externalIPs != null) | [.metadata.namespace,.metadata.name,(.spec.externalIPs|join(","))] | @tsv'Co zrobić przed upgrade’em do 1.36.1
Najlepszy plan nie zaczyna się od kubeadm upgrade apply, tylko od inwentaryzacji. W środowisku testowym warto odtworzyć realne polityki admission, kontrolery CSI, CNI, ingress, workloady stanowe oraz agenty monitoringu. Szczególnie uważnie należy sprawdzić komponenty dotykające kubeleta, wolumenów i bezpieczeństwa podów.
- Zweryfikuj, czy control plane, kubelet i kubectl mieszczą się w obsługiwanej polityce version skew.
- Przejrzyj role RBAC korzystające z szerokiego dostępu do node’ów.
- Sprawdź manifesty pod kątem
externalIPsigitRepo. - Przetestuj workloady z SELinux, PVC i CSI na środowisku staging.
- Upewnij się, że pipeline obserwowalności potrafi skorzystać z metryk PSI.
- Przygotuj plan migracji z ingress-nginx, jeśli nadal jest używany jako krytyczny komponent wejściowy.
Podsumowanie praktyczne
Kubernetes 1.36.1 jest wydaniem, które warto potraktować jako impuls do utwardzenia klastrów, a nie tylko kolejny numer wersji. Największy zysk dadzą: audyt RBAC wokół kubeleta, testy User Namespaces, przegląd SELinux i CSI, włączenie metryk związanych z presją zasobów oraz plan odejścia od ingress-nginx i przestarzałych pól w manifestach. Dla zespołów pracujących na Linuksie to konkretna okazja, aby zmniejszyć uprawnienia, poprawić izolację i lepiej widzieć, co dzieje się na node’ach.
