Istotna aktualizacja: 2 września 2026
Tytuł zachowuje publiczny adres artykułu, ale decyzja operacyjna uległa zmianie: nie należy dziś planować aktualizacji do Kubernetes 1.33. Ta wersja zakończyła wsparcie 28 czerwca 2026 roku i nie otrzymuje poprawek błędów ani bezpieczeństwa. Zespół nadal korzystający z 1.33 potrzebuje kontrolowanej migracji przez kolejne wersje minor do wersji wspieranej przez projekt Kubernetes oraz własnego dostawcę platformy.
Kubernetes 1.33 pozostaje istotnym punktem na ścieżce migracji. Wydanie z 23 kwietnia 2025 roku zawierało 64 zmiany: 18 funkcji przeszło do stable, 20 do beta, 24 weszły do alpha, a 2 zostały zdeprecjonowane lub wycofane. Te liczby opisują zakres wydania, ale nie są planem aktualizacji. Plan musi wynikać ze stanu konkretnego klastra, zależności aplikacyjnych i ograniczeń operatora chmury.
Zmień cel z „wdrożyć wersję” na „odzyskać wspierany stan”
Pierwszą decyzją jest wersja docelowa. Na 2 września 2026 roku upstream utrzymuje trzy najnowsze gałęzie minor: 1.35, 1.36 i 1.37, co potwierdza bieżąca Version Skew Policy. Usługa zarządzana może mieć inny harmonogram, dostępne patch releases i ograniczenia dodatków. Właściciel platformy powinien potwierdzić cel w dokumentacji dostawcy, a nie zakładać, że najnowszy upstream jest natychmiast dostępny.
Nie wolno pomijać wersji minor. Oficjalna procedura kubeadm upgrade wskazuje wprost, że taki skok jest niewspierany. Klaster 1.33 musi więc przejść przez 1.34, a następnie przez kolejne wymagane wersje. Każdy etap jest osobnym wdrożeniem z walidacją, nawet jeżeli organizacja chce skrócić odstęp między oknami.
Cel powinien obejmować najnowszy patch wybranej gałęzi, zgodność dodatków i termin opuszczenia wersji przejściowej. Sam zielony status control plane nie oznacza jeszcze odzyskania wspieranego stanu całej platformy.
Zbuduj dossier rzeczywistego stanu klastra
Przed pierwszą zmianą trzeba zebrać dane, które pozwolą odtworzyć decyzję. Dossier powinno zawierać wersje kube-apiserver, kubelet i kubectl, topologię control plane, tryb etcd, system operacyjny i container runtime na węzłach, CNI, CSI, ingress lub Gateway API, service mesh, autoskalery, policy engine, operatory oraz wszystkie CRD.
Druga warstwa to użycie API. Należy przejrzeć manifesty w repozytoriach, obiekty obecne w klastrze, logi ostrzeżeń o deprecacji oraz wywołania wykonywane przez kontrolery i skrypty. Kubernetes 1.33 formalnie zdeprecjonował podstawowe API Endpoints na rzecz EndpointSlice. Oficjalny opis migracji zaznacza, że dotyczy to klientów odczytujących lub zapisujących Endpoints bezpośrednio; nie wystarczy więc przeszukać manifestów aplikacji.
Każda zależność musi mieć właściciela i dowód wsparcia dla następnej wersji. „Powinna działać” nie jest wpisem w macierzy zgodności. Akceptowalnym dowodem jest wspierana wersja producenta, test na reprezentatywnym klastrze albo jawnie zaakceptowany plan zastąpienia komponentu.
Usuń blokery API i dodatków przed oknem produkcyjnym
Zmiany kompatybilności powinny trafić na produkcję jeszcze przed właściwą aktualizacją, o ile starsza wersja je obsługuje. Dotyczy to migracji API, aktualizacji CRD, webhooków admission, klientów generowanych oraz konfiguracji feature gates. Dzięki temu okno aktualizacji nie łączy zmiany platformy z dużą zmianą aplikacyjną.
W 1.33 usunięto pole status.nodeInfo.kubeProxyVersion, wcześniej wyłączone domyślnie, oraz wycofano eksperymentalną obsługę host network dla Windows Pods. Zespół powinien sprawdzić własne integracje, dashboardy i automatyzację zamiast zakładać, że zmiana dotyczy tylko użytkowników rzadkiej funkcji. Kod obserwacyjny odczytujący usunięte pole może nie zatrzymać klastra, ale może pozbawić zespół sygnału podczas incydentu.
Warto również usunąć zależności od niejawnych ustawień domyślnych. Jeżeli zachowanie scheduler, kubelet lub kontrolera ma znaczenie dla usługi, oczekiwanie powinno być zapisane w konfiguracji i teście. Release notes są wejściem do analizy, nie gotową oceną wpływu.
Przećwicz sekwencję na klastrze canary
Klaster canary musi reprezentować produkcję pod względem sposobu instalacji, sieci, storage, polityk i krytycznych klas workloadów. Pusty klaster potwierdza jedynie, że instalator potrafi uruchomić komponenty. Potrzebne są syntetyczne lub zanonimizowane obciążenia sprawdzające DNS, service discovery, ingress, wolumeny, autoscaling, disruption budgets, jobs, webhooks i obserwowalność.
Test powinien odtworzyć dokładną sekwencję wersji oraz poleceń planowanych na produkcji. Dla kubeadm control plane aktualizuje się węzeł po węźle, potem dodatkowe control plane, dodatki i workery. Węzły robocze należy drenować pojedynczo lub małymi grupami, utrzymując zdolność obsługi ruchu i krytycznych podów.
Canary nie eliminuje ryzyka. Jego rolą jest wykrycie konkretnych niezgodności i zebranie czasu wykonania. Po próbie runbook powinien zawierać rzeczywiste czasy drain, ponownego planowania podów, odtworzenia storage i stabilizacji metryk, a nie wartości skopiowane z poprzedniego projektu.
Oddziel rollback aplikacji od odzyskania control plane
Przed oknem należy wykonać i sprawdzić backup krytycznego stanu, w tym etcd lub mechanizmu zapewnianego przez dostawcę oraz danych aplikacyjnych. Sam fakt utworzenia snapshotu nie potwierdza możliwości odtworzenia. Dowodem jest zakończona próba restore w izolowanym środowisku wraz z pomiarem integralności i czasu.
Rollback Kubernetes nie powinien być opisywany jak cofnięcie zwykłego deploymentu. Zmiany danych przechowywanych, wersji etcd, konfiguracji komponentów i zachowania kontrolerów mogą ograniczać bezpieczny powrót. Dla każdego kroku trzeba więc określić ostatni punkt, w którym możliwe jest wycofanie, oraz scenariusz odzyskania, gdy przekroczono tę granicę.
Migracje aplikacyjne wykonywane w tym samym okresie powinny być backward-compatible z obiema wersjami platformy. Jeżeli nie są, wymagają osobnego właściciela ryzyka i kolejności, która nie uzależnia przywrócenia control plane od nieodwracalnej zmiany danych.
Zamknij etap dowodami, nie brakiem alarmu
Każdy skok minor powinien mieć warunki wejścia i wyjścia. Przed rozpoczęciem: zdrowe control plane i etcd, gotowe węzły, pojemność na drain, aktualny backup, zatwierdzona macierz zgodności oraz brak nierozwiązanych użyć usuwanych API. Po zakończeniu: zgodne wersje komponentów, brak nowych ostrzeżeń o deprecacji, działające krytyczne ścieżki, poprawna replikacja danych, stabilne SLI i ukończony okres obserwacji.
Warto mierzyć czas przebywania na wersji niewspieranej, liczbę pozostałych użyć deprecated API, odsetek dodatków z potwierdzonym wsparciem, czas drain węzła, liczbę interwencji ręcznych i wynik testu restore. Sukcesem nie jest „upgrade zakończony”, lecz powrót do wersji wspieranej z kompletem dowodów operacyjnych i następnym terminem aktualizacji wpisanym do backlogu platformy.
Źródła
- Kubernetes v1.33: Octarine — Kubernetes v1.33 Release Team, 23 kwietnia 2025.
- Kubernetes 1.33 release status — Kubernetes, EOL 28 czerwca 2026.
- Version Skew Policy — Kubernetes, stan na 2 września 2026.
- Upgrading kubeadm clusters — Kubernetes, stan na 2 września 2026.
- Kubernetes v1.33: Continuing the transition from Endpoints to EndpointSlices — Kubernetes, 24 kwietnia 2025.