„Mamy usługę zarządzaną” nie odpowiada na pytanie, jaką implementację faktycznie uruchamiamy. Nazwa produktu zostaje, a pod nią może zmienić się mechanizm sterowania ruchem. To dobry moment, żeby otworzyć inwentarz, zanim otworzymy kalendarz migracji.
Potwierdzone fakty i zakres
Data wydarzenia: 28 września 2026. Google ogłosił wycofanie wsparcia dla warstwy sterowania ISTIOD w Cloud Service Mesh na GKE w Google Cloud: zarówno wariantu in-cluster, jak i zarządzanego. Wsparcie kończy się 1 marca 2028. Dla wariantu zarządzanego komunikat ostrzega również o utracie komunikacji przez sidecary w niezmodernizowanych klastrach po tym terminie. Wyjątkiem opisanym w komunikacie jest dalsze wsparcie in-cluster na Google Distributed Cloud (software only).
Nie jest to komunikat o końcu całego Istio. Docelowy wariant Cloud Service Mesh korzysta z TRAFFIC_DIRECTOR i API Istio. Sama zgodność nazw zasobów nie dowodzi zgodności używanych funkcji.
Dwie różne ścieżki
| Stan wyjściowy | Ścieżka opisana przez Google | Co sprawdzić przed decyzją |
|---|---|---|
| In-cluster: sterowanie w klastrze. | Migracja do wariantu zarządzanego na nowym klastrze, z stopniowym przekierowaniem ruchu. Instalowanie obu warstw sterowania na tym samym klastrze nie jest wspieraną ścieżką tej migracji. | Obsługiwane wersje i funkcje, pojemność nowego klastra, zależności aplikacji oraz możliwość bezpiecznego skierowania ruchu z powrotem. |
Zarządzany ISTIOD. | Modernizacja floty do TRAFFIC_DIRECTOR. Można ją inicjować samodzielnie albo korzystać ze ścieżki prowadzonej przez Google. | Zgodność floty, kolejność środowisk i odpowiedzialność za wycofanie zmiany. Po finalizacji modernizacji rollback nie jest już możliwy. |
Dokumentacja wskazuje różnice także na poziomie pól ServiceEntry i Sidecar. Weryfikator zgodności floty raportuje warunki, w tym MODERNIZATION_COMPATIBLE; aktualizacja wyniku po zmianie może potrwać do jednego dnia. Nie traktuj świeżo uruchomionej kontroli jak natychmiastowej odpowiedzi.
Interpretacja: zgodność konfiguracji to pierwszy dowód
Interpretacja ArchitectMentor: pozytywny wynik kontroli dostawcy jest potrzebny, ale nie zastępuje testu naszej usługi. Weryfikator nie zna wszystkich reguł biznesowych ani tego, co użytkownik uznaje za poprawny wynik. „Konfiguracja przyjęta” i „proces działa” to dwa różne zdania.
Fikcyjny przykład edukacyjny: aplikacja przyjmuje zamówienie, a potem wywołuje usługę zewnętrzną przez reguły mesh. Nie zakładamy, że ta integracja jest niezgodna ani że już uległa awarii. Pytanie brzmi: jaki test wykryje zmianę routingu lub polityki dostępu, zanim dotknie użytkownika?
Pakiet dowodów zamiast samego terminu
- Ustal rzeczywisty wariant. Zapisz dla każdej floty i klastra implementację sterowania, wersję, używane funkcje i właściciela. Wpis „Cloud Service Mesh” jest za mało szczegółowy do wyboru procedury.
- Zmapuj zależności. Połącz każdą istotną regułę routingu i dostępu z konkretnym wywołaniem aplikacji. Zapisz różnice względem docelowego wariantu oraz sposób ich rozwiązania.
- Przygotuj dwa rodzaje próby. Pozytywna: dozwolone wywołanie kończy się poprawnym wynikiem. Negatywna: niedozwolony klient nadal jest odrzucany. Samo sprawdzenie, że „wszystko odpowiada”, może przeoczyć zniknięcie ograniczenia dostępu.
- Dodaj warunki trudniejsze. Przetestuj restart workloadu, niedostępność zależności i istotne dla procesu limity czasu. Obserwuj błędy i opóźnienia na pełnej ścieżce, nie tylko gotowość poda.
- Ustal moment zatrzymania. Przed zmianą wskaż mierzalne kryteria przerwania, osobę podejmującą decyzję i dostępny mechanizm powrotu w wybranej procedurze. Nie zakładaj, że powrót jest możliwy po każdym jej etapie.
To propozycja planu weryfikacji, nie raport przeprowadzonych testów ani kompletna instrukcja migracji. Dobierz próbę do topologii, skali i wymagań usługi. Korzystaj z aktualnej procedury producenta; ten tekst nie zastępuje jej warunków wstępnych.
Decyzja, którą warto zapisać
Jeśli wymagane funkcje są wspierane, wybierz właściwą ścieżkę i zaplanuj kontrolowane przejście przed końcem wsparcia. Jeśli nie są, porównaj zmianę konfiguracji z utrzymywaniem OSS Istio lub rezygnacją z mesh. Te alternatywy wskazuje również dokumentacja Google. Własna obsługa oznacza jednak własną odpowiedzialność za aktualizacje i eksploatację; nie jest darmowym skrótem.
Zapisz w ADR: wariant wyjściowy, potrzebne funkcje, wybraną ścieżkę, właściciela ryzyka i dowody dopuszczenia. Termin w 2028 roku daje czas na przygotowanie. Nie daje gwarancji, że wszystkie zespoły będą wtedy gotowe.
Ucz się: dobierz zakres analizy wpływu zmiany → · Zapisz decyzję w ADR →
Porozmawiajmy o tym artykule
Podziel się uwagą lub zanonimizowanym przykładem. Komentarze sprawdza AI przed publikacją. Niejednoznaczne przypadki trafiają do moderatora.