Planifier une mise à niveau

Cette page fournit des informations pour vous aider à planifier une mise à niveau d'Anthos Service Mesh. Nous vous recommandons également de consulter les notes de mise à niveau d'Istio.

À propos des mises à niveau Canary

Nous vous recommandons de mettre à niveau Anthos Service Mesh en exécutant d'abord un déploiement Canary du nouveau plan de contrôle. Avec une mise à niveau Canary, asmcli installe une nouvelle révision du plan de contrôle à côté de l'ancien plan de contrôle. L'ancien et le nouveau plans de contrôle sont associés à un libellé revision qui sert d'identifiant pour les plans de contrôle.

Pour migrer les charges de travail vers le nouveau plan de contrôle :

1. Définissez le libellé revision du nouveau plan de contrôle sur l'un de vos espaces de noms.

2. Effectuez un redémarrage progressif. Le redémarrage ré-injecte les proxys side-car dans les pods pour que les proxys utilisent le nouveau plan de contrôle.

3. Surveillez l'effet de la mise à niveau sur les charges de travail. Si vous devez tester votre application, répétez les étapes précédentes.

4. Après avoir testé votre application, vous pouvez migrer tout le trafic vers le nouveau plan de contrôle ou revenir à l'ancien plan de contrôle.

Une mise à niveau Canary est beaucoup plus sûre qu'une mise à niveau sur place dans laquelle le nouveau plan de contrôle remplace l'ancien. Pour connaître la procédure détaillée, consultez la section Passer au nouveau plan de contrôle.

Personnaliser le plan de contrôle

Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lors de la mise à niveau d'Anthos Service Mesh. Si vous avez personnalisé l'installation en ajoutant l'option --set values à istioctl install, vous devez ajouter ces paramètres à un fichier YAML IstioOperator, appelé fichier de superposition. Pour spécifier le fichier superposé, vous devez utiliser l'option --custom_overlay avec le nom de fichier lorsque vous exécutez asmcli.

Attention : L'installation aboutit même si vous oubliez le fichier superposé. Cependant, votre maillage de services a une configuration différente de celle que vous souhaitiez, car les valeurs par défaut des options omises sont rétablies lors du redéploiement du plan de contrôle.

Le package anthos-service-mesh dans GitHub contient de nombreux fichiers de superposition. Ces fichiers contiennent des personnalisations courantes de la configuration par défaut. Vous pouvez utiliser ces fichiers tels quels ou vous pouvez apporter des modifications supplémentaires si nécessaire. Certains de ces fichiers sont requis pour activer les fonctionnalités facultatives d'Anthos Service Mesh. Le package anthos-service-mesh est téléchargé lorsque vous exécutez asmcli pour valider votre projet et votre cluster.

Lorsque vous installez Anthos Service Mesh à l'aide de asmcli install, vous pouvez spécifier un ou plusieurs fichiers de superposition avec --option ou --custom_overlay. Si vous n'avez pas besoin de modifier les fichiers du dépôt anthos-service-mesh, vous pouvez utiliser --option. Le script récupère alors le fichier depuis GitHub à votre place. Sinon, vous pouvez apporter des modifications au fichier de superposition, puis utiliser l'option --custom_overlay pour le transmettre au script asmcli.

Choisir une autorité de certification

Remarque concernant la plate-forme:Mesh CA n'est pas compatible avec GKE sur AWS, Amazon EKS ou Microsoft AKS. Si vous exécutez asmcli install et spécifiez --ca mesh_ca sur ces plates-formes, l'installation échoue.

Si votre installation Anthos Service Mesh actuelle utilise l'autorité de certification Anthos Service Mesh (Mesh CA) comme autorité de certification pour l'émission de certificats TLS mutuels (mTLS), nous nous vous recommandons de continuer à utiliser Mesh CA pour les raisons suivantes :

• Mesh CA est un service hautement fiable et évolutif, optimisé pour les charges de travail à scaling dynamique sur Google Cloud.
• Avec Mesh CA, Google gère la sécurité et la disponibilité du backend CA.
• Mesh CA vous permet de dépendre d'une seule racine de confiance dans les clusters.

Si votre installation actuelle d'Anthos Service Mesh utilise l'autorité de certification Istio (anciennement appelée "Citadel"), vous pouvez passer à Mesh CA lors de la mise à niveau, mais vous devrez planifier un temps d'arrêt. Pendant la mise à niveau, le trafic mTLS est interrompu jusqu'à ce que toutes les charges de travail passent au nouveau plan de contrôle avec la nouvelle autorité de certification "Mesh CA".

Remarque concernant la plate-forme:CA Service n'est compatible qu'avec les plates-formes suivantes: clusters GKE sur Google Cloud, GKE sur VMware et GDCV pour Bare Metal. Si vous exécutez asmcli install et spécifiez --ca gcp_cas sur d'autres plates-formes, l'installation semble fonctionner, mais vos charges de travail ne pourront pas démarrer

Les certificats émis par l'autorité de certification d'Anthos Service Mesh (Mesh CA) incluent les données suivantes sur les services de votre application :

• L'ID de projet Google Cloud
• L'espace de noms GKE
• Le nom du compte de service GKE

Important : Les certificats émis par Mesh CA ne doivent être utilisés que pour permettre une communication sécurisée de service à service au sein de votre maillage de services, et ne doivent pas être utilisés à d'autres fins. Ces certificats sont envoyés chaque fois que les services tentent de communiquer entre eux via le protocole TLS mutuel. Assurez-vous de ne pas exposer par inadvertance des informations confidentielles lors de l'utilisation de ces certificats pendant une communication en dehors de votre maillage de services.

Identifier votre autorité de certification

Lorsque vous exécutez asmcli install pour effectuer la mise à niveau, vous spécifiez l'autorité de certification que asmcli doit activer sur le nouveau plan de contrôle.

La modification des autorités de certification entraîne des temps d'arrêt lorsque vos charges de travail de déploiement sont déployées sur le nouveau plan de contrôle. Si vous ne pouvez pas planifier de temps d'arrêt, assurez-vous de spécifier pour le nouveau plan de contrôle la même autorité de certification que celle utilisée par l'ancien plan de contrôle. Si vous ne savez pas quelle autorité de certification est activée sur votre maillage, exécutez les commandes suivantes :

1. Obtenez une liste des pods à partir de l'un de vos espaces de noms :

   kubectl get pods -n NAMESPACE
   

2. Remplacez POD_NAME par le nom de l'un de vos pods dans la commande suivante :

   kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
   

   Si Mesh CA est activé sur l'espace de noms, la sortie suivante s'affiche :

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

Préparer la configuration de la passerelle

Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

Par défaut, asmcli n'installe pas la istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Pour en savoir plus, consultez la section Installer et mettre à niveau des passerelles. Si vous avez besoin d'installer l'option istio-ingressgateway par défaut avec le plan de contrôle au sein du cluster, incluez l'argument --option legacy-default-ingressgateway.

Étape suivante

• Installer les outils dépendants et valider les clusters