Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Provisionner un plan de contrôle Cloud Service Mesh géré sur GKE

Cloud Service Mesh est un maillage de services géré par Google que vous pouvez simplement activer. Google gère la fiabilité, les mises à niveau, le scaling et la sécurité pour vous.

Cette page vous explique comment utiliser l'API fleet pour configurer Cloud Service Mesh géré à l'aide des API Istio.

Prérequis

Pour commencer, ce guide suppose que vous avez :

Un projet Cloud
Un compte Cloud Billing
Vous avez obtenu les autorisations requises pour provisionner Cloud Service Mesh.
Activez Workload Identity sur vos clusters et pools de nœuds.

Conditions requises

Un ou plusieurs clusters avec une version compatible de GKE, dans l'une des régions compatibles.
Notez que Cloud Service Mesh géré utilise les canaux de publication GKE pour trouver un équilibre entre stabilité et vitesse de mise à niveau. Les nouvelles modifications apportées aux composants Cloud Service Mesh dans le cluster (y compris CNI, MDPC, les proxys et les CRD Istio) seront déployées en premier sur les clusters abonnés au canal rapide GKE. Elles seront ensuite promues dans le canal standard GKE, puis dans le canal stable GKE, une fois qu'elles auront démontré une stabilité suffisante.
- La bonne pratique consiste à provisionner un sous-ensemble de clusters de votre parc dans un version disponible GKE antérieur pour s'assurer qu'ils reçoivent d'abord les mises à jour des composants Cloud Service Mesh.
- Managed Cloud Service Mesh n'est pas compatible avec la modification des canaux de publication GKE.
- Si vous modifiez le version disponible GKE, Cloud Service Mesh n'empêchera pas l'opération. Cloud Service Mesh met automatiquement à jour les composants du cluster (CNI, MDPC, version du proxy injecté par défaut et CRD Istio) pour les aligner sur le version disponible GKE actuel.
Assurez-vous que votre cluster dispose d'une capacité suffisante pour les composants requis que Cloud Service Mesh géré installe dans le cluster.
- Le déploiement mdp-controller dans l'espace de noms kube-system demande cpu:50m, memory: 128Mi.
- Le DaemonSet istio-cni-node dans l'espace de noms kube-system demande cpu: 100m, memory: 100Mi sur chaque nœud.
Assurez-vous que la règle d'administration constraints/compute.disableInternetNetworkEndpointGroup est désactivée. Si la règle est activée, ServiceEntry peut ne pas fonctionner.
Assurez-vous que la machine cliente à partir de laquelle vous provisionnez Cloud Service Mesh géré dispose d'une connectivité réseau au serveur d'API.
Les clusters doivent être enregistrés sur un parc. Cette exigence est incluse dans les instructions si le cluster n'est pas déjà enregistré avant le provisionnement.
La fonctionnalité de parc Service Mesh doit être activée sur votre projet. Cette étape est incluse dans les instructions si vous ne l'avez pas encore activée.
GKE Autopilot n'est compatible qu'avec la version 1.21.3 ou ultérieure de GKE.
Cloud Service Mesh peut utiliser plusieurs clusters GKE dans un environnement à réseau unique ou utiliser plusieurs réseaux à projet unique.
- Si vous joignez des clusters qui ne font pas partie du même projet, ils doivent être enregistrés dans le même projet hôte du parc et doivent tous se trouver dans la configuration d'un VPC partagé sur le même réseau.
- Dans un environnement multicluster à projet unique, le projet de parc peut être identique au projet de cluster. Pour en savoir plus sur les parcs, consultez la présentation des parcs.
- Pour un environnement multiprojets, nous vous recommandons d'héberger le parc dans un projet distinct de ceux des clusters. Si les règles de votre organisation et la configuration existante le permettent, nous vous recommandons d'utiliser le projet de VPC partagé comme projet hôte du parc. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.

Rôles requis pour installer Cloud Service Mesh

Le tableau suivant décrit les rôles requis pour installer Managed Cloud Service Mesh.

Nom de rôle	ID de rôle	Emplacement d'attribution	Description
Administrateur de GKE Hub	roles/gkehub.admin	Projet de parc	Accès complet à GKE Hub et aux ressources associées.
Administrateur Service Usage	roles/serviceusage.serviceUsageAdmin	Projet de parc	Permet d'activer, de désactiver et d'inspecter les états de service, d'inspecter les opérations, et de consommer les quotas et la facturation pour un projet destiné à un consommateur. ^{(Remarque 1)}
Administrateur du service CA ^Bêta	roles/privateca.admin	Projet de parc	Accès complet à toutes les ressources de CA Service. ^{(Remarque 2)}

Rôles requis pour exécuter Cloud Service Mesh

Le tableau suivant décrit les rôles requis par le compte de service pour exécuter Managed Cloud Service Mesh. Si vos projets de réseau ou de cluster diffèrent du projet hôte du parc, vous devez accorder au compte de service du projet de parc l'accès à ces rôles dans les autres projets.

Nom de rôle	ID de rôle	Emplacement d'attribution	Description
Agent de service Antho Service Mesh	roles/anthosservicemesh.serviceAgent	Projet de parc
Agent de service du plan de contrôle géré du réseau maillé (ancienne version)	roles/meshcontrolplane.serviceAgent	Projet de parc	Il s'agit d'un ancien rôle qui faisait partie des anciennes installations de Cloud Service Mesh. Si votre installation dispose de ce rôle de service, vous pouvez le laisser tel quel. Les nouvelles installations n'ont pas besoin de ce rôle.

Limites

Nous vous recommandons de consulter la liste des fonctionnalités et limites de Cloud Service Mesh. Observez en particulier les points suivants :

Les pods de charge de travail exécutés avec hostNetwork: true ne sont pas acceptés.
L'API IstioOperator n'est pas compatible, car son objectif principal est de contrôler les composants au sein du cluster.

Remarque : Vous pouvez toujours activer des fonctionnalités facultatives sans utiliser l'API IstioOperator. Consultez Activer des fonctionnalités facultatives sur Cloud Service Mesh géré.

- L'utilisation de Certificate Authority Service (CA Service) nécessite de configurer Cloud Service Mesh par cluster. Elle n'est pas compatible avec la configuration par défaut du parc dans GKE Enterprise.

Pour les clusters GKE Autopilot, la configuration multi-projets n'est compatible qu'avec GKE 1.23 ou version ultérieure.
Pour les clusters GKE Autopilot, afin de s'adapter à la limite de ressources GKE Autopilot, les demandes et limites de ressources de proxy par défaut sont définies sur 500m pour le processeur et 512 Mo pour la mémoire. Vous pouvez remplacer les valeurs par défaut à l'aide de l'injection personnalisée.
Pour les clusters GKE Autopilot, des avertissements concernant les composants Cloud Service Mesh ("DaemonSet has no nodes selected") peuvent s'afficher jusqu'à ce que le NodePool des clusters soit mis à l'échelle.
Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD d'Istio sont provisionnées dans le cluster spécifié. Si des CRD Istio sont présentes dans le cluster, elles seront écrasées.
Istio CNI et Traffic Director ne sont pas compatibles avec GKE Sandbox. Par conséquent, le maillage de services géré avec l'implémentation TRAFFIC_DIRECTOR n'est pas compatible avec les clusters pour lesquels GKE Sandbox est activé.

Avant de commencer

Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Configurez gcloud (même si vous utilisez Cloud Shell).

Authentifiez-vous avec Google Cloud CLI, où FLEET_PROJECT_ID est l'ID de votre projet hôte de parc. En général, le FLEET_PROJECT_ID est créé par défaut et porte le même nom que le projet.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
Mettez à jour les composants :
```
       gcloud components update
```

Activez les API requises dans votre projet hôte de parc.

  gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID

L'activation de mesh.googleapis.com active les API suivantes :

API	Objectif	Peut-être désactivé
`meshconfig.googleapis.com`	Cloud Service Mesh utilise l'API Mesh Configuration pour relayer les données de configuration de votre maillage vers Google Cloud. En outre, l'activation de l'API Mesh Configuration vous permet d'accéder aux pages Cloud Service Mesh dans la console Google Cloud et d'utiliser l'autorité de certification Cloud Service Mesh.	Non
`meshca.googleapis.com`	Lié à l'autorité de certification Cloud Service Mesh utilisée par Cloud Service Mesh géré.	Non
`container.googleapis.com`	Obligatoire pour créer des clusters Google Kubernetes Engine (GKE).	Non
`gkehub.googleapis.com`	Obligatoire pour gérer le réseau maillé en tant que parc.	Non
`monitoring.googleapis.com`	Obligatoire pour capturer la télémétrie pour les charges de travail du réseau maillé.	Non
`stackdriver.googleapis.com`	Obligatoire pour utiliser l'interface utilisateur des services.	Non
`opsconfigmonitoring.googleapis.com`	Obligatoire pour utiliser l'interface utilisateur des services pour les clusters horsGoogle Cloud.	Non
`connectgateway.googleapis.com`	Obligatoire pour que le plan de contrôle Cloud Service Mesh géré puisse accéder aux charges de travail du réseau maillé.	Oui*
`trafficdirector.googleapis.com`	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*
`networkservices.googleapis.com`	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*
`networksecurity.googleapis.com`	Active un plan de contrôle géré hautement disponible et évolutif.	Oui*

Avertissement : Désactiver connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com et/ou networksecurity.googleapis.com entraîne le dysfonctionnement du plan de contrôle Cloud Service Mesh géré. Si le parc n'utilise Cloud Service Mesh géré sur aucun cluster, ces API peuvent être désactivées.

Configurer Cloud Service Mesh géré

Les étapes requises pour provisionner Cloud Service Mesh géré à l'aide de l'API Fleet dépendent de votre préférence : l'activer par cluster ou l'activer par défaut pour les nouveaux clusters de parc.

Configurer par cluster

Procédez comme suit pour configurer Cloud Service Mesh géré pour chaque cluster de votre maillage individuellement.

Activer la fonctionnalité de parc Cloud Service Mesh

Activez la fonctionnalité mesh sur le projet de parc. Notez que si vous envisagez d'enregistrer plusieurs clusters, l'activation de la fonctionnalité de parc Cloud Service Mesh se produit au niveau du parc. Vous n'avez donc besoin d'exécuter cette commande qu'une seule fois.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Enregistrer des clusters dans un parc

Enregistrez un cluster GKE à l'aide de l'identité de charge de travail du parc. L'indicateur --location correspond à la zone ou à la région de calcul (par exemple, us-central1-a ou us-central1) du cluster.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

Vérifiez que votre cluster est enregistré :

gcloud container fleet memberships list --project FLEET_PROJECT_ID

Exemple de résultat :

NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

Notez le MEMBERSHIP_NAME, car vous en aurez besoin lorsque vous activerez la gestion automatique.

Si le projet du réseau de votre cluster est différent de votre projet hôte de parc (par exemple, si vous utilisez un VPC partagé), vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc à accéder au projet de réseau. Vous ne devez effectuer cette opération qu'une seule fois pour le projet de réseau.

Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet réseau :
```
 gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
```
Si le projet de votre cluster est différent de votre projet hôte de parc, vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc à accéder au projet de cluster, et activer les API requises dans le projet de cluster.

Vous ne devez effectuer cette opération qu'une seule fois par projet de cluster. Si vous avez déjà configuré Cloud Service Mesh géré pour cette combinaison de projets de cluster et de parc, ces modifications ont déjà été appliquées et vous n'avez pas besoin d'exécuter les commandes suivantes.

Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet de cluster :
```
 gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent
```
Activez l'API Mesh sur le projet du cluster :
```
 gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
```

Configurer Certificate Authority Service (facultatif)

Si votre déploiement de service mesh nécessite Certificate Authority Service (CA Service), suivez Configurer Certificate Authority Service pour Cloud Service Mesh géré pour l'activer pour votre parc. Veillez à effectuer toutes les étapes avant de passer à la section suivante.

Activer la gestion automatique

Exécutez la commande suivante pour activer la gestion automatique :

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

où :

MEMBERSHIP_NAME est le nom d'appartenance indiqué après avoir vérifié que votre cluster était enregistré dans le parc.
MEMBERSHIP_LOCATION correspond à l'emplacement de votre abonnement (une région ou global).

Si vous avez récemment créé l'association à l'aide de la commande de ce guide, il s'agit de la région de votre cluster. Si vous disposez d'un cluster zonal, utilisez la région correspondant à la zone du cluster. Par exemple, si vous disposez d'un cluster zonal dans us-central1-c, utilisez la valeur us-central1.

Cette valeur peut être global si vous vous êtes inscrit avant mai 2023 ou si vous avez spécifié le lieu global lors de l'enregistrement de l'abonnement. Vous pouvez vérifier la zone géographique de votre abonnement avec gcloud container fleet memberships list --project FLEET_PROJECT_ID.

Passez à Vérifier que le plan de contrôle a été provisionné.

Configurer pour votre parc

Vous devez activer l'édition Enterprise de Google Kubernetes Engine (GKE) pour pouvoir activer Cloud Service Mesh géré comme configuration par défaut pour votre parc. Cela signifie que Cloud Service Mesh géré est activé sur chaque nouveau cluster GKE sur Google Cloud enregistré lors de la création du cluster. Pour en savoir plus sur la configuration par défaut des parcs, consultez Gérer les fonctionnalités au niveau du parc.

Notez que les valeurs par défaut au niveau du parc ne s'appliquent automatiquement qu'aux nouveaux clusters créés après l'activation des valeurs par défaut du parc. Vous devez synchroniser les clusters existants pour appliquer les nouveaux paramètres par défaut.

L'activation de Cloud Service Mesh géré comme configuration par défaut pour votre parc et l'enregistrement des clusters dans le parc lors de la création du cluster ne sont compatibles qu'avec Mesh CA. Si vous souhaitez utiliser Certificate Authority Service, nous vous recommandons de l'activer par cluster.

Pour activer les valeurs par défaut au niveau du parc pour Cloud Service Mesh géré, procédez comme suit :

Console

Dans la console Google Cloud , accédez à la page Gestionnaire de fonctionnalités.

Accéder au gestionnaire de fonctionnalités
Dans le volet Service Mesh, cliquez sur Configurer.
Examinez les paramètres dont héritent tous les nouveaux clusters que vous créez dans la console Google Cloud et que vous enregistrez dans le parc.

Remarque : Ces paramètres GKE sont des conditions préalables à l'utilisation de Cloud Service Mesh.
Pour appliquer ces paramètres, cliquez sur Configurer.
Dans la boîte de dialogue de confirmation, cliquez sur Confirmer.
Pour activer Cloud Service Mesh géré sur les clusters existants, vous devez synchroniser tous les clusters existants avec les paramètres par défaut :
1. Dans la liste Clusters du parc, sélectionnez les clusters que vous souhaitez synchroniser.
2. Cliquez sur Synchroniser avec les paramètres du parc, puis sur Confirmer dans la boîte de dialogue de confirmation qui s'affiche. Cette opération peut durer quelques minutes.

gcloud

Pour configurer les valeurs par défaut au niveau du parc à l'aide de Google Cloud CLI, vous devez définir les paramètres suivants :

Paramètres au niveau du parc

Créez un fichier mesh.yaml contenant uniquement la ligne management: automatic :
```
echo "management: automatic" > mesh.yaml
```

Activez Cloud Service Mesh pour votre parc :

gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

Si l'erreur suivante s'affiche, vous devez activer GKE Enterprise.

ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

Paramètres au niveau du réseau
- Si le projet de votre réseau diffère de votre projet hôte de parc (par exemple, si vous utilisez un VPC partagé), vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc à accéder au projet de réseau. Vous ne devez effectuer cette opération qu'une seule fois pour le projet de réseau.
  
  Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet réseau :
```
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
Paramètres au niveau du cluster
- Lorsque vous êtes prêt à créer des clusters à utiliser avec Cloud Service Mesh, créez-les et enregistrez-les en une seule étape avec Google Cloud CLI pour utiliser la configuration par défaut. Exemple :
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  Vous pouvez obtenir le numéro de projet de votre parc en exécutant la commande suivante :
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  L'indicateur --location correspond à la zone ou à la région de calcul (par exemple, us-central1-a ou us-central1) du cluster.
- Si le projet de votre cluster est différent de votre projet hôte de parc, vous devez autoriser les comptes de service Cloud Service Mesh dans le projet de parc à accéder au projet de cluster et activer les API requises dans le projet de cluster. Vous ne devez effectuer cette opération qu'une seule fois par projet de cluster.
  
  Accordez aux comptes de service du projet de parc l'autorisation d'accéder au projet de cluster :
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
  Activez l'API Mesh sur le projet du cluster :
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  Remplacez CLUSTER_PROJECT_ID par l'identifiant unique de votre projet de cluster. Si vous avez créé votre cluster dans le même projet que votre parc, le champ CLUSTER_PROJECT_ID est identique à FLEET_PROJECT_ID.

Passez à Vérifier que le plan de contrôle a été provisionné.

Compatibilité avec Terraform

Cloud Service Mesh est compatible avec le provisionnement via Terraform grâce au module d'appartenance aux fonctionnalités GKE Hub.

Pour obtenir des instructions détaillées, consultez le tutoriel sur le provisionnement d'un maillage de services géré.

Vérifier que le plan de contrôle a été provisionné

Après quelques minutes, vérifiez que l'état du plan de contrôle est ACTIVE :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Le résultat est semblable à :

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Notez le plan de contrôle affiché dans le champ implementation, ISTIOD ou TRAFFIC_DIRECTOR. Consultez Fonctionnalités compatibles avec Cloud Service Mesh pour connaître les différences entre les plans de contrôle et les configurations compatibles, et pour savoir comment sélectionner l'implémentation du plan de contrôle.

Configurer `kubectl` pour qu'il pointe vers le cluster

Les sections suivantes impliquent l'exécution de commandes kubectl sur chacun de vos clusters. Avant de passer aux sections suivantes, exécutez la commande suivante pour chacun de vos clusters afin de configurer kubectl pour qu'il pointe vers le cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Notez qu'une passerelle d'entrée n'est pas déployée automatiquement avec le plan de contrôle. Dissocier le déploiement de la passerelle d'entrée et du plan de contrôle vous permet de gérer vos passerelles dans un environnement de production. Si vous souhaitez utiliser une passerelle d'entrée ou de sortie Istio, consultez Déployer des passerelles. Si vous souhaitez utiliser l'API Kubernetes Gateway, consultez Préparer Gateway pour Mesh. Pour activer d'autres fonctionnalités facultatives, consultez Activer des fonctionnalités facultatives sur Cloud Service Mesh.

Plan de données géré

Si vous utilisez Cloud Service Mesh géré, Google gère entièrement les mises à niveau de vos proxys.

Lorsque la fonctionnalité de plan de données géré est activée, les proxys side-car et les passerelles injectées sont activement et automatiquement mis à jour conjointement avec le plan de contrôle géré en redémarrant les charges de travail pour réinjecter les nouvelles versions du proxy. Elle commence une fois le plan de contrôle mis à niveau et se termine normalement dans les deux semaines suivant son lancement.

Notez que le plan de données géré repose sur le canal de publication GKE. Si vous modifiez le version disponible GKE alors que le plan de données géré est activé, Cloud Service Mesh géré met à jour les proxys de toutes les charges de travail existantes comme lors d'un déploiement de plan de données géré.

Si cette option est désactivée, la gestion du proxy est effectuée de manière passive. Elle est déterminée par le cycle de vie naturel des pods du cluster et doit être déclenchée manuellement par l'utilisateur pour contrôler le taux de mise à jour.

Le plan de données géré met à niveau les proxys en expulsant les pods qui exécutent des versions antérieures du proxy. Les évictions sont effectuées progressivement, en respectant le budget d'interruption des pods et en contrôlant le rythme des modifications.

Lorsque de nouvelles versions du plan de données Cloud Service Mesh sont déployées

Plan de données géré	Événements qui déclenchent un nouveau déploiement du plan de données Cloud Service Mesh
Plan de données géré	Mises à jour actives de Cloud Service Mesh Activement, lorsque de nouvelles versions sont disponibles¹	Création de pods Lorsque vous ou l'autoscaling horizontal des pods déployez de nouvelles charges de travail	Intervalles de maintenance GKE Remplacement des nœuds pendant un intervalle de maintenance GKE
Activé
Désactivé

¹ Les mises à jour actives de Cloud Service Mesh remplacent automatiquement Pods dans les charges de travail, à l'exception de StatefulSets, Jobs, DaemonSets et Pods injectés manuellement. Les mises à jour actives de Cloud Service Mesh respectent les budgets de perturbation Pod.

Les mises à jour actives de faible priorité coïncident avec les périodes de maintenance de GKE.
Les mises à jour actives de haute priorité peuvent avoir lieu dès que Cloud Service Mesh les met à la disposition de votre cluster, sans tenir compte des intervalles de maintenance GKE. Les mises à jour actives de haute priorité sont généralement associées à au moins une CVE.

Activez le plan de données géré si vous ne souhaitez pas gérer vous-même le cycle de vie du plan de données Cloud Service Mesh et si vos charges de travail peuvent tolérer le remplacement des pods à tout moment.

Désactivez le plan de données géré si vous souhaitez contrôler entièrement le moment où toutes les mises à jour du plan de données Cloud Service Mesh sont effectuées.

Limites

Le plan de données géré ne gère pas les éléments suivants :

Pods non injectés
Pods injectés manuellement
Jobs
StatefulSets
DaemonSets

Désactiver le plan de données géré (facultatif)

Si vous provisionnez un service Cloud Service Mesh géré sur un nouveau cluster, vous pouvez désactiver complètement le plan de données géré, ou pour des espaces de noms ou des pods individuels. Le plan de données géré restera désactivé pour les clusters existants où il était désactivé par défaut ou manuellement.

Pour désactiver le plan de données géré au niveau du cluster et revenir à la gestion des proxys side-car vous-même, recherchez chaque révision du plan de contrôle, puis modifiez chaque annotation.

Recherchez toutes les révisions du plan de contrôle :
```
kubectl get controlplanerevisions -n istio-system
```
Modifiez l'annotation :
```
kubectl annotate --overwrite controlplanerevision CONTROL_PLANE_REVISION_NAME -n istio-system mesh.cloud.google.com/proxy='{"managed":"false"}'
```
Répétez cette étape pour chaque révision du plan de contrôle.

Remplacez CONTROL_PLANE_REVISION_NAME par le résultat de la commande précédente.

Pour désactiver le plan de données géré pour un espace de noms :

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Pour désactiver le plan de données géré pour un pod :

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Activer les intervalles de maintenance pour le plan de données géré

Si vous avez configuré un intervalle de maintenance GKE, les mises à niveau actives commenceront au début du prochain intervalle de maintenance disponible et se poursuivront sans interruption jusqu'à ce que tous les pods gérés aient été mis à jour (généralement 12 heures). L'intervalle de maintenance n'est pas respecté pour les déploiements liés aux CVE.

Cloud Service Mesh utilise la période de maintenance GKE pour s'aligner sur GKE.

Activer les notifications de maintenance pour le plan de données géré

Vous pouvez demander à être averti de la maintenance à venir du plan de données géré jusqu'à une semaine avant la maintenance. Par défaut, les notifications de maintenance ne sont pas envoyées. Vous devez également configurer un intervalle de maintenance GKE avant de pouvoir recevoir des notifications. Si cette option est activée, des notifications sont envoyées au moins deux jours avant l'opération de mise à niveau.

Pour activer les notifications de maintenance du plan de données géré :

Accédez à la page Communication.

Accédez à la page Communication.
Dans la ligne Mise à niveau de Cloud Service Mesh, sous la colonne Adresse e-mail, cochez la case d'option pour activer les notifications de maintenance.

Chaque utilisateur souhaitant recevoir des notifications doit activer lui-même l'option. Si vous souhaitez définir un filtre de messagerie pour ces notifications, la ligne d'objet est la suivante :

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

L'exemple suivant montre une notification de maintenance typique du plan de données géré :

Objet : Mise à niveau à venir de votre cluster Cloud Service Mesh "<location/cluster-name>"

Bonjour,

La mise à niveau des composants Cloud Service Mesh de votre cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) est prévue le ${scheduled_date_human_readable} à ${scheduled_time_human_readable}.

Vous pouvez consulter les notes de version (https://cloud.google.com/service-mesh/docs/release-notes) pour en savoir plus sur la nouvelle mise à jour.

En cas d'annulation de cette opération, nous vous préviendrons par e-mail.

Cordialement,

L'équipe Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043, États-Unis Cette annonce vous a été envoyée afin de vous informer de modifications importantes apportées à Google Cloud Platform ou à votre compte. Vous pouvez désactiver les notifications concernant les intervalles de maintenance en modifiant vos préférences utilisateur : https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Configurer la découverte des points de terminaison (uniquement pour les installations multiclusters)

Si votre maillage ne comporte qu'un seul cluster, ignorez ces étapes multicluster et passez à Déployer des applications ou Migrer des applications.

Avant de continuer, assurez-vous que Cloud Service Mesh est configuré sur chaque cluster.

L'activation de Cloud Service Mesh avec l'API Fleet permet la découverte des points de terminaison pour ce cluster. Vous devez toutefois ouvrir les ports de pare-feu. Pour désactiver la découverte de points de terminaison pour un ou plusieurs clusters, consultez les instructions de la section Activer la découverte de points de terminaison entre les clusters avec l'API déclarative.

Pour obtenir un exemple d'application comportant deux clusters, consultez la page Exemple de service HelloWorld.

Compatibilité avec les groupes de points de terminaison du réseau

Cloud Service Mesh avec l'implémentation du plan de contrôle TRAFFIC_DIRECTOR nécessite des groupes de points de terminaison du réseau (NEG) pour représenter les points de terminaison de service dans GKE.

Création automatique de NEG

Lorsque vous activez Cloud Service Mesh avec le plan de contrôle Traffic Director, le maillage annote automatiquement vos services Kubernetes avec l'annotation cloud.google.com/neg. Cela permet au contrôleur NEG GKE de créer des NEG autonomes pour les points de terminaison de votre service.

Ces NEG sont essentiels pour que le plan de contrôle puisse découvrir les points de terminaison de votre service et programmer vos clients pour qu'ils les découvrent.

À quoi vous attendre

Annotations automatiques : tous les services (y compris les types ClusterIP, NodePort et LoadBalancer) d'un espace de noms compatible avec le maillage sont automatiquement annotés avec l'annotation cloud.google.com/neg.
État du NEG : une annotation cloud.google.com/neg-status est également ajoutée à vos services, fournissant des informations sur les NEG créés.
Comportement requis : cette automatisation est essentielle au fonctionnement des services dans le plan de contrôle moderne et ne peut pas être désactivée pour les services de maillage.

Interaction avec les outils CI/CD

Si vous utilisez des outils CI/CD pour gérer vos services, ils peuvent détecter les annotations automatiques comme une dérive de configuration et tenter de les supprimer.

Pour éviter tout problème, configurez vos outils CI/CD de façon à ignorer les annotations cloud.google.com/neg et cloud.google.com/neg-status. Pour en savoir plus et obtenir des exemples, consultez Dépanner les NEG avec les outils CI/CD.

Déployer des applications

Si plusieurs clusters du parc utilisent Cloud Service Mesh géré, assurez-vous que la découverte des points de terminaison ou les ports de pare-feu sont configurés comme prévu avant de poursuivre et de déployer les applications.

Activez l'espace de noms pour l'injection : Les étapes dépendent de votre mise en œuvre du plan de contrôle.

Plan de contrôle géré (TD)

Appliquez les étiquettes d'injection par défaut à l'espace de noms.

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Plan de contrôle géré (Istiod)

Recommandation : Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Si vous utilisez déjà le plan de contrôle Istiod géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée. Suivez les instructions suivantes :

Exécutez la commande suivante pour localiser les canaux de publication disponibles :
```
kubectl -n istio-system get controlplanerevision
```
Le résultat ressemble à ce qui suit :
```
NAME                AGE
asm-managed-rapid   6d7h
```
REMARQUE : Si deux révisions du plan de contrôle apparaissent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans un même cluster.

Dans le résultat, la valeur de la colonne NAME est l'étiquette de révision qui correspond au canal de publication disponible pour la version de Cloud Service Mesh.

Appliquez l'étiquette de révision à l'espace de noms :

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Vérifiez que le libellé de l'espace de noms est correctement appliqué à l'aide de la commande suivante.

  kubectl get namespace -L istio-injection

Exemple de résultat :

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

À ce stade, vous avez configuré avec succès Cloud Service Mesh géré. Si vous avez des charges de travail existantes dans des espaces de noms libellés, redémarrez-les pour que des proxys y soient injectés.

Si vous déployez une application dans une configuration multi-cluster, répliquez la configuration de Kubernetes et du plan de contrôle dans tous les clusters, sauf si vous envisagez de limiter cette configuration à un sous-ensemble de clusters. La configuration appliquée à un cluster particulier est la source de vérité de ce cluster.

Personnaliser l'injection (facultatif)

Vous pouvez remplacer les valeurs par défaut et personnaliser les paramètres d'injection, mais cela peut entraîner des erreurs de configuration imprévues et des problèmes avec les conteneurs side-car. Avant de personnaliser l'injection, lisez les informations qui suivent l'exemple pour obtenir des notes sur des paramètres spécifiques et des recommandations.

Une configuration par pod est disponible pour remplacer ces options sur des pods individuels. Pour ce faire, ajoutez un conteneur istio-proxy à votre pod. L'injection de sidecar traitera toute configuration définie ici comme un remplacement du modèle d'injection par défaut.

Par exemple, la configuration suivante personnalise divers paramètres, y compris en réduisant les demandes de processeur, en ajoutant un montage de volume et en ajoutant un hook preStop :

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

En général, n'importe quel champ d'un pod peut être défini. Toutefois, vous devez faire attention à certains champs :

Kubernetes exige que le champ image soit défini avant l'exécution de l'injection. Bien que vous puissiez définir une image spécifique pour remplacer celle par défaut, nous vous recommandons de définir image sur auto. L'injecteur side-car sélectionnera alors automatiquement l'image à utiliser.
Certains champs de containers dépendent de paramètres associés. Par exemple, la valeur doit être inférieure ou égale à la limite de processeur. Si les deux champs ne sont pas correctement configurés, le pod risque de ne pas démarrer.
Kubernetes vous permet de définir à la fois requests et limits pour les ressources de votre spec de pod. GKE Autopilot ne prend en compte que requests. Pour en savoir plus, consultez Définir des limites de ressources dans Autopilot.

De plus, certains champs sont configurables par des annotations sur le pod, bien qu'il soit recommandé d'utiliser l'approche ci-dessus pour personnaliser les paramètres. Faites particulièrement attention aux annotations suivantes :

Pour GKE Standard, si sidecar.istio.io/proxyCPU est défini, assurez-vous de définir explicitement sidecar.istio.io/proxyCPULimit. Sinon, la limite de processeur du side-car sera définie sur "illimité".
Pour GKE Standard, si sidecar.istio.io/proxyMemory est défini, veillez à définir explicitement sidecar.istio.io/proxyMemoryLimit. Sinon, la limite de mémoire du side-car sera définie sur "illimité".
Pour GKE Autopilot, la configuration des requests et limits de ressources à l'aide d'annotations peut entraîner un surprovisionnement des ressources. Utilisez l'approche du modèle d'image pour éviter cela. Consultez Exemples de modification de ressources dans Autopilot.

Par exemple, consultez l'annotation des ressources ci-dessous :

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Migrer des applications vers Cloud Service Mesh géré

Pour migrer des applications depuis Cloud Service Mesh intégré au cluster vers Cloud Service Mesh géré, procédez comme suit :

Remplacez le libellé de l'espace de noms actuel. Les étapes dépendent de votre mise en œuvre du plan de contrôle.

Plan de contrôle géré (TD)

Appliquez les étiquettes d'injection par défaut à l'espace de noms.

kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Plan de contrôle géré (Istiod)

Recommandation : Exécutez la commande suivante pour appliquer le libellé d'injection par défaut à l'espace de noms :

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Exécutez la commande suivante pour localiser les canaux de publication disponibles :
```
kubectl -n istio-system get controlplanerevision
```
Le résultat ressemble à ce qui suit :
```
NAME                AGE
asm-managed-rapid   6d7h
```
REMARQUE : Si deux révisions du plan de contrôle apparaissent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans un même cluster.

Dans le résultat, la valeur de la colonne NAME est l'étiquette de révision qui correspond au canal de publication disponible pour la version de Cloud Service Mesh.

Appliquez l'étiquette de révision à l'espace de noms :

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Effectuez une mise à niveau progressive des déploiements dans l'espace de noms :
```
kubectl rollout restart deployment -n NAMESPACE
```
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes précédentes pour chaque espace de noms.
Si vous avez déployé l'application dans une configuration multi.cluster, répliquez la configuration de Kubernetes et d'Istio dans tous les clusters, sauf si vous souhaitez limiter cette configuration à un sous-ensemble de clusters uniquement. La configuration appliquée à un cluster particulier est la source de vérité de ce cluster.

Si vous êtes sûr que votre application fonctionne comme prévu, vous pouvez supprimer la ressource istiod dans le cluster après avoir remplacé tous les espaces de noms par le plan de contrôle géré, ou les conserver en tant que sauvegarde. istiod effectue un scaling automatique afin d'utiliser moins de ressources. Pour le supprimer, passez à l'étape Supprimer l'ancien plan de contrôle.

Si vous rencontrez des problèmes, vous pouvez les identifier et les résoudre en utilisant les informations figurant dans la section Résoudre les problèmes liés au plan de contrôle géré et, si nécessaire, effectuer un rollback vers la version précédente.

Supprimer l'ancien plan de contrôle

Après avoir installé et vérifié que tous les espaces de noms utilisent le plan de contrôle géré par Google, vous pouvez supprimer l'ancien plan de contrôle.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Si vous avez utilisé istioctl kube-inject au lieu de l'injection automatique ou si vous avez installé des passerelles supplémentaires, vérifiez les métriques du plan de contrôle et vérifiez que le nombre de points de terminaison connectés est de zéro.

Rollback

Pour effectuer un rollback vers la version précédente du plan de contrôle, procédez comme suit :

Mettez à jour les charges de travail à injecter avec la version précédente du plan de contrôle. Dans la commande suivante, la valeur de révision asm-191-1 n'est utilisée qu'à titre d'exemple. Remplacez l'exemple de valeur par le libellé de révision de votre précédent plan de contrôle.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :
```
kubectl rollout restart deployment -n NAMESPACE
```

Le plan de contrôle géré effectue un scaling automatique à zéro instance et n'utilise aucune ressource lorsqu'il n'est pas utilisé. Les webhooks et le provisionnement en mutation restent inchangés et n'affectent pas le comportement du cluster.

La passerelle est maintenant définie sur la révision asm-managed. Pour effectuer un rollback, exécutez à nouveau la commande d'installation de Cloud Service Mesh, qui redéploiera la passerelle en pointant vers votre plan de contrôle au sein du cluster :

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Attendez-vous à ce résultat :

deployment.apps/istio-ingressgateway rolled back

Désinstaller Cloud Service Mesh

Le plan de contrôle géré effectue un scaling automatique à zéro instance si aucun espace de noms ne l'utilise. Pour connaître la procédure détaillée, consultez Désinstaller Cloud Service Mesh.

Provisionner un plan de contrôle Cloud Service Mesh géré sur GKE

Prérequis

Conditions requises

Rôles requis pour installer Cloud Service Mesh

Rôles requis pour exécuter Cloud Service Mesh

Limites

Avant de commencer

L'activation de mesh.googleapis.com active les API suivantes :

Configurer Cloud Service Mesh géré

Configurer par cluster

Activer la fonctionnalité de parc Cloud Service Mesh

Enregistrer des clusters dans un parc

Configurer Certificate Authority Service (facultatif)

Activer la gestion automatique

Configurer pour votre parc

Console

gcloud

Compatibilité avec Terraform

Vérifier que le plan de contrôle a été provisionné

Configurer kubectl pour qu'il pointe vers le cluster

Plan de données géré

Lorsque de nouvelles versions du plan de données Cloud Service Mesh sont déployées

Limites

Désactiver le plan de données géré (facultatif)

Activer les intervalles de maintenance pour le plan de données géré

Activer les notifications de maintenance pour le plan de données géré

Configurer la découverte des points de terminaison (uniquement pour les installations multiclusters)

Compatibilité avec les groupes de points de terminaison du réseau

Création automatique de NEG

À quoi vous attendre

Interaction avec les outils CI/CD

Déployer des applications

Plan de contrôle géré (TD)

Plan de contrôle géré (Istiod)

Personnaliser l'injection (facultatif)

Migrer des applications vers Cloud Service Mesh géré

Plan de contrôle géré (TD)

Plan de contrôle géré (Istiod)

Supprimer l'ancien plan de contrôle

Rollback

Désinstaller Cloud Service Mesh

Configurer `kubectl` pour qu'il pointe vers le cluster