22 kwietnia 2026 r. projekt Kubernetes wydał wersję 1.36 o nazwie kodowej Haru. Dla osób utrzymujących klastry na Linuksie nie jest to kosmetyczny release. Najważniejsze zmiany dotykają miejsc, które w praktyce decydują o bezpieczeństwie i operacyjności środowiska: dostępu do API kubeleta, diagnostyki awarii sprzętu, spójnych snapshotów wolumenów, limitów CSI, podpisywania tokenów ServiceAccount oraz porządków w przestarzałych mechanizmach, takich jak gitRepo i service.spec.externalIPs.
Cykl wydania Kubernetes 1.36 trwał od 12 stycznia 2026 r. do 22 kwietnia 2026 r. Według zespołu wydawniczego w samym Kubernetes udział wniosło 491 osób ze 106 firm, a w szerszym ekosystemie cloud native liczby te rosną do 2235 kontrybutorów i 370 firm. To ważne, bo Kubernetes coraz rzadziej jest tylko „warstwą orkiestracji kontenerów”. W środowiskach produkcyjnych staje się systemem operacyjnym dla obciążeń rozproszonych, uruchamianym najczęściej na hostach Linux, z bezpośrednim wpływem na sieć, storage, akceleratory, tożsamość i model uprawnień.
Najważniejsza zmiana bezpieczeństwa: fine-grained kubelet API authorization
W Kubernetes 1.36 do stanu General Availability awansowała funkcja Fine-grained kubelet API authorization. Feature gate KubeletFineGrainedAuthz pojawił się jako alpha w Kubernetes 1.32, był domyślnie włączony w becie od Kubernetes 1.33, a w 1.36 jest już funkcją stabilną.
Praktyczny sens tej zmiany jest prosty: nie trzeba już tak często nadawać szerokiego uprawnienia nodes/proxy, żeby narzędzia monitoringu i observability mogły korzystać z wybranych endpointów HTTPS API kubeleta. W starszym modelu zbyt łatwo było tworzyć role, które dawały więcej dostępu, niż wymagał rzeczywisty przypadek użycia. W klastrach wielozespołowych, z Prometheusem, agentami security, autoscalerami i kontrolerami third-party, takie nadmiarowe uprawnienia robią się trudne do audytu.
Dla administratora Linuksa oznacza to konkretny punkt do przeglądu po aktualizacji: role RBAC, które zawierają nodes/proxy, powinny zostać ocenione pod kątem minimalizacji uprawnień. Nie każda rola musi zniknąć od razu, ale warto sprawdzić, czy dana integracja naprawdę potrzebuje ogólnego proxy do kubeleta, czy może wystarczy bardziej zawężony dostęp do konkretnego zasobu API.
kubectl get clusterrole -o json \
| jq -r '.items[] | select(.rules[]? | (.resources // []) | index("nodes/proxy")) | .metadata.name'
kubectl get clusterrolebinding -o json \
| jq -r '.items[] | select(.roleRef.name as $r | $r != null) | [.metadata.name, .roleRef.name] | @tsv'Takie polecenia nie rozwiązują audytu automatycznie, ale dają szybki punkt startowy. Warto połączyć wynik z listą komponentów monitoringu, agentów EDR/CWPP, operatorów i kontrolerów, które działają w klastrze. Szczególną uwagę trzeba poświęcić rolom nadawanym namespace’om użytkowników, bo to tam szeroki dostęp do kubeleta najłatwiej staje się boczną ścieżką eskalacji.
Status zdrowia urządzeń: lepsza diagnostyka GPU, NIC i akceleratorów
Drugą zmianą istotną dla platform opartych o Linux jest awans pola allocatedResourcesStatus w statusie Poda do wersji beta. Kubernetes 1.36 rozszerza mechanizm raportowania zdrowia przydzielonych urządzeń, tak aby administrator mógł zobaczyć, czy crash loop kontenera ma związek ze statusem sprzętu oznaczonym jako Unhealthy albo Unknown.
To szczególnie ważne w klastrach z GPU, kartami sieciowymi wysokiej przepustowości, DPU, FPGA albo innymi urządzeniami przydzielanymi przez device plugins lub Dynamic Resource Allocation. Bez takiej informacji awaria bywała widoczna tylko jako kolejny restart kontenera, błąd aplikacji albo nieczytelny komunikat z runtime’u. W praktyce administrator musiał łączyć logi kubeleta, pluginu urządzenia, runtime’u kontenerowego i aplikacji. Kubernetes 1.36 przesuwa część tej diagnostyki bliżej standardowego modelu Poda.
kubectl describe pod -n ml inference-worker-0
kubectl get pod -n ml inference-worker-0 -o json \
| jq '.status.containerStatuses, .status.allocatedResourcesStatus'W środowiskach AI i HPC ta zmiana może skrócić czas od zgłoszenia „model przestał działać” do decyzji operacyjnej: przenieść workload, odłączyć wadliwy node, zrestartować plugin urządzenia, sprawdzić sterownik jądra albo otworzyć incydent sprzętowy. Dla zespołów SRE sensowne będzie też dodanie alertów lub automatycznych reakcji na statusy urządzeń, o ile używane pluginy i sterowniki raportują te informacje w przewidywalny sposób.
Storage: snapshoty grup wolumenów i dynamiczne limity CSI
Kubernetes 1.36 stabilizuje VolumeGroupSnapshot. Funkcja pozwala wykonywać crash-consistent snapshoty wielu PersistentVolumeClaim jednocześnie, przez zestaw rozszerzeń API dla grup snapshotów. To nie jest pełny backup aplikacyjny z gwarancją spójności transakcyjnej na poziomie bazy danych, ale jest to ważny krok dla systemów, które rozkładają dane na kilka wolumenów.
Typowy przykład to aplikacja z osobnym wolumenem na dane, log transakcyjny i indeksy, albo system stateful, w którym kilka PVC musi zostać odtworzonych z tego samego punktu w czasie. Do tej pory administratorzy często ratowali się skryptami, operatorami specyficznymi dla dostawcy storage albo wykonywaniem snapshotów po kolei, co zwiększało ryzyko niespójnego punktu odtworzenia. W 1.36 mechanizm grupowy staje się stabilnym elementem platformy, choć nadal wymaga wsparcia po stronie sterownika CSI i odpowiednich CRD.
Do stabilnych funkcji awansowały też mutable volume attach limits dla CSINode. Sterownik CSI może dynamicznie aktualizować maksymalną liczbę wolumenów obsługiwanych przez node. Dla administratorów to mniej ręcznego strojenia i mniej sytuacji, w których scheduler podejmuje decyzję na podstawie przestarzałej informacji o możliwościach noda. W praktyce warto po aktualizacji sprawdzić dokumentację własnego sterownika CSI, bo korzyść pojawi się tylko wtedy, gdy driver faktycznie używa tej funkcji.
ServiceAccount tokens: zewnętrzny signer jako stabilny element układanki
W Kubernetes 1.36 stabilny stał się również external ServiceAccount token signer. Klaster może delegować podpisywanie tokenów ServiceAccount do zewnętrznego systemu, zachowując integrację z Kubernetes API i standardowym formatem tokenów. Dla organizacji z mocnymi wymaganiami compliance to istotne, bo klucze podpisujące mogą być obsługiwane przez dedykowany system, zamiast pozostawać wyłącznie częścią konfiguracji control plane.
Nie jest to funkcja, którą trzeba włączyć w każdym klastrze. W małych instalacjach zarządzanych przez jednego operatora dodatkowy signer może zwiększyć złożoność. W środowiskach enterprise, gdzie rotacja kluczy, separacja obowiązków i centralne zarządzanie materiałem kryptograficznym są formalnym wymaganiem, Kubernetes 1.36 daje stabilniejszy fundament pod taką architekturę.
Workload Aware Scheduling: alpha, ale warto obserwować
Kubernetes 1.36 wprowadza zestaw funkcji Workload Aware Scheduling w stanie alpha. Ich cel to traktowanie powiązanych Podów jako jednej logicznej całości przy planowaniu. Dotyczy to zwłaszcza zadań rozproszonych, batch processingu, treningu modeli AI i systemów, w których uruchomienie tylko części Podów nie ma sensu albo wręcz marnuje zasoby.
Kubernetes 1.35 wspierał już gang scheduling przez wymaganie minimalnej liczby Podów gotowych do zaplanowania. W 1.36 koncepcja idzie dalej przez PodGroup scheduling cycle, w którym grupa może zostać związana z nodami atomowo: albo całość, albo nic. Ponieważ to alpha, nie należy opierać na tym krytycznej produkcji bez świadomego planu testów. Warto jednak śledzić rozwój, bo presja ze strony workloadów AI i HPC będzie rosła, a klasyczny scheduler traktujący Pody zbyt indywidualnie ma w takich scenariuszach ograniczenia.
Koniec gitRepo volume driver: sprawdź manifesty przed aktualizacją
Najbardziej bezpośrednia zmiana migracyjna dotyczy gitRepo volume driver. Ten typ wolumenu był przestarzały od Kubernetes 1.11, ale w praktyce długo pozostawał technicznie dostępny. W Kubernetes 1.36 plugin gitRepo jest trwale wyłączony i nie można go ponownie włączyć. Zespół Kubernetes wskazuje tu także aspekt bezpieczeństwa: użycie gitRepo mogło prowadzić do krytycznego scenariusza wykonania kodu jako root na nodzie.
To dobry przykład zmiany, której nie wolno zostawić na etap „po upgrade”. Jeśli w repozytoriach manifestów, Helm chartach albo generatorach YAML nadal istnieje gitRepo, workload po aktualizacji może po prostu nie wystartować. Zalecane alternatywy to między innymi init container klonujący repozytorium do współdzielonego wolumenu albo narzędzia w stylu git-sync, zależnie od wymagań aplikacji.
kubectl get pods -A -o json \
| jq -r '.items[] | select(.spec.volumes[]? | has("gitRepo")) | [.metadata.namespace, .metadata.name] | @tsv'
rg -n "gitRepo:|externalIPs:" ./manifests ./charts ./deployWarto skanować zarówno żywy klaster, jak i repozytoria z deklaratywną konfiguracją. Sam klaster pokazuje tylko to, co jest aktualnie uruchomione. Repozytorium pokaże także ścieżki wdrożeniowe, środowiska testowe, stare chart values i konfiguracje, które mogą wrócić przy następnym rolloutcie.
externalIPs z ostrzeżeniami deprecacyjnymi
Kubernetes 1.36 zaczyna wyświetlać ostrzeżenia deprecacyjne dla pola service.spec.externalIPs, a pełne usunięcie zaplanowano na Kubernetes 1.43. To daje sporo czasu, ale nie oznacza, że temat można ignorować. externalIPs od dawna bywa mechanizmem wygodnym, lecz kłopotliwym operacyjnie i bezpieczeństwowo, szczególnie w środowiskach wielozespołowych, gdzie przypisanie zewnętrznego IP do Service może mieć konsekwencje wykraczające poza namespace.
Projekt Kubernetes sugeruje rozważenie alternatyw: Service typu LoadBalancer dla środowisk chmurowych, NodePort dla prostszej ekspozycji portu albo Gateway API dla bardziej elastycznego i kontrolowanego routingu. Dla administratorów oznacza to konieczność inwentaryzacji, a następnie zaplanowania migracji według krytyczności usług.
- Sprawdź role RBAC używające
nodes/proxyi ogranicz je tam, gdzie integracje mogą działać z mniejszym zakresem uprawnień. - Zweryfikuj, czy używane device plugins i sterowniki DRA raportują zdrowie urządzeń widoczne przez
allocatedResourcesStatus. - Przetestuj VolumeGroupSnapshot z konkretnym sterownikiem CSI, zanim wpiszesz go do procedury odtwarzania.
- Usuń
gitRepoz manifestów przed migracją do Kubernetes 1.36. - Zrób listę Service korzystających z
externalIPsi przypisz im docelowy model ekspozycji.
Plan praktycznej aktualizacji
Przed przejściem na Kubernetes 1.36 warto potraktować ten release jak zmianę platformową, nie tylko podbicie numeru wersji. Najpierw należy sprawdzić zgodność dystrybucji Kubernetes, runtime’u kontenerowego, CNI, CSI, ingress controllera, narzędzi backupowych i operatorów. Potem warto uruchomić testy na środowisku staging z manifestami produkcyjnymi, zwracając szczególną uwagę na wolumeny, Service, autoryzację kubeleta i workloady korzystające z GPU lub innych urządzeń.
kubeadm upgrade plan
kubectl get nodes -o wide
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.externalIPs != null) | [.metadata.namespace, .metadata.name, (.spec.externalIPs | join(","))] | @tsv'Jeżeli klaster jest zarządzany przez dostawcę chmury, termin dostępności Kubernetes 1.36 będzie zależał od harmonogramu tego dostawcy. Nie zmienia to jednak pracy przygotowawczej: audyt manifestów, RBAC i zależności można wykonać wcześniej. W środowiskach self-managed aktualizacja wymaga dodatkowo sprawdzenia wersji kubeadm, kubeletów, konfiguracji systemd, reguł firewalla, pluginów CNI i polityk utrzymania pakietów na hostach Linux.
Podsumowanie praktyczne
Kubernetes 1.36 Haru to wydanie, które wzmacnia kierunek znany z ostatnich cykli: mniej domyślnie szerokich uprawnień, więcej informacji diagnostycznych w API i stopniowe usuwanie starych mechanizmów obciążonych ryzykiem. Najpilniejsze działania dla admina lub zespołu DevOps to audyt nodes/proxy, wyszukanie gitRepo, inwentaryzacja externalIPs i testy storage oraz device plugins na stagingu. Dopiero po tych krokach aktualizacja do 1.36 będzie rutynowym wdrożeniem, a nie polowaniem na nieoczywiste regresje w produkcji.