Google Cloud ogłosiło, że usługa GKE oferuje teraz ogólnodostępne (GA) dwuetapowe aktualizacje płaszczyzny sterowania (control-plane), co pozwala klientom oddzielić aktualizację binariów oprogramowania od migracji formatu danych i zachować możliwość wycofania zmian (rollback) podczas zmian wersji minornych.

Dlaczego GKE potrzebowało bezpieczniejszej ścieżki

Aktualizacja płaszczyzny sterowania Kubernetes z jednej wersji minornej do kolejnej zawsze wiązała się z ryzykiem. Przejście z wersji 1.33 do 1.34 nie polega jedynie na zastąpieniu binariów, ale także na przepisaniu struktur danych. Jeśli nowa wersja zawiera błąd, klastra nie można po prostu przywrócić do poprzedniego stanu; administratorzy muszą przywrócić stare migawki (snapshots) bazy danych lub odbudować cały klaster, co jest procesem czasochłonnym i podatnym na błędy.

Jak działa dwuetapowa aktualizacja

Nowy przepływ dzieli aktualizację na dwie odrębne fazy:

  • Krok 1 – Aktualizacja binariów (tryb emulowany). GKE podmienia binarne pliki płaszczyzny sterowania na docelową wersję, zachowując jednocześnie stary format danych. Ponieważ nie są zapisywane żadne nowe struktury danych, klaster pozostaje bezpieczny pod kątem możliwości wycofania zmian (rollback) przez cały ten etap.
  • Krok 2 – Finalizacja. Po skonfigurowanym okresie oczekiwania GKE konwertuje zapisane dane na nowy format. Po zakończeniu tej konwersji wycofanie zmian wymagałoby takiego samego wysiłku związanego z przywracaniem migawek, któremu proces dwuetapowy miał zapobiec.

To rozdzielenie tworzy „okno stabilizacji” (soak window), w którym operatorzy mogą obserwować zaktualizowane binarne pliki w środowisku produkcyjnym, nie decydując się jeszcze na nieodwracalną migrację danych.

Okno stabilizacji w praktyce

GKE automatycznie monitoruje kluczowe metryki stanu podczas okresu stabilizacji — opóźnienia API, współczynniki błędów oraz stan podów. Jeśli usługa wykryje anomalie, wstrzymuje wdrażanie, pozostawiając klaster w stanie „tylko binarne”, w którym wycofanie zmian jest wciąż możliwe. Google podaje, że wskaźnik sukcesu aktualizacji realizowanych według tego schematu wynosi 99,999%.

W przypadku klastrów korzystających z funkcji auto-upgrade w GKE, platforma koordynuje cały dwuetapowy proces bez konieczności ręcznej interwencji. Użytkownicy preferujący pełną kontrolę mogą uruchomić ten proces za pomocą Cloud CLI lub Terraform.

Uruchamianie ręcznej dwuetapowej aktualizacji

Typowa ręczna aktualizacja z 48-godzinnym oknem bezpieczeństwa wygląda następująco:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Aby sprawdzić aktualny status:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Jeśli podczas okresu stabilizacji pojawi się błąd, administrator może wydać polecenie rollback i wrócić do poprzedniej wersji bez utraty danych. Gdy klaster okaże się stabilny, aktualizację można ukończyć wcześniej za pomocą polecenia complete-control-plane-upgrade.

Ograniczenia i wymagania

  • Funkcja dotyczy klastrów GKE działających na wersji 1.33 lub nowszej.
  • W jednym czasie można zaktualizować tylko jedną wersję minorną; pomijanie wersji nie jest obsługiwane.
  • Zarówno klastry Autopilot, jak i regionalne pozostają dostępne przez cały dwuetapowy proces.

Potencjalne wady

Rozdzielenie aktualizacji binariów i danych dodaje dodatkowy krok do harmonogramu aktualizacji, co może wydłużyć całkowity czas operacji dla organizacji potrzebujących szybkich zmian wersji. Okres stabilizacji opiera się również na zautomatyzowanych kontrolach stanu; zespoły uruchamiające wysoce spersonalizowane obciążenia mogą potrzebować uzupełnić monitoring GKE o własne narzędzia do obserwacji (observability), aby wykryć regresje w nietypowych przypadkach.

Na co warto czekać w przyszłości

Google nie ujawniło mapy drogowej dotyczącej rozszerzenia modelu dwuetapowego na aktualizacje wersji majornych, które w wielu przypadkach wciąż wymagają pełnej rekonstrukcji klastra. Obserwatorzy będą wypatrywać ogłoszeń dotyczących podobnych zabezpieczeń dla aktualizacji pul węzłów (node-pools) oraz integracji z zewnętrznymi potokami CI/CD, które mogłyby automatyzować sprawdzanie w oknie stabilizacji.

Podsumowanie: Poprzez oddzielenie aktualizacji binariów od migracji danych, GKE zapewnia inżynierom platformowym praktyczne okno na wycofanie zmian (rollback) podczas aktualizacji wersji minornych, co zmniejsza koszty operacyjne utrzymania klastra przy jednoczesnym zminimalizowaniu przestojów.