Provisionner Cloud Service Mesh géré avec asmcli

Présentation

Cloud Service Mesh géré avec asmcli est un plan de contrôle géré et un plan de données géré que vous configurez simplement. Google en gère la fiabilité, les mises à niveau, le scaling et la sécurité de manière rétrocompatible. Ce guide explique comment configurer ou migrer des applications vers Cloud Service Mesh géré dans une configuration à cluster unique ou multicluster avec asmcli.

Pour en savoir plus sur les fonctionnalités compatibles et les limites de Cloud Service Mesh géré, consultez la section Fonctionnalités compatibles avec Cloud Service Mesh géré.

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.
• L'outil d'installation asmcli, kpt et les autres outils spécifiés dans la section Installer les outils requis

Pour un provisionnement plus rapide, Workload Identity doit être activé sur vos clusters. Si Workload Identity n'est pas activé, la provision l'activera automatiquement.

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 équilibrer la stabilité et la vitesse de mise à niveau. Les nouvelles modifications apportées aux composants du cluster Cloud Service Mesh (y compris CNI, MDPC, proxys et CRD Istio) seront déployées en priorité sur les clusters qui s'abonnent 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.

  • Cloud Service Mesh géré n'est pas compatible avec la modification sécurisée des canaux de publication GKE.
  • Si vous modifiez le version disponible GKE, Cloud Service Mesh met automatiquement à niveau/rétrograde les composants du cluster (CNI, MDPC, version par défaut du proxy injecté 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 : 50 m, mémoire: 128 Mo.
  • 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 cette règle est activée, ServiceEntry risque de 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. Vous pouvez effectuer cette opération séparément avant la provision ou pendant la provision en transmettant les options --enable-registration et --fleet-id.

• La fonctionnalité de parc Service Mesh doit être activée sur votre projet. Vous pouvez l'activer pendant la provision 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 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.
  • Pour un environnement multicluster à un seul projet, le projet de parc peut être identique au projet de cluster. Pour en savoir plus sur les parcs, consultez la section Présentation des parcs.
  • Pour un environnement multiprojet, nous vous recommandons d'héberger le parc dans un projet distinct des projets de cluster. Si vos règles organisationnelles et votre configuration existante le permettent, nous vous recommandons d'utiliser le projet VPC partagé comme projet hôte de 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 dont la version est supérieure ou égale à 1.22.1-gke.10, vous devrez peut-être effectuer des étapes de configuration supplémentaires :
    • Si vous provisionnez Cloud Service Mesh sur le canal de version standard ou stable, vous devez utiliser l'option supplémentaire --use-vpcsc lorsque vous appliquez le plan de contrôle géré et suivre le guide VPC Service Controls (preview). Sinon, le provisionnement ne sera pas en mesure d'effectuer les contrôles de sécurité.
    • Si vous provisionnez Cloud Service Mesh sur le canal de publication rapide, vous n'avez pas besoin d'utiliser l'option supplémentaire --use-vpcsc lorsque vous appliquez le plan de contrôle géré, mais vous devez suivre le guide VPC Service Controls (GA).

Rôles requis pour installer Cloud Service Mesh

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

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 Cloud Service Mesh géré. 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.

Limites

Nous vous recommandons de consulter la liste des fonctionnalités compatibles et limites de 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.

• Pour les clusters GKE Autopilot, la configuration multiprojet 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 500 millions de processeurs et 512 Mo de mémoire. Vous pouvez remplacer les valeurs par défaut à l'aide d'une injection personnalisée.

• Pour les clusters GKE Autopilot, des avertissements peuvent s'afficher pour les composants Cloud Service Mesh "DaemonSet n'a aucun nœud sélectionné" jusqu'à ce que le pool de nœuds 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és dans le cluster spécifié. Si des CRD d'Istio sont présentes dans le cluster, elles seront écrasées.

• CNI Istio et Cloud Service Mesh ne sont pas compatibles avec GKE Sandbox. Par conséquent, Cloud Service Mesh géré avec l'implémentation TRAFFIC_DIRECTOR n'est pas compatible avec les clusters avec GKE Sandbox activé.

• L'outil asmcli doit avoir accès au point de terminaison Google Kubernetes Engine (GKE). Vous pouvez configurer l'accès via un serveur de saut, tel qu'une VM Compute Engine dans le cloud privé virtuel (VPC) qui offre un accès spécifique.

Avant de commencer

Configurer gcloud

Procédez comme suit même si vous utilisez Cloud Shell.

1. 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)"
      ```
   

2. Mettez à jour les composants :

   gcloud components update
   

3. Configurez kubectl de façon à pointer vers le cluster.

   gcloud container clusters get-credentials CLUSTER_NAME \
        --zone CLUSTER_LOCATION \
        --project PROJECT_ID
   

Télécharger l'outil d'installation

1. 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
   

2. 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 de votre maillage.

Appliquer le plan de contrôle géré

Avant d'appliquer le plan de contrôle géré, vous devez sélectionner un canal de publication. Votre canal Cloud Service Mesh est déterminé par le canal de votre cluster GKE au moment du provisionnement de Cloud Service Mesh géré. Notez que l'utilisation de plusieurs canaux dans le même cluster en même temps n'est pas possible.

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, le champ FLEET_PROJECT_ID est identique à PROJECT_ID, le projet hôte du parc et le projet du cluster sont identiques. Dans les configurations plus complexes telles que multiprojets, nous vous recommandons d'utiliser un projet hôte de parc distinct.

• --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é.

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

  ./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 au bout de quelques minutes, consultez la section 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 le met automatiquement à jour lorsque 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.

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. Cette opération commence après la mise à niveau du plan de contrôle et se termine normalement dans les deux semaines suivant son démarrage.

Notez que le plan de données géré repose sur le canal de version GKE. Si vous modifiez le version disponible de GKE lorsque 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 passive, 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.

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é Cloud Service Mesh géré sur un ancien cluster, vous pouvez activer 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 révision, un espace de noms ou un pod de plan de contrôle spécifique en lui attribuant la même annotation. Si vous contrôlez sélectivement des composants individuels, l'ordre de priorité est le suivant : révision du plan de contrôle, puis espace de noms, puis 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 é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, 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:

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'à la mise à jour de tous les pods gérés (généralement 12 heures). La fenêtre de maintenance n'est pas respectée pour les déploiements liés à des failles de sécurité.

Cloud Service Mesh utilise la fenêtre 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. Lorsqu'elle est activée, cette option envoie des notifications au moins deux jours avant l'opération de mise à niveau.

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

1. Accédez à la page Communication.

   Accédez à la page Communication.

2. 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 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 pour 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 pour 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 Amphitheatre 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 multiclusters et passez à Déployer des applications ou à Migrer des applications.

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

Déployer des applications

Activez l'espace de noms pour l'injection : La procédure dépend de votre implémentation du plan de contrôle.

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

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

Vérifiez que l'étiquette de l'espace de noms est correctement appliquée à 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 qu'ils reçoivent des 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, mais cela peut entraîner des erreurs de configuration imprévues et des problèmes avec les conteneurs sidecar. Avant de personnaliser l'injection, lisez les informations qui suivent l'exemple pour obtenir des remarques sur les paramètres et les recommandations spécifiques.

La configuration par pod permet d'ignorer 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 forçage du modèle d'injection par défaut.

Par exemple, la configuration suivante personnalise divers paramètres, y compris la réduction des requêtes de processeur, l'ajout d'un montage de volume et l'ajout d'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, vous pouvez définir n'importe quel champ d'un pod. Toutefois, vous devez faire preuve de prudence pour certains champs:

• Kubernetes nécessite 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 l'image par défaut, nous vous recommandons de définir image sur auto, ce qui entraînera la sélection automatique de l'image à utiliser par l'injecteur sidecar.
• Certains champs de containers dépendent de paramètres associés. Par exemple, il doit être inférieur ou égal à 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 la section Définir des limites de ressources dans Autopilot.

De plus, certains champs sont configurables par 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, veillez à définir explicitement sidecar.istio.io/proxyCPULimit. Sinon, la limite de processeur du sidecar sera définie comme illimitée.
• 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 sidecar sera définie comme illimitée.
• Pour GKE Autopilot, la configuration des ressources requests et limits à l'aide d'annotations peut entraîner un surprovisionnement de ressources. Pour éviter cela, utilisez l'approche du modèle d'image. 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"

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:

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

   Accéder à l'explorateur de métriques

2. 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
   • Agrégateur: sum
   • Période : 1 minute

   Lorsque vous exécutez Cloud Service Mesh avec à la fois un plan de contrôle géré par Google et un plan de contrôle au sein du cluster, vous pouvez distinguer les métriques en fonction de leur nom de 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".

3. 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 le mappage entre le canal actuel et la version de Cloud Service Mesh, consultez la section Versions de Cloud Service Mesh par canal.

Migrer des applications vers Cloud Service Mesh géré

Préparer la migration

Pour vous préparer à migrer des applications de Cloud Service Mesh au sein du cluster vers Cloud Service Mesh géré, procédez comme suit:

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

2. (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 de Cloud Service Mesh au sein du cluster vers Cloud Service Mesh géré, procédez comme suit:

1. Remplacez le libellé de l'espace de noms actuel. La procédure dépend de votre implémentation du plan de contrôle.

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

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

1. Effectuez une mise à niveau progressive des déploiements dans l'espace de noms :

   kubectl rollout restart deployment -n NAMESPACE
   

2. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

3. 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.

4. 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.

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

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

deployment.apps/istio-ingressgateway rolled back

Désinstaller

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.

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 un plan de contrôle géré
• Découvrez comment activer les fonctionnalités facultatives de Cloud Service Mesh gérées, par exemple :
  • Journaux d'accès Envoy
  • Traçage
  • Images Distroless
  • Authentification de l'utilisateur final