Résolution des problèmes de mise à niveau de la mise à niveau de révision mineure du 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 de mise à niveau et de restauration mineures pour le module complémentaire Istio Service Mesh dans Microsoft Azure Kubernetes Service (AKS).

Note

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 en tant que x-y) correspond à une désignation de version majeure.mineure (x.y). Vous pouvez contrôler la révision de votre plan de contrôle, mais vous ne pouvez pas contrôler la version de correctif spécifique dans une bande de révision.

Prerequisites

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 différents problèmes et les différents scénarios et solutions pour ces problèmes.

Scénario	Problème	Solution
Les charges de travail du plan de données sont supprimées du maillage.	Les révisions de plan de données et de plan de contrôle ne correspondent pas avant la fin ou la restauration d’une mise à niveau.	Effectuez les étapes suivantes : Espaces de noms Relabel qui contiennent des charges de travail en spécifiant la révision attendue après la fin ou la restauration de la mise à niveau. 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 sidecar 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 manquent 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 dernière révision Istio peut être incompatible avec la version actuelle du cluster AKS.	Vous pouvez utiliser la commande az aks mesh get-revisions pour déterminer si des révisions Istio plus récentes existent. La sortie inclut une liste de versions de cluster compatibles pour chaque révision 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 du plan de données sont supprimées du maillage.

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

Effectuez les étapes suivantes :

Espaces de noms Relabel qui contiennent des charges de travail en spécifiant la révision attendue après la fin ou la restauration de la mise à niveau. 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 sidecar 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 manquent 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 dernière révision Istio peut être incompatible avec la version actuelle du cluster AKS.

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

Note

Pour éviter les comportements inattendus et les fonctionnalités interrompues, et assurez-vous également que vous recevez des mises à jour pour les vulnérabilités de sécurité, nous vous recommandons vivement de procéder à 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 de mise à niveau d’Istio, vous pouvez exécuter les az aks mesh get-revisions commandes et az aks mesh get-upgrades les commandes pour en savoir plus sur les révisions, mises à niveau et informations de compatibilité 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 nonconsecutive n’est autorisé que si AKS ne prend plus en charge la révision actuelle et la prochaine révision de mise à niveau. À ce stade, la seule mise à niveau disponible est la révision prise en charge la plus faible.
L’étiquette Istio sidecar.istio.io/inject n’active pas l’injection de sidecar 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 de 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 mesh.
Le module complémentaire Istio déploie des pods de passerelle d’entrée Istio et des 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 plusieurs pods de passerelle d’entrée entre 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 changer 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