Résolution des problèmes de mise à niveau de révision mineure du module complémentaire De maillage de service Istio

Article
04/30/2024

Cet article décrit les scénarios de résolution des problèmes et les restrictions dans les processus mineurs de mise à niveau et de restauration des révisions pour le module complémentaire Istio Service Mesh dans Microsoft Azure Kubernetes Service (AKS).

Remarque

Istio utilise le terme « révisions » pour implémenter le processus de mise à niveau canary et faire la distinction entre les versions. Chaque désignation de révision (écrite sous la forme x-y) correspond à une désignation de version major.minor (x.y). Vous pouvez contrôler la révision de votre plan de contrôle, mais vous ne pouvez pas contrôler la version du correctif spécifique dans une bande de révision.

Configuration requise

Azure CLI.
L’outil Kubernetes kubectl , ou un outil similaire pour se connecter au cluster. Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

Matrice de résolution des problèmes

Le tableau suivant répertorie les différents problèmes, ainsi que les différents scénarios et solutions pour ces problèmes.

Scénario	Problème	Solution
Les charges de travail de plan de données sont supprimées du maillage.	Les révisions de plan de données et de plan de contrôle ne correspondaient pas avant la fin ou la restauration d’une mise à niveau.	Procédez comme suit : Réétiqueter les espaces de noms qui contiennent des charges de travail en spécifiant la révision qui doit exister après la fin de la mise à niveau ou la restauration. Pour ce faire, exécutez la commande kubectl label : kubectl label namespace default istio.io/rev=asm-x-y --overwrite Redémarrez les déploiements de charge de travail correspondants pour déclencher la réinjection side-car de la révision correcte. Pour ce faire, exécutez la commande kubectl rollout restart : kubectl rollout restart deployment <deployment name> Vérifiez que les images side-car existent. Pour ce faire, exécutez la commande kubectl get : kubectl get pods --namespace <namespace> --output yaml \| grep mcr.microsoft.com/oss/istio/proxyv2:
Les pods de plan de contrôle sont dans l’état en attente.	Les pods ne disposent pas de capacité.	Vérifiez l’état des pods en exécutant la commande kubectl describe . Si la capacité est le problème, vous pouvez effectuer un scale-up de votre cluster pour ajouter un autre nœud. Pour plus d’informations, consultez Mettre à l’échelle manuellement le nombre de nœuds dans un cluster Azure Kubernetes Service (AKS).
La commande az aks mesh get-upgrades ne retourne aucune mise à niveau disponible.	La révision Istio la plus récente peut être incompatible avec la version actuelle du cluster AKS.	Vous pouvez utiliser la commande az aks mesh get-revisions pour découvrir si des révisions Istio plus récentes existent. La sortie inclut une liste des versions de cluster compatibles pour chaque révision d’Istio. Par conséquent, vous pouvez déterminer si une mise à niveau de cluster est nécessaire.

Scénario

Problème

Solution

Les charges de travail de plan de données sont supprimées du maillage.

Les révisions de plan de données et de plan de contrôle ne correspondaient pas avant la fin ou la restauration d’une mise à niveau.

Procédez comme suit :

Réétiqueter les espaces de noms qui contiennent des charges de travail en spécifiant la révision qui doit exister après la fin de la mise à niveau ou la restauration. Pour ce faire, exécutez la commande kubectl label :
```
kubectl label namespace default istio.io/rev=asm-x-y --overwrite
```
Redémarrez les déploiements de charge de travail correspondants pour déclencher la réinjection side-car de la révision correcte. Pour ce faire, exécutez la commande kubectl rollout restart :
```
kubectl rollout restart deployment <deployment name>
```

Vérifiez que les images side-car existent. Pour ce faire, exécutez la commande kubectl get :

kubectl get pods --namespace <namespace> --output yaml | grep mcr.microsoft.com/oss/istio/proxyv2:

Les pods de plan de contrôle sont dans l’état en attente.

Les pods ne disposent pas de capacité.

Vérifiez l’état des pods en exécutant la commande kubectl describe . Si la capacité est le problème, vous pouvez effectuer un scale-up de votre cluster pour ajouter un autre nœud. Pour plus d’informations, consultez Mettre à l’échelle manuellement le nombre de nœuds dans un cluster Azure Kubernetes Service (AKS).

La commande az aks mesh get-upgrades ne retourne aucune mise à niveau disponible.

La révision Istio la plus récente peut être incompatible avec la version actuelle du cluster AKS.

Vous pouvez utiliser la commande az aks mesh get-revisions pour découvrir si des révisions Istio plus récentes existent. La sortie inclut une liste des versions de cluster compatibles pour chaque révision d’Istio. Par conséquent, vous pouvez déterminer si une mise à niveau de cluster est nécessaire.

Remarque

Pour éviter les comportements inattendus et les fonctionnalités rompues, et pour vous assurer que vous recevez des mises à jour pour les vulnérabilités de sécurité, nous vous recommandons vivement d’effectuer une mise à niveau vers une version AKS prise en charge et à jour et une révision du module complémentaire Istio. N’oubliez pas que la révision du module complémentaire doit également se trouver dans la plage de versions kubernetes prise en charge pour le cluster AKS donné. Comme indiqué dans la section Mise à niveau de révision mineure de l’article sur la mise à niveau d’Istio, vous pouvez exécuter les az aks mesh get-revisions commandes et az aks mesh get-upgrades pour en savoir plus sur les révisions, mises à niveau et informations de compatibilité des modules complémentaires disponibles.

Restrictions

Une rétrogradation vers une révision antérieure (en dehors du processus de restauration canary) n’est pas autorisée.
Passer d’une révision à une révision non obligatoire n’est autorisé que si AKS ne prend plus en charge la révision actuelle et la révision de mise à niveau suivante. À ce stade, la seule mise à niveau disponible est la révision la plus faible prise en charge.
L’étiquette Istio sidecar.istio.io/inject n’active pas l’injection de side-car pour le module complémentaire Istio. Vous devez utiliser l’étiquette istio.io/rev lorsque vous étiquetez et réétiquetez vos espaces de noms pendant la mise à niveau canary.
L’étiquetage doit se produire au niveau de l’espace de noms au lieu d’un niveau par déploiement. Si vous souhaitez pouvoir restaurer des pods individuellement, vous pouvez choisir de redémarrer des déploiements individuels au lieu d’utiliser l’étiquetage des pods.
Si vous utilisez le module complémentaire Istio Shared MeshConfig, vous devez copier ou transférer les paramètres MeshConfig vers le nouveau ConfigMap avant d’effectuer une mise à niveau canary. Pour plus d’informations, consultez Configuration et mises à niveau du maillage.
Le module complémentaire Istio déploie les pods de passerelle d’entrée Istio et les déploiements par révision. Si vous effectuez une mise à niveau canary et que deux révisions de plan de contrôle sont installées dans votre cluster, vous devrez peut-être résoudre les problèmes de plusieurs pods de passerelle d’entrée sur les deux révisions.

References

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via