Planifier une mise à niveau

Cette page fournit des informations pour vous aider à planifier une mise à niveau de Cloud 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 Cloud 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 lorsque vous mettez à niveau Cloud 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 sur 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 de Cloud 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 Cloud Service Mesh à l'aide de asmcli install, vous 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

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

• L'autorité de certification Cloud Service Mesh est un service hautement fiable et évolutif, optimisé pour les charges de travail évolutives.
• Avec l'autorité de certification Cloud Service Mesh, Google gère la sécurité et la disponibilité du backend de l'autorité de certification.
• L'autorité de certification Cloud Service Mesh vous permet de compter sur une seule racine de confiance clusters.

Si votre installation actuelle de Cloud Service Mesh utilise Istio CA (anciennement appelée "Citadel"), vous pouvez passer à l'autorité de certification Cloud Service Mesh lorsque vous effectuez une mise à niveau, mais vous devez 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 l'autorité de certification Cloud Service Mesh.

Remarque sur la plate-forme:Le service CA n'est compatible qu'avec le les plates-formes suivantes: clusters GKE sur Google Cloud, Google Distributed Cloud et Distributed Cloud. 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 Cloud Service Mesh 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 l'autorité de certification Cloud Service Mesh est activée 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

Cloud Service Mesh vous permet de déployer et de gérer des passerelles dans le cadre le 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é.

asmcli n'installe pas istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Pour plus plus d'informations, consultez Installer et mettre à niveau des passerelles.

Mettre à niveau votre plate-forme (facultatif)

Nous vous recommandons de mettre à niveau Cloud Service Mesh vers la dernière version compatible compatible avec votre plate-forme actuelle. Mettez ensuite à niveau votre environnement afin qu'il se situe dans la plage des plates-formes et versions Kubernetes compatibles. Enfin, si nécessaire, passez à la dernière version compatible de Cloud Service Mesh.

Étape suivante

• Installer les outils dépendants et valider les clusters