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. Pour en savoir plus sur la planification de mise en production et la prise en charge des révisions des modules complémentaires service de maillage, lisez la stratégie de prise en charge.

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 plan de contrôle de la révision initiale (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-22 vers la révision asm-1-23 avec toutes les charges de travail de l’espace de noms default. Les étapes sont identiques pour toutes les mises à niveau mineures et peuvent être utilisées pour un nombre quelconque d’espaces de noms.

  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-22 à asm-1-23 en utilisant az aks mesh upgrade start :

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

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

  4. Si vous le souhaitez, les balises de révision peuvent être utilisées pour restaurer le plan de données vers la nouvelle révision sans avoir à réétiqueter manuellement chaque espace de noms. 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 balises de révision résolvent ce problème en servant d’identificateurs stables qui pointent vers les révisions.

    Au lieu de réétiqueter chaque espace de noms, un opérateur de cluster peut 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, vous devez toujours redémarrer les charges de travail pour vous assurer que la bonne version des side-cars istio-proxy est injectée.

    Pour utiliser des balises de révision pendant une mise à niveau :

    1. Installer l’interface CLI istioctl

    2. Créez une balise de révision pour la révision initiale. Dans cet exemple, nous l’appelons prod-stable :

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

    3. Créez une balise de révision pour la révision installée pendant la mise à niveau. Dans cet exemple, nous l’appelons prod-canary :

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

    4. Étiquetez les espaces de noms d’application à mapper aux balises de révision :

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

      Vous pouvez également étiqueter des espaces de noms avec istio.io/rev=prod-canary pour la révision la plus récente. Toutefois, les charges de travail de ces espaces de noms ne sont pas mises à jour vers un nouveau side-car tant qu’elles ne sont pas redémarrées.

      Si une nouvelle application est créée dans un espace de noms après son étiquetage, un side-car est injecté, correspondant à la balise de révision de cet espace de noms.

  5. Vérifiez que les pods du plan de contrôle correspondant à asm-1-22 et asm-1-23 existent :

    1. vérifiez les pods istiod :

      kubectl get pods -n aks-istio-system

      Exemple de sortie :

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

      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.

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

    1. Si vous utilisez des balises de révision, remplacez la balise prod-stable elle-même pour modifier son mappage :

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

      Vérifiez les mappages de balise à révision :

      istioctl tag list

      Les deux balises doivent pointer vers la révision nouvellement installée :

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

      Dans ce cas, vous n’avez pas besoin de réétiqueter chaque espace de noms individuellement.

    2. Si vous n’utilisez pas de balises de révision, les espaces de noms du plan de données doivent être réétiquetés pour pointer vers la nouvelle révision :

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

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

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

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

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

    2. 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éétiquetez l’espace de noms à la révision précédente : si vous utilisez des balises de révision :

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

      Ou, si vous n’utilisez pas de balises de révision :

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

    La balise de révision prod-canary peut être supprimée :

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

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

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 pour 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 du contrôle de validité, lorsque deux révisions existent simultanément sur le cluster, les pods de passerelle d’entrée des deux révisions servent le trafic entrant.

Mises à niveau de révision mineures avec des personnalisations de mise à l’échelle automatique des pods horizontaux

Si vous avez personnalisé les paramètres de mise à l’échelle automatique des pods horizontaux (HPA) pour Istiod ou les passerelles d’entrée, notez le comportement suivant pour savoir comment les paramètres HPA sont appliqués entre les deux révisions pour maintenir la cohérence pendant une mise à niveau de contrôle de validité :

  • Si vous mettez à jour la spécification HPA avant de lancer une mise à niveau, les paramètres de la révision existante (stable) sont appliqués aux HPA de la révision du contrôle de validité lorsque le nouveau plan de contrôle est installé.
  • Si vous mettez à jour la spécification HPA pendant qu’une mise à niveau du contrôle de validité est en cours, la spécification HPA de la révision stable est prioritaire et est appliquée à l’HPA de la révision du contrôle de validité.
    • Si vous mettez à jour le HPA de la révision stable pendant une mise à niveau, la spécification HPA de la révision du contrôle de validité est mise à jour pour refléter les nouveaux paramètres appliqués à la révision stable.
    • Si vous mettez à jour le HPA de la révision du contrôle de validité pendant une mise à niveau, la spécification HPA de la révision du contrôle de validité est rétablie à la spécification HPA de la révision stable.

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