Partager via

Mettre à niveau le module complémentaire de maillage de services basé sur Istio pour Azure Kubernetes Service

  • Article

Cet article aborde les expériences de mise à niveau pour le module complémentaire de maillage de service basé sur Istio pour Azure Kubernetes Service (AKS).

Les annonces relatives aux nouvelles révisions mineures ou aux correctifs du module complémentaire de maillage de service basé sur Istio sont publiées dans les notes de publication AKS.

Mise à niveau de révision mineure

Le module complémentaire Istio permet de mettre à niveau la révision mineure à l'aide du processus de mise à niveau axé contrôle de validité. Lorsqu'une mise à niveau est lancée, le plan de contrôle de la nouvelle révision (contrôle de validité) est déployé en même temps que l'ancien plan de contrôle de la révision (stable). Vous pouvez ensuite restaurer manuellement les charges de travail du plan de données lors de l'utilisation d'outils de surveillance pour suivre l'intégrité des charges de travail pendant ce processus. Si vous n'observez aucun problème avec l'intégrité de vos charges de travail, vous pouvez effectuer la mise à niveau afin que seule la nouvelle révision reste sur le cluster. Sinon, vous pouvez revenir à la révision précédente d'Istio.

Si le cluster utilise actuellement une révision mineure prise en charge d'Istio, les mises à niveau ne sont autorisées que pour une seule révision mineure à la fois. Si le cluster utilise une révision non prise en charge d'Istio, vous devez effectuer une mise à niveau vers la version mineure la plus basique prise en charge d'Istio pour cette révision de Kubernetes. Ensuite, les mises à niveau peuvent à nouveau être effectuées sur une révision mineure à la fois.

L'exemple suivant montre comment effectuer une mise à niveau de la révision asm-1-20 à asm-1-21. Les étapes sont les mêmes pour toutes les mises à niveau mineures.

  1. Utilisez la commande az aks mesh get-upgrades pour vérifier quelles révisions sont disponibles pour le cluster en tant que cibles de mise à niveau :

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

    Si vous prévoyez le retour d'une révision plus récente qui n'est pas générée par cette commande, vous devrez éventuellement mettre à niveau votre cluster AKS afin qu'il soit compatible avec la révision la plus récente.

  2. Si vous avez configuré la configuration de maillage pour la révision de maillage existante sur votre cluster, vous devez créer un ConfigMap distinct correspondant à la nouvelle révision dans l’espace de noms aks-istio-system avant de lancer la mise à niveau de contrôle de validité à l’étape suivante. Cette configuration est applicable quand le plan de contrôle de la nouvelle révision est déployé sur le cluster. Pour plus d’informations, cliquez ici.

  3. Lancez une mise à niveau de contrôle de validité de la révision asm-1-20 à asm-1-21 en utilisant az aks mesh upgrade start :

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

    Une mise à niveau de contrôle de validité signifie que le plan de contrôle 1.20 est déployé parallèlement au plan de contrôle 1.21. Les deux plans continuent de coexister jusqu'à ce que vous mettez à niveau ou restaurez la mise à niveau.

  4. Vérifiez que les pods du plan de contrôle correspondant à asm-1-20 et asm-1-21 existent :

    • vérifiez les pods istiod :

      kubectl get pods -n aks-istio-system

      Exemple de sortie :

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

    • si l'entrée est activée, vérifiez les pods d'entrée :

      kubectl get pods -n aks-istio-ingress

      Exemple de sortie :

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

      Notez que les pods de passerelle d'entrée des deux révisions sont déployés côte à côte. Toutefois, le service et son adresse IP restent immuables.

  5. Étiquetez à nouveau l'espace de noms afin que tous les nouveaux pods obtiennent le side-car Istio associé à la nouvelle révision et à son plan de contrôle :

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

    Le réétiquetage n'affecte pas vos charges de travail tant qu'elles ne sont pas redémarrées.

  6. Restaurez individuellement chacune de vos charges de travail d'application en les redémarrant. Par exemple :

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

  7. Vérifiez vos outils et tableaux de bord de surveillance pour déterminer si vos charges de travail s'exécutent dans un état d'intégrité après le redémarrage. En fonction du résultat, vous avez deux options :

    • Terminez la mise à niveau de contrôle de validité : si vous êtes satisfait que les charges de travail s'exécutent dans un état d'intégrité comme prévu, vous pouvez effectuer la mise à niveau de contrôle de validité. Une fois la mise à niveau terminée, le plan de contrôle de la révision précédente est supprimé et le plan de contrôle de la nouvelle révision est laissé en place sur le cluster. Exécutez la commande suivante pour terminer la mise à niveau de contrôle de validité :

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

    • Restaurer la mise à niveau de contrôle de validité : si vous observez des problèmes liés à l'intégrité de vos charges de travail, vous pouvez revenir à la révision précédente d'Istio :

      • Réétiqueter l’espace de noms en fonction de la révision précédente :

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

      • Restaurez les charges de travail pour utiliser le side-car correspondant à la révision Istio précédente en redémarrant ces charges de travail :

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

      • restaurez le plan de contrôle à la révision précédente :

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

  8. Si la configuration de maillage a été précédemment configurée pour les révisions, vous pouvez maintenant supprimer la ConfigMap pour la révision qui a été supprimée du cluster pendant l’achèvement/la restauration.

Remarque

le réétiquetage manuel des espaces de noms lorsqu'ils sont déplacés vers une nouvelle révision peut être fastidieux et source d'erreurs. Les étiquettes de révision résolvent ce problème. Les balises de révision sont des identificateurs stables qui pointent vers des révisions et peuvent être utilisés pour éviter le réétiquetage des espaces de noms. Au lieu d'étiqueter l'espace de noms, un opérateur de maillage peut simplement modifier la balise pour qu'elle pointe vers une nouvelle révision. Tous les espaces de noms étiquetés avec cette balise seront mis à jour en même temps. Toutefois, notez que vous devez toujours redémarrer les charges de travail pour vous assurer que la bonne version des side-cars istio-proxy est injectée.

Mises à niveau de révision mineures avec la passerelle d’entrée

Si vous utilisez actuellement les passerelles d’entrée Istio et vous effectuez une mise à niveau mineure de révision, gardez à l’esprit que les pods/déploiements de passerelle d’entrée Istio sont déployés par révision. Toutefois, nous fournissons un seul service LoadBalancer sur tous les pods de passerelle d’entrée sur plusieurs révisions. Par conséquent, l’adresse IP externe/interne des passerelles d’entrée ne changera pas tout au long d’une mise à niveau.

Par conséquent, lors de la mise à niveau canary, lorsque deux révisions existent simultanément sur le cluster, le trafic entrant sera servi par les pods de passerelle d’entrée des deux révisions.

Mise à niveau de version corrective

  • Les informations de disponibilité des versions de correctif du module complémentaire Istio sont publiées dans les notes de publication AKS.
  • Les patchs sont déployés automatiquement pour les pods istiod et d’entrée dans le cadre de ces versions AKS, qui respectent la defaultfenêtre de maintenance planifiée configurée pour le cluster.
  • L’utilisateur doit lancer des correctifs sur le proxy Istio dans ses charges de travail en redémarrant les pods pour la réinjection :

    • Vérifiez la version du proxy Istio destinée aux pods nouveaux ou redémarrés. Cette version est identique à la version des pods d’entrée Istiod et Istio une fois qu’ils ont été corrigés :

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

      Exemple de sortie :

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

    • Vérifiez la version de l’image de proxy Istio pour tous les pods d’un espace de noms :

      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"

      Exemple de sortie :

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

    • Pour déclencher la réinjection, redémarrez les charges de travail. Par exemple :

      kubectl rollout restart deployments/productpage-v1 -n default

    • Pour vérifier qu’ils sont désormais sur les versions plus récentes, vérifiez à nouveau la version de l’image de proxy Istio pour tous les pods de l’espace de noms :

      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"

      Exemple de sortie :

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

Remarque

En cas de problèmes rencontrés pendant les mises à niveau, reportez-vous à l’article sur la résolution des problèmes liés aux mises à niveau de révision de maillage