Uaktualnianie dodatku siatki usługi opartej na technologii Istio dla usługi Azure Kubernetes Service

  • Artykuł

W tym artykule omówiono środowiska uaktualniania dodatku siatki usług opartej na technologii Istio dla usługi Azure Kubernetes Service (AKS).

Ogłoszenia dotyczące wydań nowych poprawek pomocniczych lub poprawek do dodatku siatki usługi Istio są publikowane w informacjach o wersji usługi AKS.

Uaktualnienie poprawki pomocniczej

Dodatek Istio umożliwia uaktualnienie poprawki pomocniczej przy użyciu procesu uaktualniania kanarowego. Po zainicjowaniu uaktualnienia płaszczyzna sterowania nowej (kanarowej) poprawki jest wdrażana wraz ze starą (stabilną) płaszczyzną sterowania poprawki. Następnie można ręcznie przerzucać obciążenia płaszczyzny danych podczas korzystania z narzędzi do monitorowania w celu śledzenia kondycji obciążeń podczas tego procesu. Jeśli nie zauważysz żadnych problemów z kondycją obciążeń, możesz ukończyć uaktualnienie, aby tylko nowa poprawka pozostała w klastrze. W przeciwnym razie możesz wycofać się do poprzedniej poprawki istio.

Jeśli klaster używa obecnie obsługiwanej wersji pomocniczej istio, uaktualnienia są dozwolone tylko jedną poprawkę pomocniczą naraz. Jeśli klaster korzysta z nieobsługiwanej poprawki istio, należy uaktualnić do najniższej obsługiwanej wersji pomocniczej istio dla tej wersji rozwiązania Kubernetes. Następnie uaktualnienia można wykonać pojedynczo jedną poprawkę pomocniczą.

Poniższy przykład ilustruje sposób uaktualniania z wersji asm-1-18 do asm-1-19. Kroki są takie same w przypadku wszystkich drobnych uaktualnień.

  1. Użyj polecenia az aks mesh get-upgrades, aby sprawdzić, które poprawki są dostępne dla klastra jako cele uaktualniania:

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    Jeśli spodziewasz się, że nowsza wersja nie zostanie zwrócona przez to polecenie, może być konieczne najpierw uaktualnienie klastra usługi AKS, aby był zgodny z najnowszą poprawką.

  2. Jeśli skonfigurowaliśmy konfigurację siatki dla istniejącej poprawki siatki w klastrze, należy utworzyć oddzielną ConfigMap odpowiadającą nowej poprawce w aks-istio-system przestrzeni nazw przed zainicjowaniem uaktualnienia kanary w następnym kroku. Ta konfiguracja ma zastosowanie do momentu wdrożenia nowej płaszczyzny sterowania poprawki w klastrze. Więcej informacji można znaleźć tutaj.

  3. Zainicjuj uaktualnienie kanary z wersji asm-1-18 do asm-1-19 polecenia za pomocą polecenia az aks mesh upgrade start:

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-19

    Uaktualnienie kanary oznacza, że płaszczyzna sterowania 1.18 jest rozmieszczona wraz z płaszczyzną sterowania 1.17. Będą one nadal współistnieć do momentu ukończenia lub wycofania uaktualnienia.

  4. Sprawdź zasobniki płaszczyzny sterowania odpowiadające obu asm-1-18 zasobnikom i asm-1-19 istnieją:

    • Sprawdź istiod zasobniki:

      kubectl get pods -n aks-istio-system

      Przykładowe wyjście:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-18-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-18-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-19-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-19-f85f46bf5-8p9qx             1/1     Running   0          51m

    • Jeśli ruch przychodzący jest włączony, sprawdź zasobniki ruchu przychodzącego:

      kubectl get pods -n aks-istio-ingress

      Przykładowe wyjście:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-18-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-krq9w   1/1     Running   0          51m

      Zwróć uwagę, że zasobniki bramy ruchu przychodzącego obu wersji są wdrażane obok siebie. Jednak usługa i jej adres IP pozostają niezmienne.

  5. Ponownie zatwierdź przestrzeń nazw, aby wszystkie nowe zasobniki mogły uzyskać przyczepkę Istio skojarzoną z nową poprawką i jej płaszczyzną sterowania:

    kubectl label namespace default istio.io/rev=asm-1-19 --overwrite

    Ponowne etykietowanie nie wpływa na obciążenia, dopóki nie zostaną ponownie uruchomione.

  6. Pojedynczo przerzucaj poszczególne obciążenia aplikacji, uruchamiając je ponownie. Na przykład:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  7. Sprawdź narzędzia do monitorowania i pulpity nawigacyjne, aby określić, czy wszystkie obciążenia działają w dobrej kondycji po ponownym uruchomieniu. Na podstawie wyniku masz dwie opcje:

    • Ukończ uaktualnienie kanary: jeśli masz pewność, że wszystkie obciążenia działają w dobrej kondycji zgodnie z oczekiwaniami, możesz ukończyć uaktualnienie kanary. Ukończenie uaktualnienia usuwa płaszczyznę sterowania poprzedniej poprawki i pozostawia płaszczyznę sterowania nowej poprawki w klastrze. Uruchom następujące polecenie, aby ukończyć uaktualnianie kanary:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    • Wycofywanie uaktualnienia kanarku: jeśli zauważysz problemy z kondycją obciążeń, możesz przywrócić poprzednią wersję programu Istio:

      • Ponownie podaj przestrzeń nazw do poprzedniej poprawki:

        kubectl label namespace default istio.io/rev=asm-1-18 --overwrite

      • Wycofaj obciążenia, aby użyć przyczepki odpowiadającej poprzedniej poprawce istio, ponownie uruchamiając te obciążenia:

        kubectl rollout restart deployment <deployment name> -n <deployment namespace>

      • Wycofaj płaszczyznę sterowania do poprzedniej poprawki:

        az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER

  8. Jeśli konfiguracja siatki została wcześniej skonfigurowana dla poprawek, możesz teraz usunąć ConfigMap dla poprawki, która została usunięta z klastra podczas zakończenia/wycofywania.

Uwaga

Ręczne ponowne etykietowanie przestrzeni nazw podczas przenoszenia ich do nowej poprawki może być żmudne i podatne na błędy. Tagi poprawek rozwiążą ten problem. Tagi poprawek są stabilnymi identyfikatorami wskazującymi poprawki i mogą służyć do unikania ponownego oznaczania przestrzeni nazw. Zamiast ponownie oznaczać przestrzeń nazw, operator siatki może po prostu zmienić tag, aby wskazywał nową poprawkę. Wszystkie przestrzenie nazw oznaczone tym tagiem zostaną zaktualizowane w tym samym czasie. Należy jednak pamiętać, że nadal trzeba ponownie uruchomić obciążenia, aby upewnić się, że wprowadzana jest poprawna wersja istio-proxy przyczepek.

Drobne uaktualnienia poprawek z bramą ruchu przychodzącego

Jeśli obecnie używasz bram ruchu przychodzącego Istio i przeprowadzasz uaktualnienie wersji pomocniczej, pamiętaj, że zasobniki/wdrożenia bramy ruchu przychodzącego Istio są wdrażane na wersję. Jednak udostępniamy jedną usługę LoadBalancer we wszystkich zasobnikach bramy ruchu przychodzącego w wielu poprawkach, więc zewnętrzny/wewnętrzny adres IP bram ruchu przychodzącego nie zmieni się w trakcie uaktualniania.

W związku z tym podczas uaktualniania kanargu, gdy w klastrze istnieją jednocześnie dwie poprawki, ruch przychodzący będzie obsługiwany przez zasobniki bramy ruchu przychodzącego obu poprawek.

Uaktualnianie wersji poprawki

  • Informacje o dostępności wersji dodatku Istio są publikowane w informacjach o wersji usługi AKS.
  • Poprawki są wdrażane automatycznie dla zasobników istiod i przychodzących w ramach tych wydań usługi AKS, które przestrzegają zaplanowanego defaultokna obsługi skonfigurowanego dla klastra.
  • Użytkownik musi zainicjować poprawki do serwera proxy Istio w swoich obciążeniach, uruchamiając ponownie zasobniki w celu ponownego uruchomienia:

    • Sprawdź wersję serwera proxy Istio przeznaczoną dla nowych lub ponownie uruchomionych zasobników. Ta wersja jest taka sama jak wersja zasobników ruchu przychodzącego istiod i Istio po ich wprowadzeniu poprawek:

      kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Przykładowe wyjście:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless"

    • Sprawdź wersję obrazu serwera proxy Istio dla wszystkich zasobników w przestrzeni nazw:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Przykładowe wyjście:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-distroless

    • Aby wyzwolić ponowne uruchamianie, uruchom ponownie obciążenia. Na przykład:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Aby sprawdzić, czy są teraz w nowszych wersjach, sprawdź ponownie wersję obrazu serwera proxy Istio dla wszystkich zasobników w przestrzeni nazw:

      kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort |\
grep "mcr.microsoft.com\/oss\/istio\/proxyv2"

      Przykładowe wyjście:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless