Configurer Anthos Service Mesh géré avec "asmcli"

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Présentation

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

Pour en savoir plus sur les fonctionnalités compatibles et les limitations d'Anthos Service Mesh géré, consultez la section Fonctionnalités compatibles avec Anthos Service Mesh géré.

Prerequisites

Pour commencer, ce guide suppose que vous avez :

Conditions requises

  • Un ou plusieurs clusters avec une version compatible de GKE, dans l'une des régions compatibles.
  • Assurez-vous que la machine cliente à partir de laquelle vous installez Anthos 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 l'installation ou pendant l'installation en transmettant les options --enable-registration et --fleet-id.
  • La fonctionnalité de flotte de maillage de services doit être activée dans votre projet. Vous pouvez l'activer lors de l'installation en transmettant --enable-gcp-components ou en exécutant la commande suivante:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
    

    FLEET_PROJECT_ID est l'ID du projet hôte du parc.

  • GKE Autopilot n'est compatible qu'avec GKE version 1.21.3 ou ultérieure. CNI sera installé et géré par Google.

  • Le service Anthos Service Mesh géré 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.
    • En outre, nous vous recommandons de disposer d'un projet pour héberger le VPC partagé et de projets de service séparés pour la création de clusters. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.
    • Si votre organisation utilise VPC Service Controls, vous devez utiliser l'option --use-vpcsc supplémentaire lorsque vous appliquez le plan de contrôle géré. Sinon, l'installation ne sera pas en mesure d'effectuer les contrôles de sécurité. La fonctionnalité VPC Service Controls est disponible dans les canaux standard et rapide.

Limites

Nous vous recommandons de consulter la liste des fonctionnalités compatibles et limitations d'Anthos Service Mesh géré. 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.

  • Si vous avez déjà déployé le plan de contrôle géré et que vous souhaitez déployer le plan de données géré, vous devez réexécuter l'outil d'installation comme décrit dans la section Appliquer le plan de contrôle géré.

  • Pour les clusters GKE Autopilot, la configuration multiprojet n'est compatible qu'avec GKE 1.23 et les versions ultérieures. Afin de vous adapter à la limite de ressources de GKE Autopilot, les demandes et limites de ressources proxy par défaut sont définies sur 500 mCPU et 512 Mo de mémoire.

  • Les fonctionnalités réellement disponibles pour Anthos Service Mesh géré dépendent de la version disponible. Pour en savoir plus, consultez la liste complète des fonctionnalités compatibles et limitations d'Anthos Service Mesh.

  • Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD d'Istio correspondant au canal sélectionné sont installées dans le cluster spécifié. Si des CRD d'Istio sont présentes dans le cluster, elles seront écrasées.

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
    
  2. Mettez à jour les composants :

    gcloud components update
    
  3. Configurez kubectl pour qu'il pointe 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 Anthos 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 une version disponible.

Exécutez l'outil d'installation pour chaque cluster qui utilisera Anthos 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.

Si votre organisation applique VPC Service Controls pour votre projet, vous devez configurer une option supplémentaire : --use-vpcsc. Sinon, l'installation ne sera pas en mesure d'effectuer les contrôles de sécurité. La fonctionnalité VPC Service Controls est disponible dans les canaux standard et rapide.

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. Remplacez RELEASE_CHANNEL par le canal approprié : regular, stable ou rapid.

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

Service d'autorité de certification

  1. Suivez la procédure décrite dans Configurer l'autorité de certification.
  2. 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. Remplacez RELEASE_CHANNEL par le canal approprié : regular, stable ou rapid.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --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é

L'outil asmcli crée une ressource personnalisée ControlPlaneRevision dans le cluster. L'état de cette ressource est mis à jour lorsque le plan de contrôle géré est provisionné ou que le provisionnement échoue.

Inspectez l'état de la ressource. Remplacez NAME par la valeur correspondant à chaque canal : asm-managed, asm-managed-stable ou asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

Le résultat est semblable à :

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

La condition de rapprochement détermine si le plan de contrôle géré fonctionne correctement. Si la valeur est true, le plan de contrôle fonctionne correctement. Stalled détermine si le processus de provisionnement du plan de contrôle géré a rencontré une erreur. Si la valeur est Stalled, le champ Message contient plus d'informations sur l'erreur spécifique. Pour en savoir plus sur les erreurs possibles, consultez la section Codes figés.

Mises à niveau sans contact

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

Il n'est pas obligatoire de mettre à niveau le plan de données chaque fois qu'une mise à niveau de plan de contrôle est effectuée. Le plan de contrôle continue de fonctionner avec tous les proxys dans la fenêtre d'assistance, mais il est recommandé d'accéder aux dernières fonctionnalités, corrections et améliorations de performances du plan de données. Pour effectuer la mise à niveau vers la dernière image de proxy publiée sur votre canal, vous pouvez effectuer un redémarrage progressif si nécessaire, ou appliquer le plan de données géré qui le fera automatiquement pour vous.

Appliquer le plan de données géré (facultatif)

Si vous souhaitez que Google gère entièrement les mises à niveau des proxys, activez le plan de données géré.

Si cette option est activée, les proxys side-car et les passerelles injectées sont 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. Si cette option est désactivée, la gestion du proxy 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 évinçant les pods qui exécutent d'anciennes versions du proxy. Les évictions sont effectuées progressivement, en respectant le budget d'interruption des pods et en contrôlant le rythme des modifications.

Notez que le plan de données géré nécessite le plug-in CNI (Container Network Interface) d'Istio, qui est désormais activé par défaut lorsque vous déployez le plan de contrôle géré.

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

Le plan de données géré est disponible dans les versions disponibles rapide et standard.

Pour activer le plan de données géré, procédez comme suit :

  1. 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 révision, un espace de noms ou un pod de plan de contrôle spécifique en lui annotant la même annotation. Si vous contrôlez des composants individuels de manière sélective, l'ordre de priorité est la révision du plan de contrôle, puis 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.

Si vous souhaitez désactiver le plan de données géré et revenir à la gestion des proxys side-car vous-même, modifiez l'annotation :

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  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"}'

Vous pouvez également désactiver le plan de données géré pour un pod spécifique en lui annotant la même annotation.

Activer les notifications de maintenance

Vous pouvez demander à être averti de la maintenance à venir 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.

Pour activer les notifications de maintenance :

  1. Accédez à la page Communication.

    Accédez à la page Communication.

  2. Dans la ligne Mise à niveau d'Anthos 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 Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"

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

Avant de continuer, vous devez avoir déjà configuré Anthos Service Mesh géré sur chaque cluster, comme décrit dans les étapes précédentes. Il n'est pas nécessaire d'indiquer qu'un cluster est un cluster principal, car il s'agit du comportement par défaut.

Assurez-vous également d'avoir téléchargé asmcli (uniquement si vous souhaitez vérifier votre configuration avec l'exemple d'application) et définir les variables de projet et de cluster.

Clusters publics

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

Si vous utilisez des clusters publics (non privés), vous pouvez soit configurer la découverte des points de terminaison entre les clusters publics, soit activer la découverte 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

Pour déployer des applications, utilisez le libellé correspondant au canal que vous avez configuré lors de l'installation, ou bien istio-injection=enabled si vous utilisez des libellés d'injection par défaut.

Libellé d'injection par défaut

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

Libellé de révision

Avant de déployer des applications, supprimez les anciens libellés istio-injection de leurs espaces de noms et définissez à la place le libellé istio.io/rev=REVISION_LABEL.

Pour lui attribuer un libellé de révision spécifique, cliquez sur REVISION_LABEL et remplacez-le par le libellé applicable : asm-managed-rapid pour un chargement rapide, asm-managed pour un déploiement standard ou asm-managed-stable pour un déploiement stable.

Le libellé de révision correspond à une version disponible :

Libellé de révision Canal
asm-managed Standard
asm-managed-rapid Version précoce
asm-managed-stable Stable
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite

À ce stade, vous avez configuré avec succès le plan de contrôle géré d'Anthos Service Mesh. Si vous avez des charges de travail existantes dans des espaces de noms avec libellé, redémarrez-les pour qu'elles soient injectées.

Vous êtes maintenant prêt à déployer vos applications ou l'exemple d'application Bookinfo.

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.

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 la configuration fonctionne correctement, procédez comme suit :

  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é de révision et libellé proxy_version
    • Somme de l'agrégateur
    • Période : 1 minute

    Lorsque vous exécutez Anthos 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 d'Anthos Service Mesh, consultez la section Versions d'Anthos Service Mesh par canal.

Migrer des applications vers Anthos Service Mesh géré

Préparer la migration

Pour préparer la migration d'applications d'Anthos Service Mesh en cluster vers Anthos 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 les applications

Pour migrer des applications d'Anthos Service Mesh en cluster vers Anthos Service Mesh géré, procédez comme suit:

  1. Remplacez le libellé de l'espace de noms actuel. La procédure à suivre varie selon que vous souhaitez utiliser des libellés d'injection par défaut (par exemple, istio-injection enabled) ou le libellé de révision.

    Libellé d'injection par défaut

    1. Exécutez la commande suivante pour déplacer le tag par défaut vers la révision gérée :

      istioctl tag set default --revision REVISION_LABEL
      
    2. Si ce n'est pas déjà fait, exécutez la commande suivante pour ajouter un libellé à l'espace de noms à l'aide de istio-injection=enabled :

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

    Libellé de révision

    Si vous avez utilisé le libellé istio.io/rev=REVISION_LABEL, exécutez la commande suivante :

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
        --overwrite
    
  2. Effectuez une mise à niveau progressive des déploiements dans l'espace de noms :

    kubectl rollout restart deployment -n NAMESPACE
    
  3. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

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

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

  6. Vérifiez que les métriques s'affichent comme prévu en suivant les étapes décrites dans la section Vérifier les métriques du plan de contrôle.

Si vous êtes satisfait du fonctionnement de votre application, vous pouvez supprimer le istiod du cluster après avoir basculé tous les espaces de noms vers le plan de contrôle géré, ou les conserver en tant que sauvegarde. istiod effectuera un scaling à la baisse de façon à utiliser moins de ressources. Pour le supprimer, passez à la section 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 :

  1. 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
    
  2. 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 d'Anthos 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

Le plan de contrôle géré évolue automatiquement jusqu'à zéro lorsqu'aucun espace de noms ne l'utilise. Pour connaître la procédure détaillée, consultez la page Désinstaller Anthos 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