Ulepsz dodatek do siatki usług oparty na Istio dla usługi Azure Kubernetes.

Ten artykuł dotyczy doświadczeń związanych z aktualizacją dodatku dla siatki usług opartej na Istio w Azure Kubernetes Service (AKS).

Ogłoszenia o wydaniach nowych mniejszych rewizji lub poprawek do dodatku opartego na Istio, służącego do tworzenia siatki usług, są publikowane w notatkach wydania AKS. Aby dowiedzieć się więcej o harmonogramie wydania i wsparciu dla poprawek dodatku service mesh, przeczytaj politykę wsparcia.

Drobna aktualizacja wersji

Dodatek Istio umożliwia aktualizację mniejszej wersji za pomocą procesu aktualizacji typu kanarek. Gdy inicjowana jest aktualizacja, płaszczyzna kontrolna nowej (kanarek) rewizji jest wdrażana obok płaszczyzny kontrolnej początkowej (stabilnej) rewizji. Następnie możesz ręcznie przełączać obciążenie płaszczyzny danych, używając narzędzi monitorujących do śledzenia kondycji obciążeń w trakcie tego procesu. Jeśli nie zauważysz żadnych problemów ze zdrowiem swoich obciążeń, możesz dokończyć aktualizację, aby na klastrze pozostała tylko nowa wersja. W przeciwnym razie możesz przywrócić poprzednią wersję Istio.

Dostępne aktualizacje zależą od tego, czy aktualna wersja Istio oraz wersja klastra AKS są obsługiwane.

• Możesz zaktualizować do następnej obsługiwanej wersji (n+1) lub pominąć jedną i zaktualizować do n+2, o ile obie są obsługiwane i zgodne z wersją klastra.
• Jeśli zarówno Twoja obecna wersja (n), jak i kolejna wersja (n+1) są nieobsługiwane, możesz dokonać aktualizacji tylko do najbliższej obsługiwanej wersji (n+2 lub wyższej), ale nie dalej.
• Jeśli wersja klastra i rewizja Istio nie są obsługiwane, wersja klastra musi zostać zaktualizowana przed rozpoczęciem aktualizacji Istio.

Poniższy przykład pokazuje, jak przeprowadzić upgrade z rewizji asm-1-23 do asm-1-24 wraz ze wszystkimi obciążeniami w przestrzeni nazw default. Kroki są takie same dla wszystkich drobnych aktualizacji i mogą być używane dla dowolnej liczby przestrzeni nazw.

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

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

   Jeśli oczekujesz zobaczyć nowszą wersję, która nie jest zwracana przez to polecenie, może być konieczne najpierw zaktualizowanie twojego klastra AKS, aby był kompatybilny z najnowszą wersją.

2. Jeśli skonfigurujesz konfigurację siatki dla istniejącej wersji siatki w klastrze, musisz utworzyć osobny ConfigMap odpowiadający nowej wersji w przestrzeni nazw aks-istio-systemzanim rozpoczniesz aktualizację kanarkową w następnym kroku. Proponowana konfiguracja staje się stosowana w momencie, gdy płaszczyzna sterowania nowej wersji zostaje wdrożona w klastrze. Więcej szczegółów można znaleźć tutaj.

3. Rozpocznij kanaryjską aktualizację z rewizji asm-1-23 do asm-1-24 używając az aks mesh upgrade start:

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

   Aktualizacja typu canary oznacza, że płaszczyzna sterowania 1.24 jest wdrożona równolegle z płaszczyzną sterowania 1.23. Będą nadal współistnieć, dopóki nie zakończysz lub nie cofniesz aktualizacji.

   Chociaż aktualizacja canary jest w toku, wyższa wersja jest uznawana za domyślną wersję używaną do walidacji zasobów Istio.

4. Opcjonalnie, tagi rewizji mogą być używane, aby przełączyć płaszczyznę danych na nową rewizję bez konieczności ręcznego nadawania nowych etykiet każdej przestrzeni nazw. Ręczne zmienianie etykiet przestrzeni nazw podczas przenoszenia ich do nowej wersji może być żmudne i podatne na błędy. Revision tags rozwiązują ten problem, działając jako stabilne identyfikatory wskazujące na rewizje.

   Zamiast ponownego etykietowania każdej przestrzeni nazw, operator klastra może zmienić znacznik, aby wskazywał na nową wersję. Wszystkie przestrzenie nazw oznaczone tym tagiem są aktualizowane jednocześnie. Musisz jednak ponownie uruchomić obciążenia, aby upewnić się, że prawidłowe wersje istio-proxy sidecarów zostały wstrzyknięte.

   Aby używać tagów rewizji podczas uaktualnienia:

   1. Instalowanie interfejsu wiersza polecenia istioctl

   2. Utwórz znacznik rewizji dla początkowej wersji. Na tym przykładzie nazywamy to prod-stable:

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

   3. Utwórz tag wersji dla rewizji zainstalowanej podczas aktualizacji. Na tym przykładzie nazywamy to prod-canary:

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

   4. Oznacz przestrzenie nazw aplikacji, aby mapować na tagi rewizji.

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

      Możesz także oznaczyć przestrzenie nazw za pomocą istio.io/rev=prod-canary dla nowszej wersji. Jednak obciążenia w tych przestrzeniach nazw nie są aktualizowane do nowego sidecaru, dopóki nie zostaną ponownie uruchomione.

      Jeśli nowa aplikacja zostanie utworzona w przestrzeni nazw po jej oznaczeniu, zostanie wstrzyknięty sidecar odpowiadający tagowi rewizji w tej przestrzeni nazw.

5. Zweryfikuj, czy istnieją kontrolne pody płaszczyzny odpowiadające zarówno asm-1-23, jak i asm-1-24.

   1. Zweryfikuj istiod pods:

      kubectl get pods -n aks-istio-system
      

      Przykładowy wynik:

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

   2. Jeśli ingress jest włączony, zweryfikuj pody ingress.

      kubectl get pods -n aks-istio-ingress
      

      Przykładowy wynik:

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

      Obserwuj, że pody bramki wejściowej obu wersji są rozmieszczone obok siebie. Jednak usługa i jej adres IP pozostają niezmienne.

6. Zmień oznaczenie przestrzeni nazw, aby nowe zasobniki były powiązane z bocznym kontenerem Istio związanym z nową wersją i jego płaszczyzną kontrolną.

   1. Jeśli używasz znaczników rewizji, nadpisz sam znacznik prod-stable, aby zmienić jego mapowanie.

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

      Zweryfikuj mapowania między tagami a rewizjami.

      istioctl tag list
      

      Oba znaczniki powinny wskazywać na nowo zainstalowaną wersję.

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

      W tym przypadku nie musisz ponownie oznaczać każdej przestrzeni nazw osobno.

   2. Jeśli nie używasz znaczników rewizji, przestrzenie nazw płaszczyzny danych muszą zostać oznaczone na nowo, aby wskazywały na nową rewizję.

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

   Zmiana etykietowania nie wpływa na obciążenia robocze, dopóki nie zostaną ponownie uruchomione.

7. Indywidualnie przetwórz każde obciążenie robocze aplikacji, restartując je. Przykład:

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

8. Sprawdź swoje narzędzia monitorujące i pulpity nawigacyjne, aby określić, czy wszystkie obciążenia robocze działają w prawidłowym stanie po ponownym uruchomieniu. Na podstawie wyniku masz dwie opcje.

   1. Ukończ aktualizację kanarka: Jeśli jesteś zadowolony, że wszystkie obciążenia działają w oczekiwanym zdrowym stanie, możesz ukończyć aktualizację kanarka. Ukończenie aktualizacji usuwa płaszczyznę kontrolną poprzedniej wersji i pozostawia płaszczyznę kontrolną nowej wersji na klastrze. Uruchom następujące polecenie, aby zakończyć aktualizację kanarkową:

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

   2. Cofnij aktualizację próbnej wersji: Jeśli zaobserwujesz jakiekolwiek problemy ze stanem zdrowia swoich obciążeń, możesz przywrócić poprzednią wersję Istio:

   • Zmień etykietę przestrzeni nazw na poprzednią wersję: Jeśli używasz tagów wersji:

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

     Lub, jeśli nie używasz znaczników rewizyjnych:

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

   • Cofnij obciążenia, aby używały sidecar odpowiadający poprzedniej wersji Istio poprzez ponowne ich uruchomienie.

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

   • Przywróć płaszczyznę sterowania do poprzedniej wersji:

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

   Znacznik rewizji prod-canary można usunąć.

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

9. Jeśli konfiguracja mesh została wcześniej ustawiona dla rewizji, możesz teraz usunąć ConfigMap dla rewizji, która została usunięta z klastra podczas pełnego procesu/odwracania zmian.

Drobne aktualizacje wersji z użyciem bram wejściowych i wyjściowych

Jeśli obecnie używasz bram wprowadzających Istio lub bram wyprowadzających Istio i przeprowadzasz uaktualnienie wersji pomocniczej, pamiętaj, że zasobniki i wdrożenia bramy wprowadzającej oraz wyprowadzającej Istio są wdrażane dla każdej wersji, ale usługa jest współużytkowana pomiędzy obiema wersjami.

Udostępniamy jedną LoadBalancer usługę 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. Podczas uaktualnienia kanaryjskiego, gdy dwie wersje istnieją równocześnie na klastrze, pody bramy wejściowej obu wersji obsługują przychodzący ruch.

Podobnie, podczas uaktualniania metodą kanaryjną, wszystkie zasobniki (pods) bramy ruchu wychodzącego we wszystkich poprawkach będą realizowane za pomocą jednej usługi ClusterIP.

Drobne poprawki wersji z dostosowaniami automatycznego skalowania horyzontalnego zasobników

Jeśli dostosowałeś ustawienia poziomego skalowania automatycznego (HPA) dla Istiod lub bram wejściowych, zwróć uwagę na następujące zachowanie dotyczące tego, jak ustawienia HPA są stosowane w obu wersjach, aby zachować spójność podczas aktualizacji kanarkowej:

• Jeśli zaktualizujesz specyfikację HPA przed rozpoczęciem aktualizacji, ustawienia z istniejącej (stabilnej) rewizji zostaną zastosowane do HPAs rewizji kanarkowej po zainstalowaniu nowego płaszczyzny sterowania.
• Jeśli zaktualizujesz specyfikację HPA, gdy aktualizacja kanarka jest w toku, specyfikacja HPA stabilnej wersji będzie miała pierwszeństwo i zostanie zastosowana do specyfikacji HPA wersji kanarka.
  • Jeśli zaktualizujesz HPA stabilnej wersji podczas uaktualnienia, specyfikacja HPA wersji canary zostanie zaktualizowana, aby odzwierciedlić nowe ustawienia zastosowane do stabilnej wersji.
  • Jeśli zaktualizujesz HPA rewizji kanarka podczas aktualizacji, specyfikacja HPA rewizji kanarka zostanie przywrócona do specyfikacji HPA rewizji stabilnej.

Aktualizacja wersji patcha

• Informacje o dostępności wersji poprawkowych dodatku Istio są publikowane w notatkach o wydaniu AKS.
• Łatki są wdrażane automatycznie dla istiod i pods ingress jako część tych wydań AKS, które uwzględniają defaultzaplanowane okno konserwacyjne ustawione dla klastra.
• Użytkownik musi zainicjować aktualizacje do Istio proxy w swoich obciążeniach poprzez ponowne uruchomienie podów w celu wstrzyknięcia.

  • Sprawdź wersję proxy Istio przeznaczoną dla nowych lub ponownie uruchomionych podów. Ta wersja jest taka sama jak wersja istiod i zasobników wejściowych Istio po wprowadzeniu poprawek.

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

    Przykładowy wynik:

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

  • Sprawdź wersję obrazu proxy Istio dla wszystkich podó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ładowy wynik:

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

  • Aby uruchomić ponowne zastrzyki, zrestartuj obciążenie pracą. Przykład:

    kubectl rollout restart deployments/productpage-v1 -n default
    

  • Aby zweryfikować, że są teraz na nowszych wersjach, ponownie sprawdź wersję obrazu Istio proxy dla wszystkich podrzędnych 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ładowy wynik:

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