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

Cette page a été traduite par l'API Cloud Translation.

Provisionner le maillage de services Cloud géré avec asmcli

Présentation

Le maillage de services cloud géré avec asmcli est un plan de contrôle géré. un plan de données géré qu'il suffit de configurer. Google en gère la fiabilité, les mises à niveau, le scaling et la sécurité de manière rétrocompatible. Ce Ce guide explique comment configurer ou migrer des applications vers le service géré Cloud Service Mesh. dans une configuration unique ou multicluster avec asmcli.

Pour en savoir plus sur les fonctionnalités et les limites du service géré Cloud Service Mesh, consultez la page Fonctionnalités compatibles avec le service Cloud Service Mesh géré.

Prérequis

Pour commencer, ce guide suppose que vous avez :

Un projet Cloud
Un compte Cloud Billing
obtenu les autorisations requises ; pour provisionner Cloud Service Mesh
L'outil d'installation asmcli, kpt et d'autres outils spécifiés dans Installer les outils requis

Pour un provisionnement plus rapide, vos clusters doivent disposer Workload Identity est activé. Si Workload Identity n'est pas activé, le provisionnement l'activer automatiquement.

Conditions requises

Un ou plusieurs clusters avec une version compatible de GKE, dans l'une des régions compatibles.
Assurez-vous que votre cluster dispose d'une capacité suffisante pour les composants requis qui les installations gérées Cloud Service Mesh dans le cluster.
- Le déploiement mdp-controller dans l'espace de noms kube-system demande un processeur: 50 m, mémoire: 128 Mi.
- Le daemonset istio-cni-node dans l'espace de noms kube-system demande le CPU: 100 m, mémoire: 100 Mi sur chaque nœud.
Assurez-vous que la machine cliente à partir de laquelle vous provisionnez Cloud Service Mesh géré la connectivité réseau au serveur d'API.
Les clusters doivent être enregistrés sur un parc. Cette étape peut être effectuée séparément avant la fourniture ou dans le cadre en transmettant les options --enable-registration et --fleet-id.
La fonctionnalité de parc de maillages de services doit être activée pour votre projet. Vous pourriez activez-les dans le cadre du provisionnement en transmettant --enable-gcp-components, ou en exécutant la commande suivante:
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
où FLEET_PROJECT_ID est l'ID du projet hôte du parc.
GKE Autopilot n'est compatible qu'avec la version de GKE 1.21.3+.
Cloud Service Mesh peut utiliser plusieurs clusters GKE dans un environnement à réseau unique à un seul projet ou réseau à un seul réseau multiprojet environnement.
- 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.
- Pour un environnement multicluster à projet unique, le projet de parc peut être identique au projet de cluster. Pour en savoir plus sur les parcs, consultez Présentation des parcs
- Pour un environnement multiprojet, nous vous recommandons d'héberger le parc dans un environnement un projet distinct des projets de cluster. Si votre organisation et la configuration existante le permettent, nous vous recommandons d'utiliser le projet VPC partagé en tant que projet hôte du parc. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.
- Si votre organisation utilise VPC Service Controls et que vous provisionnez Cloud Service Mesh sur des clusters GKE avec une version supérieure ou égale à 1.22.1-gke.10, vous devrez peut-être prendre des mesures étapes de configuration suivantes:
  - Si vous provisionnez Cloud Service Mesh standard ou stable version disponible, vous devez utiliser l'option --use-vpcsc supplémentaire lorsque vous appliquez la plan de contrôle géré et suivez les Guide VPC Service Controls (preview). Sinon, les contrôles de sécurité échoueront.
  - Si vous provisionnez Cloud Service Mesh rapidement version disponible, vous n'avez pas besoin d'utiliser l'option --use-vpcsc supplémentaire lorsque en appliquant le plan de contrôle géré, mais vous devez suivre Guide VPC Service Controls (DG).

Rôles requis pour installer Cloud Service Mesh

Le tableau suivant décrit les rôles requis pour installer l'infrastructure gérée 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 du service CA. ^{(Remarque 2)}

Limites

Nous vous recommandons de consulter la liste Fonctionnalités et limites prises en charge par Cloud Service Mesh Observez en particulier les points suivants :

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 la page Activer les fonctionnalités facultatives sur le service géré Cloud Service Mesh. Vous pouvez également utiliser l'outil de migration inclus dans asmcli pour convertir d'autres fonctionnalités facultatives de IstioOperator pour qu'elles soient compatibles avec plan de contrôle géré. Pour en savoir plus, consultez la page Migrer depuis IstioOperator.
Pour les clusters GKE Autopilot, la configuration inter-projets n'est compatibles avec GKE 1.23 ou version ultérieure.
Pour les clusters GKE Autopilot, afin de vous adapter Limite de ressources GKE Autopilot. les demandes et limites de ressources de proxy par défaut sont définies sur 500 millicœurs de processeur et 512 Mo mémoire. Vous pouvez remplacer les valeurs par défaut injection personnalisée.
Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD Istio sont provisionnées dans le cluster spécifié. S'il existe des CRD Istio dans le fichier dans le cluster, elles seront écrasées
CNI Istio et Cloud Service Mesh ne sont pas compatibles avec GKE Sandbox. Par conséquent, le service géré Cloud Service Mesh avec l'implémentation TRAFFIC_DIRECTOR ne permet pas n'est pas compatible avec les clusters sur lesquels GKE Sandbox est activé.
L'outil asmcli doit avoir accès au point de terminaison Google Kubernetes Engine (GKE). Vous pouvez configurer l'accès via un "saut" d'un serveur, tel qu'un Compute Engine au sein du cloud privé virtuel (VPC), ce qui donne y accéder.

Avant de commencer

Configurer gcloud

Suivez la procédure ci-dessous même si vous utilisez Cloud Shell.

Authentifiez-vous avec Google Cloud CLI :
```
gcloud auth login --project PROJECT_ID
```
où PROJECT_ID est l'identifiant unique de votre projet de cluster. Exécutez la commande suivante pour obtenir votre PROJECT_ID:
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
Mettez à jour les composants :
```
gcloud components update
```
Configurez kubectl pour qu'il pointe vers le cluster.

Remarque :Utilisez --region au lieu de --zone si le cluster est un cluster régional cluster.
```
gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID
```

Télécharger l'outil d'installation

Téléchargez la dernière version de l'outil dans le répertoire de travail actuel :
```
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
```
Rendez l'outil exécutable :
```
chmod +x asmcli
```

Configurer chaque cluster

Procédez comme suit pour configurer Cloud Service Mesh géré pour chaque cluster dans votre réseau maillé.

Appliquer le plan de contrôle géré

Avant d'appliquer le plan de contrôle géré, vous devez sélectionnez une version disponible. Votre canal Cloud Service Mesh est déterminé par le canal de votre cluster GKE le temps de provisionnement géré de Cloud Service Mesh. Notez que plusieurs chaînes dans le même cluster en même temps.

Exécutez l'outil d'installation pour chaque cluster qui utilisera Cloud Service Mesh géré. Nous vous recommandons d'inclure les deux options suivantes :

--enable-registration --fleet_id FLEET_PROJECT_ID Ces deux options enregistrent le cluster dans une flotte, où FLEET_ID est l'ID du projet hôte de la flotte. Si vous utilisez un seul projet, FLEET_PROJECT_ID est identique à PROJECT_ID, le parc le projet hôte et le projet de cluster sont identiques. Dans les cas plus complexes, multiprojets, nous vous recommandons d'utiliser un hôte de parc distinct projet.
--enable-all : cette option active à la fois les composants requis et l'enregistrement.

L'outil asmcli configure le plan de contrôle géré directement à l'aide d'outils et de logiques au sein de l'outil CLI. Suivez les instructions ci-dessous en fonction de votre autorité de certification préférée.

Autorités de certification

Sélectionnez une autorité de certification à utiliser pour votre réseau maillé.

Mesh CA

Exécutez la commande suivante pour installer le plan de contrôle avec les fonctionnalités par défaut et Mesh CA. Saisissez vos valeurs dans les espaces réservés fournis.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

Service d'autorité de certification

Suivez la procédure décrite dans Configurer l'autorité de certification.
Exécutez la commande suivante pour installer le plan de contrôle avec les fonctionnalités par défaut et Certificate Authority Service. Saisissez vos valeurs dans les espaces réservés fournis.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

L'outil télécharge tous les fichiers de configuration du plan de contrôle géré dans le --output_dir spécifié, en installant l'outil istioctl et les exemples d'applications. Les étapes de ce guide supposent que vous exécutez istioctl à partir de l'emplacement --output_dir que vous avez spécifié lors de l'exécution de asmcli install, avec istioctl présent dans son sous-répertoire <Istio release dir>/bin.

Si vous réexécutez asmcli sur le même cluster, la configuration du plan de contrôle existante est écrasée. Veillez à spécifier les mêmes options si vous souhaitez la même configuration.

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 à :

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Si l'état n'atteint pas ACTIVE dans quelques minutes, reportez-vous à Vérifier l'état du plan de contrôle géré pour en savoir plus sur les erreurs possibles.

Mises à niveau sans contact

Une fois le plan de contrôle géré installé, Google effectue automatiquement la mise à niveau quand de nouvelles versions ou de nouveaux correctifs sont disponibles.

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 sauf si vous la désactivez.

Avec le plan de données géré, les proxys side-car et les passerelles injectées automatiquement mis à jour conjointement avec le plan de contrôle géré redémarrer des charges de travail pour réinjecter de nouvelles versions du proxy. Normalement, se termine une à deux semaines après la mise à niveau du plan de contrôle géré.

Si cette option est désactivée, la gestion du proxy est régie par le cycle de vie naturel des pods le cluster. L'utilisateur doit les déclencher manuellement pour contrôler la mise à jour taux de conversion.

Le plan de données géré met à niveau les proxys en évinçant les pods en cours d'exécution les versions antérieures du proxy. Les évictions sont effectuées progressivement, conformément à la un budget d'interruptions de pods et le contrôle du taux d'évolution.

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

Si vous avez provisionné le maillage de services Cloud Service géré sur un cluster plus ancien, vous pouvez activez la gestion du plan de données pour l'ensemble du cluster:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Vous pouvez également activer le plan de données géré de manière sélective pour une une révision, un espace de noms ou un pod spécifique du plan de contrôle en l'annotant avec le paramètre même annotation. Si vous contrôlez les composants individuels de manière sélective, l'ordre de priorité est la révision du plan de contrôle, l'espace de noms, puis le pod.

Il peut être nécessaire d'attendre jusqu'à dix minutes pour que le service soit prêt à gérer les proxys du cluster. Exécutez la commande suivante pour vérifier l'état :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Résultat attendu

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Si le service n'est pas prêt dans les dix minutes, consultez la section État du plan de données géré pour connaître les étapes suivantes.

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

Si vous provisionnez 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é continuera d'être désactivé pour les clusters existants où il a été désactivé par défaut par défaut ou manuellement.

Pour désactiver le plan de données géré au niveau du cluster et revenir à gérez vous-même les proxys side-car, modifiez l'annotation:

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

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, procédez comme suit:

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

Activer les notifications de maintenance

Vous pouvez demander à être averti de la mise à jour à venir du plan de données géré à une semaine avant la planification de la maintenance. Les notifications de maintenance ne sont pas envoyées par défaut. Vous devez également Configurer un intervalle de maintenance GKE avant de pouvoir recevoir des notifications. Lorsque cette option est activée, les notifications sont envoyées à au moins deux jours avant la 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.
Sur la ligne Mise à niveau Cloud Service Mesh, dans la colonne E-mail, sélectionnez pour activer les notifications de maintenance.

Chaque utilisateur souhaitant recevoir des notifications doit les activer séparément. Si vous voulez pour définir un filtre de messagerie pour ces notifications, l'objet est le suivant:

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

L'exemple suivant illustre une opération de maintenance classique pour un plan de données géré notification:

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 programmée le ${schedule_date_human_enhanced} à ${Scheduled_time_human_{/2}.

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 de maintenance, nous vous préviendrons par e-mail.

Cordialement,

L'équipe Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, États-Unis Cette annonce vous a été envoyée afin de vous informer de changements importants apportés à 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 réseau maillé ne comporte qu'un seul cluster, ignorez ces étapes concernant l'utilisation de plusieurs clusters et passez à Déployer des applications ou Migrer des applications.

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

Clusters publics

Configurer la découverte des points de terminaison entre les clusters publics

Si vous travaillez sur des clusters publics (clusters non privés), vous pouvez : Configurer la détection de points de terminaison entre des clusters publics ou plus simplement Activez la détection des points de terminaison entre les clusters publics.

Clusters privés

Configurer la recherche de points de terminaison entre les clusters privés

Lorsque vous utilisez des clusters privés GKE, vous devez configurer le point de terminaison du plan de contrôle pour qu'il soit le point de terminaison public au lieu du point de terminaison privé. Reportez-vous à la section Configurer la recherche de points de terminaison entre les clusters privés.

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

Déployer des applications

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

Géré (TD)

Appliquez l'étiquette d'injection par défaut à l'espace de noms:

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

Géré (Istiod)

Recommandé:Exécutez la commande suivante pour appliquer l'injection par défaut. l'étiquette à l'espace de noms:

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

Si vous êtes un utilisateur existant disposant du plan de contrôle Istiod géré: Nous vous recommandons d'utiliser l'injection par défaut, mais celle basée sur les révisions compatibles. Pour ce faire, procédez comme suit:

Exécutez la commande suivante pour localiser les versions 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 figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.

Dans le résultat, la valeur figurant dans la colonne NAME correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.

Appliquez le libellé de révision à l'espace de noms.

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

À ce stade, vous avez correctement configuré le service géré Cloud Service Mesh. Si vous des charges de travail existantes dans des espaces de noms étiquetés, puis redémarrez-les pour obtenir proxys 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, entraîner des erreurs de configuration imprévues et des problèmes qui en découlent avec le side-car conteneurs. Avant de personnaliser l'injection, lisez les informations après le pour les notes sur des paramètres et recommandations spécifiques.

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

Par exemple, la configuration suivante personnalise divers paramètres, en réduisant le nombre de demandes de ressources de processeur, en ajoutant un montage de volume Accroche 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, il convient de veiller certains champs:

Kubernetes nécessite que le champ image soit défini avant l'exécution de l'injection. Vous pouvez définir une image spécifique pour remplacer celle par défaut, mais nous vous recommandons que vous définissez image sur auto, ce qui entraînera l'injecteur de side-car pour sélectionner automatiquement l'image à utiliser.
Certains champs de containers dépendent de paramètres associés. Par exemple, doit être inférieure ou égale à la limite du processeur. Si les deux champs ne sont pas corrects configuré, le démarrage du pod peut échouer.
Kubernetes vous permet de définir à la fois requests et limits pour les ressources de votre Pod spec. GKE Autopilot ne prend en compte que requests. Pour plus consultez Définir des limites de ressources en mode Autopilot.

De plus, certains champs peuvent être configurés à l'aide d'annotations sur le pod. bien qu'il soit recommandé d'utiliser l'approche ci-dessus pour personnaliser les paramètres. Prenez garde aux annotations suivantes:

Pour GKE Standard, si sidecar.istio.io/proxyCPU est défini, veillez à définir explicitement sidecar.istio.io/proxyCPULimit. Dans le cas contraire, La limite du processeur sera définie sur illimitée.
Pour GKE Standard, si sidecar.istio.io/proxyMemory est défini, veillez à définir explicitement sidecar.istio.io/proxyMemoryLimit. Dans le cas contraire, la limite de mémoire du side-car sera définie comme illimitée.
Pour GKE Autopilot, configurer les ressources requests et limits l'utilisation d'annotations peut surprovisionner des ressources. Utiliser l'approche basée sur les modèles d'images à éviter. Consultez Exemples de modification de ressources en Autopilot.

Par exemple, consultez l'annotation de 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"

Vérifier les métriques du plan de contrôle

Vous pouvez afficher la version du plan de contrôle et du plan de données dans l'Explorateur de métriques.

Pour vérifier que votre configuration fonctionne comme prévu:

Dans la console Google Cloud, affichez les métriques du plan de contrôle :

Accéder à l'explorateur de métriques
Choisissez votre espace de travail et ajoutez une requête personnalisée à l'aide des paramètres suivants :
- Type de ressource : conteneur Kubernetes
- Métrique : Clients proxy
- Filtre : container_name="cr-REVISION_LABEL"
- Grouper par: libellé revision et libellé proxy_version
- Aggregator (Agrégateur) : sum (somme)
- Période : 1 minute
Lorsque vous exécutez Cloud Service Mesh avec un plan de contrôle géré par Google et un plan de contrôle interne au cluster, vous pouvez les distinguer grâce au nom de leur conteneur. Par exemple, les métriques gérées comportent container_name="cr-asm-managed", tandis que les métriques non gérées comportent container_name="discovery". Pour afficher les métriques gérées et non gérées, supprimez le filtre sur container_name="cr-asm-managed".
Vérifiez la version du plan de contrôle et la version du proxy en inspectant les champs suivants dans l'explorateur de métriques :
- Le champ revision indique la version du plan de contrôle.
- Le champ proxy_version indique la valeur proxy_version.
- Le champ value indique le nombre de proxys connectés.
Pour connaître le mappage des versions du canal actuel à Cloud Service Mesh, consultez Versions de Cloud Service Mesh par canal

Migrer des applications vers le service géré Cloud Service Mesh

Préparer la migration

Pour préparer la migration des applications depuis le maillage de services Cloud Service intégré au cluster vers le service géré Cloud Service Mesh, procédez comme suit:

Exécutez l'outil comme indiqué dans la section Appliquer le plan de contrôle géré par Google.

(Facultatif) Si vous souhaitez utiliser le plan de données géré par Google, activez la gestion du plan de données :

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Migrer des applications

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

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

Géré (TD)

Appliquez l'étiquette d'injection par défaut à l'espace de noms:

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

Géré (Istiod)

Recommandé:Exécutez la commande suivante pour appliquer l'injection par défaut. l'étiquette à l'espace de noms:

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

Exécutez la commande suivante pour localiser les versions 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 figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.

Dans le résultat, la valeur figurant dans la colonne NAME correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.

Appliquez le libellé 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 satisfait du fonctionnement de votre application, vous pouvez supprimer le istiod du cluster après le passage de tous les espaces de noms au contrôle géré ou les conserver comme solution de secours : istiod effectue automatiquement un scaling à la baisse moins de ressources. Pour la supprimer, passez à Supprimez 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, réexécutez la commande d'installation de Cloud Service Mesh, qui redéploie la passerelle en renvoyant au plan de contrôle du cluster:

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

Attendez-vous à ce résultat :

deployment.apps/istio-ingressgateway rolled back

Désinstaller

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

Dépannage

Pour identifier et résoudre les problèmes lors de l'utilisation du plan de contrôle géré, consultez la section Résoudre les problèmes liés au plan de contrôle géré.

Étape suivante

Apprenez-en plus sur les versions disponibles.
Migrer à partir de IstioOperator
Migrer une passerelle vers le plan de contrôle géré.
Découvrez comment Activer les fonctionnalités gérées Cloud Service Mesh facultatives par exemple: