Udostępnij za pośrednictwem

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. Aby dowiedzieć się więcej o harmonogramie wydania i obsłudze poprawek dodatku usługi Service Mesh, przeczytaj zasady pomocy technicznej.

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 z początkową (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ą.

W poniższym przykładzie pokazano, jak uaktualnić wersję asm-1-22 do asm-1-23 wszystkich obciążeń w default przestrzeni nazw. Kroki są takie same dla wszystkich uaktualnień pomocniczych i mogą być używane dla dowolnej liczby przestrzeni nazw.

  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 skonfigurujesz konfigurację siatki dla istniejącej poprawki siatki w klastrze, musisz 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-22 do asm-1-23 polecenia za pomocą polecenia az aks mesh upgrade start:

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

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

  4. Opcjonalnie tagi poprawek mogą służyć do przerzucania płaszczyzny danych do nowej poprawki bez konieczności ręcznego ponownego etykietowania każdej przestrzeni nazw. Ręczne ponowne etykietowanie przestrzeni nazw podczas przenoszenia ich do nowej poprawki może być żmudne i podatne na błędy. Tagi poprawek rozwiązać ten problem, służąc jako stabilne identyfikatory wskazujące poprawki.

    Zamiast ponownie oznaczać każdą przestrzeń nazw, operator klastra może zmienić tag tak, aby wskazywał nową poprawkę. Wszystkie przestrzenie nazw oznaczone tym tagiem są aktualizowane w tym samym czasie. Jednak nadal trzeba ponownie uruchomić obciążenia, aby upewnić się, że jest wstrzykiwana poprawna wersja istio-proxy przyczepek.

    Aby użyć tagów poprawek podczas uaktualniania:

    1. Instalowanie interfejsu wiersza polecenia istioctl

    2. Utwórz tag poprawki dla początkowej poprawki. W tym przykładzie nadamy mu prod-stablenazwę :

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. Utwórz tag poprawki dla poprawki zainstalowanej podczas uaktualniania. W tym przykładzie nadamy mu prod-canarynazwę :

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. Etykietuj przestrzenie nazw aplikacji do mapowania na tagi poprawek:

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      Możesz również oznaczyć przestrzeń nazw etykietą istio.io/rev=prod-canary dla nowszej poprawki. Jednak obciążenia w tych przestrzeniach nazw nie są aktualizowane do nowego przyczepki, dopóki nie zostaną ponownie uruchomione.

      Jeśli nowa aplikacja zostanie utworzona w przestrzeni nazw po jej oznaczeniu, przyczepka zostanie wstrzyknięta odpowiadająca tagowi poprawek w tej przestrzeni nazw.

  5. Sprawdź zasobniki płaszczyzny sterowania odpowiadające obu asm-1-22 zasobnikom i asm-1-23 istnieją:

    1. Sprawdź istiod zasobniki:

      kubectl get pods -n aks-istio-system

      Przykładowe wyjście:

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

    2. 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-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-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.

  6. Ponownie dołącz przestrzeń nazw, aby wszystkie nowe zasobniki zostały zamapowane na przyczepkę Istio skojarzoną z nową poprawką i jej płaszczyzną sterowania:

    1. W przypadku używania tagów poprawek zastąp prod-stable sam tag, aby zmienić jego mapowanie:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      Sprawdź mapowania tag-to-revision:

      istioctl tag list

      Oba tagi powinny wskazywać nowo zainstalowaną poprawkę:

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      W takim przypadku nie trzeba ponownie oznaczać każdej przestrzeni nazw pojedynczo.

    2. Jeśli nie używasz tagów poprawek, przestrzenie nazw płaszczyzny danych muszą zostać ponownie etykietowane, aby wskazać nową poprawkę:

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

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

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

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

  8. 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:

    1. 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

    2. 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: w przypadku używania tagów poprawek:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      Lub, jeśli nie używać tagów poprawek:

      kubectl label namespace default istio.io/rev=asm-1-22 --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

    prod-canary Tag poprawki można usunąć:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. 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.

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 pozostaje niezmieniony w trakcie uaktualniania.

W związku z tym podczas uaktualniania kanargu, gdy w klastrze istnieją jednocześnie dwie poprawki, zasobniki bramy ruchu przychodzącego obu wersji obsługują ruch przychodzący.

Drobne uaktualnienia poprawek z dostosowaniami skalowania automatycznego zasobnika poziomego

Jeśli dostosowano ustawienia automatycznego skalowania zasobników poziomych (HPA) dla bram Istiod lub bram ruchu przychodzącego, zwróć uwagę na następujące zachowanie dotyczące sposobu stosowania ustawień HPA w obu poprawkach w celu zachowania spójności podczas uaktualniania kanargu:

  • Jeśli zaktualizujesz specyfikację HPA przed zainicjowaniem uaktualnienia, ustawienia z istniejącej (stabilnej) poprawki zostaną zastosowane do hpA wersji kanarku po zainstalowaniu nowej płaszczyzny sterowania.
  • Jeśli zaktualizujesz specyfikację HPA, gdy uaktualnienie kanary jest w toku, specyfikacja HPA stabilnej wersji będzie mieć pierwszeństwo i zostanie zastosowana do HPA poprawki kanary.
    • W przypadku aktualizacji HPA stabilnej wersji podczas uaktualniania specyfikacja HPA poprawki kanarku zostanie zaktualizowana w celu odzwierciedlenia nowych ustawień zastosowanych do stabilnej poprawki.
    • W przypadku aktualizacji HPA wersji kanarowej podczas uaktualniania specyfikacja HPA poprawki kanarku zostanie przywrócona do specyfikacji HPA stabilnej wersji.

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 default okna 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.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-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.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-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.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

Uwaga

Jeśli wystąpią problemy występujące podczas uaktualniania, zapoznaj się z artykułem dotyczącym rozwiązywania problemów z uaktualnieniami poprawek siatki