Configurer Anthos Service Mesh géré

Présentation

Anthos Service Mesh géré est un plan de contrôle géré par Google et un plan de données facultatif 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 le service Anthos Service Mesh géré dans une configuration à cluster unique ou multicluster.

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

Prérequis

Pour commencer, ce guide suppose que vous avez :

Conditions requises

Migrations

  • Les migrations directes/mises à niveau du plan de contrôle géré dans le cluster vers le plan de contrôle géré par Google ne sont compatibles qu'avec les versions 1.9 et ultérieures (installées avec Mesh CA).
  • Les installations utilisant Istio CA doivent d'abord migrer vers Mesh CA 1.9 ou version ultérieure.
  • Les migrations/mises à niveau indirectes sont compatibles, ce qui signifie que vous pouvez suivre les chemins de mise à niveau standards d'Anthos Service Mesh d'une version à l'autre jusqu'à atteindre Anthos Service Mesh 1.11 avec un plan de contrôle au sein du cluster. Vous pouvez ensuite migrer vers le plan de contrôle géré par Google.

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 :

  • Anthos Service Mesh géré peut utiliser plusieurs clusters GKE dans un seul projet Google Cloud.

  • L'API IstioOperator n'est pas compatible.

  • Limites du plan de données géré :

    • Cette version bêta du plan de données géré n'est disponible que pour les nouveaux déploiements du plan de contrôle géré. 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 le script d'installation comme décrit dans la section Appliquer le plan de contrôle géré par Google.

    • Le plan de données géré est disponible dans les versions disponibles standards et rapides.

Activer Workload Identity

Si Workload Identity n'est pas activé, consultez la section Activer Workload Identity sur un cluster pour connaître les autorisations IAM requises ainsi que la commande gcloud CLI pour l'activation.

Téléchargez le script d'installation

  1. Téléchargez la dernière version du script qui installe Anthos Service Mesh 1.11.8 dans le répertoire de travail actuel :

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm

  2. Rendez le script exécutable :

    chmod +x install_asm

Configurer chaque cluster

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

Obtenir les identifiants du cluster

Récupérez les identifiants appropriés. La commande suivante dirige également le contexte kubectl vers le cluster cible.

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

Appliquer le plan de contrôle géré par Google

Exécutez le script d'installation install_asm pour chaque cluster qui utilisera Anthos Service Mesh géré. Nous vous recommandons d'inclure les deux options suivantes lorsque vous exécutez install_asm :

  • --option cni-managed : cette option active le plug-in CNI (Container Network Interface) Istio. Le plug-in CNI configure la redirection du trafic réseau vers et depuis les proxys side-car à l'aide de l'interface CNI CNCF au lieu d'utiliser un conteneur init à privilèges élevés.

  • --enable-registration : cette option enregistre le cluster auprès de fleet.

Ces options sont requises si vous souhaitez également déployer le plan de données géré par Google. Pour obtenir la liste complète des options, consultez la page de référence asmcli.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

Le script télécharge tous les fichiers sur la sortie spécifiée (--output_dir) pour configurer le plan de contrôle géré, en installant une passerelle Istio, ainsi que l'outil istioctl et des exemples d'application. Les étapes de ce guide supposent que vous exécutez istioctl à partir de la racine du répertoire d'installation, avec istioctl présent dans son sous-répertoire /bin.

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

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 plus facilement vos passerelles dans un environnement de production. Si le cluster nécessite une passerelle d'entrée, consultez la section Installer des passerelles Istio.

Appliquer le plan de données géré par Google

Si vous souhaitez que les mises à niveau des proxys soient gérées par Google, activez le plan de données géré par Google. Une fois activé, les proxys side-car et les passerelles injectées sont automatiquement mis à niveau conjointement avec le plan de contrôle géré.

Dans l'aperçu des fonctionnalités, le plan de données géré met à niveau les proxys en expulsant les pods qui exécutent des versions plus anciennes du proxy. Les évictions sont effectuées de manière ordonnée en respectant le budget d'interruption des pods et en contrôlant le rythme des modifications.

Cette version bêta du plan de données géré ne gère pas les éléments suivants :

  • Pods non injectés.
  • Pods injectés manuellement à l'aide de istioctl kube-inject.
  • Tâches
  • Ensembles avec état
  • DaemonSet

Si vous ne souhaitez pas utiliser de plan de données géré ou si vous ne souhaitez pas l'activer pour tous les espaces de noms, vous devez déclencher un redémarrage des proxys pour bénéficier de la dernière image du proxy. Le plan de contrôle continue de fonctionner avec les proxys existants.

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

  1. Activez la gestion du plan de données :

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

    Vous pouvez également activer le plan de données géré par Google pour un pod spécifique en lui attribuant la même annotation. Lorsque vous annotez un pod spécifique, ce pod utilise le proxy side-car géré par Google, et le reste des charges de travail utilise les proxys side-car non gérés.

  2. Répétez l'étape précédente pour chaque espace de noms sur lequel vous souhaitez un plan de données géré.

  3. Activez Anthos Service Mesh dans le parc :

    gcloud alpha container hub mesh enable --project=PROJECT_ID

Il peut s'écouler jusqu'à dix minutes avant que le contrôleur de plan de données ne soit prêt à gérer les proxies du cluster. Exécutez la commande suivante pour vérifier l'état :

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

Lorsque le contrôleur de plan de données est prêt, la commande génère le résultat suivant : Managed Data Plane is ready.

Si l'état du contrôleur de plan de données n'est pas prêt après plus de 10 minutes d'attente, consultez la section État du plan de données géré pour obtenir des conseils de dépannage.

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

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

Installer les passerelles Istio (facultatif)

Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

Nous vous recommandons de créer un espace de noms distinct pour les passerelles. Ne déployez pas les passerelles dans l'espace de noms istio-system.

Vous pouvez installer une ou plusieurs passerelles Istio dans votre cluster pour gérer le trafic entrant, en procédant comme suit :

  1. Choisissez l'une de ces deux options pour configurer l'espace de noms dans lequel vous allez déployer la passerelle aux étapes suivantes.

    • Activez l'espace de noms pour l'injection : 
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

    OR

    • Activez l'injection uniquement pour le pod de la passerelle, mais pas pour tous les pods de l'espace de noms. Cette commande supprime tous les libellés d'injection, puis activez l'injection sur le pod lui-même : 
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-

  2. Créez un déploiement et un service pour la passerelle, en utilisant l'exemple minimal suivant :

    kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

  3. Après avoir créé le déploiement, vérifiez que les nouveaux services fonctionnent correctement :

    kubectl get pod,service -n GATEWAY_NAMESPACE

    Vérifiez que le résultat ressemble à ce qui suit :

    NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Vous pouvez choisir de laisser le contrôleur de plan de données géré gérer les proxys pour vos passerelles comme il le fait pour vos services. Si vous avez déployé le plan de données géré et que vous souhaitez que vos proxys de passerelle soient gérés, ajoutez un libellé et une annotation à l'espace de noms de la passerelle, comme décrit dans la section Appliquer le plan de données géré par Google.

Si vous choisissez de gérer vous-même les passerelles, vous devez redémarrer les pods dans GATEWAY_NAMESPACE lorsqu'une nouvelle version d'Anthos Service Mesh est publiée afin qu'ils récupèrent la configuration du nouveau plan de contrôle. Avant de redémarrer les pods, vérifiez que la nouvelle version du plan de contrôle a été déployée sur votre cluster à l'aide de la requête personnalisée de l'explorateur de métriques fournie dans Vérifier les métriques du plan de contrôle.

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

Le plan de contrôle géré d'Anthos Service Mesh accepte une configuration à un seul projet, à un seul réseau et à plusieurs déploiements principaux, avec la différence que le plan de contrôle n'est pas installé dans le cluster.

Avant de continuer, vous devez avoir déjà exécuté le script d'installation 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.

Pour chaque cluster, activez la découverte des points de terminaison en exécutant les commandes suivantes une fois pour chaque autre cluster i=1..N du maillage :

  1. Pour chaque cluster, assurez-vous que le contexte de configuration kubectl pointe vers le cluster actuel :

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME

  2. Activez la détection des points de terminaison en exécutant les commandes suivantes une fois pour chaque autre cluster i=1..N dans le maillage :

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

  3. Vérifiez que le secret a été créé en exécutant la commande suivante :

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

    Vérifiez le résultat attendu :

    NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

  4. Si le cluster actuel est ajouté à un maillage multi-cluster existant, laissez tous les autres clusters découvrir ses points de terminaison en créant un secret correspondant au cluster actuel dans tous les autres clusters :

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}

  5. Vous pouvez également vérifier le secret de l'autre cluster :

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

    Vérifiez le résultat attendu :

    NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

Pour obtenir plus de détails et un exemple avec deux clusters, consultez la section Activer la détection des points de terminaison.

Déploiement d'applications

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:asm-managed-rapid :

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

À ce stade, vous avez configuré avec succès le plan de contrôle géré d'Anthos Service Mesh. Vous êtes maintenant prêt à déployer vos applications, ou vous pouvez déployer 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. De plus, si le cluster exécute également le service Anthos Service Mesh version 1.7, 1.8 ou ultérieure avec l'autorité de certification Mesh dans d'autres espaces de noms, vérifiez que l'application peut communiquer avec les autres applications contrôlées par le plan de contrôle au sein du 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-asm-managed-rapid"
    • 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é

Anthos Service Mesh géré est uniquement compatible avec la migration d'Anthos Service Mesh 1.9 qui utilise l'autorité de certification Mesh.

Pour migrer vers Anthos Service Mesh géré, procédez comme suit :

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

  2. Si vous avez déployé le plan de contrôle et le plan de données gérés par Google :

    1. Activez la gestion du plan de données :

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

    2. Activez Anthos Service Mesh dans le parc :

      gcloud alpha container hub mesh enable --project=PROJECT_ID

  3. Remplacez le libellé de l'espace de noms actuel par le libellé istio.io/rev:asm-managed-rapid :

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --overwrite

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

Un cluster peut combiner des révisions, par exemple Anthos Service Mesh 1.7 et 1.8, et un plan de contrôle au sein du cluster. Vous pouvez combiner des espaces de noms à l'aide de différentes révisions du plan de contrôle d'Anthos Service Mesh.

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 au sein du cluster, 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 :

  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

Migrer une passerelle vers un plan de contrôle géré par Google

  1. Créez un déploiement Kubernetes pour la nouvelle version de la passerelle à l'aide de la documentation. Vous devez configurer le service de passerelle Kubernetes existant pour sélectionner à la fois l'ancienne et la nouvelle version, en utilisant le champ selector dans la configuration du service.

  2. À l'aide de cette commande kubectl scale, augmentez progressivement le nouveau déploiement, tout en réduisant l'ancien et en recherchant les signes d'interruption ou de temps d'arrêt de service. Si la migration réussit, vous devez atteindre zéro instance ancienne sans rencontrer d'interruption de service.

Désinstaller

Le plan de contrôle géré par Google effectue un scaling automatique à zéro instance lorsqu'aucun espace de noms ne l'utilise. Par conséquent, aucune désinstallation n'est requise.

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