Configurer un maillage multicluster sur Cloud Service Mesh géré

Remarque : Ce guide est uniquement consacré à Cloud Service Mesh avec les API Istio. Il ne concerne pas les API. Google Cloud Pour en savoir plus, consultez la présentation de Cloud Service Mesh. .

Ce guide explique comment joindre deux clusters dans un seul maillage de services Cloud Service Mesh à l'aide de Mesh CA ou de Certificate Authority Service et comment activer l'équilibrage de charge interclusters. Vous pouvez facilement étendre ce processus pour intégrer autant de clusters que vous le souhaitez dans votre maillage.

Une configuration multicluster Cloud Service Mesh peut résoudre plusieurs scénarios d'entreprise essentiels, tels que l'échelle, l'emplacement et l'isolation. Pour en savoir plus, consultez la section Cas d'utilisation multicluster.

Prérequis

Dans ce guide, nous partons du principe que vous disposez d'au moins deux Google Cloud clusters GKE répondant aux exigences suivantes :

• Cloud Service Mesh est installé sur les clusters. Vous avez besoin de asmcli, de l'outil istioctl et d'exemples que asmcli télécharge dans le répertoire que vous avez spécifié dans --output_dir.
• Les clusters de votre maillage doivent être connectés entre tous les pods avant de configurer Cloud Service Mesh. En outre, 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. Nous vous recommandons également de disposer d'un projet pour héberger le VPC partagé et de deux projets de service pour la création de clusters. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.
• Si vous utilisez Certificate Authority Service, les pools d'autorités de certification subordonnées correspondants de tous les clusters doivent être associés au même pool d'autorités de certification racine. Sinon, ils devront tous utiliser le même pool d'autorités de certification.

Définir des variables de projet et de cluster

1. Créez les variables d'environnement suivantes pour l'ID de projet, la zone ou la région du cluster, le nom du cluster et le contexte.

   export PROJECT_1=PROJECT_ID_1
   export LOCATION_1=CLUSTER_LOCATION_1
   export CLUSTER_1=CLUSTER_NAME_1
   export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
   
   export PROJECT_2=PROJECT_ID_2
   export LOCATION_2=CLUSTER_LOCATION_2
   export CLUSTER_2=CLUSTER_NAME_2
   export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
   

2. S'il s'agit de nouveaux clusters, veillez à récupérer les identifiants de chaque cluster à l'aide des commandes gcloud suivantes. Sinon, la variable context associée ne sera pas disponible pour les étapes suivantes de ce guide.

   Les commandes dépendent du type de cluster, régional ou zonal :

   Régional

   gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
   

   Zonal

   gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
   

Créer une règle de pare-feu

Dans certains cas, vous devez créer une règle de pare-feu pour autoriser le trafic interclusters. Par exemple, vous devez créer une règle de pare-feu dans les cas suivants :

• Vous utilisez différents sous-réseaux pour les clusters de votre maillage.
• Vos pods ouvrent des ports autres que 443 et 15002.

GKE ajoute automatiquement des règles de pare-feu à chaque nœud pour autoriser le trafic au sein du même sous-réseau. Si votre maillage contient plusieurs sous-réseaux, vous devez configurer explicitement les règles de pare-feu pour autoriser le trafic entre sous-réseaux. Vous devez ajouter une règle de pare-feu pour chaque sous-réseau afin d'autoriser les blocs CIDR des adresses IP sources et les ports cible pour l'ensemble du trafic entrant.

Les instructions suivantes permettent d'établir la communication entre tous les clusters de votre projet, ou uniquement entre $CLUSTER_1 et $CLUSTER_2.

1. Recueillez des informations sur le réseau de vos clusters.

   Tous les clusters du projet

   Si les clusters se trouvent dans le même projet, vous pouvez utiliser la commande suivante pour autoriser la communication entre tous les clusters de votre projet. Si vous ne souhaitez pas exposer des clusters de votre projet, exécutez la commande décrite dans l'onglet Clusters spécifiques.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

   Clusters spécifiques

   La commande suivante autorise la communication entre $CLUSTER_1 et $CLUSTER_2, et n'expose pas les autres clusters de votre projet.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

2. Créez la règle de pare-feu.

   GKE

   gcloud compute firewall-rules create istio-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --direction=INGRESS \
       --priority=900 \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
       --network=YOUR_NETWORK
   

   Autopilot

   TAGS=""
   for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
   do
       TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
   done
   TAGS=${TAGS::-1}
   echo "Network tags for pod ranges are $TAGS"
   
   gcloud compute firewall-rules create asm-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --network=gke-cluster-vpc \
       --direction=INGRESS \
       --priority=900 --network=VPC_NAME \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags=$TAGS
   

Configurer la découverte des points de terminaison

Remarque : Pour plus d'informations sur la découverte des points de terminaison, consultez la section Découverte des points de terminaison avec plusieurs plans de contrôle.

Avertissement : Si la découverte des points de terminaison est activée entre les clusters, les services interclusters ne peuvent pas communiquer entre eux sans une configuration DNS appropriée. En effet, les services GKE dépendent du nom de domaine complet de chaque service pour le routage du trafic. Vous pouvez activer le proxy DNS, pour autoriser la découverte interclusters. Le proxy DNS capture toutes les requêtes DNS et les résout à l'aide des informations du plan de contrôle.

Activer la découverte des points de terminaison entre les clusters publics ou privés avec l'API déclarative

L'activation de Cloud Service Mesh géré avec l'API Fleet active la découverte des points de terminaison pour ce cluster. Si vous avez provisionné Cloud Service Mesh géré avec un autre outil, vous pouvez activer manuellement la découverte des points de terminaison sur les clusters publics ou privés d'un parc en appliquant la configuration "multicluster_mode":"connected" dans le asm-options fichier ConfigMap. Détection de services interclusters sera automatiquement activée entre les clusters de la même flotte pour lesquels cette configuration est activée.

**Avertissement** : N'utilisez pas cette méthode si vos clusters utilisent des secrets distants existants.

Il s'agit de la seule façon de configurer la découverte des points de terminaison multicluster si vous disposez de l'implémentation du plan de contrôle géré (TD), et de la méthode recommandée pour la configurer si vous disposez de l'implémentation gérée (Istiod).

Avant de continuer, vous devez avoir créé une règle de pare-feu.

Activer

Si le fichier ConfigMap asm-options existe déjà dans votre cluster, activez la découverte des points de terminaison pour le cluster :

      kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

Si le fichier ConfigMap asm-options n'existe pas encore dans votre cluster, alors créez-le avec les données associées et activez la découverte des points de terminaison pour le cluster :

      kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')

Désactiver

Désactivez la découverte des points de terminaison pour un cluster :

      kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'

Si vous annulez l'enregistrement d'un cluster du parc sans désactiver la découverte des points de terminaison, les secrets peuvent rester dans le cluster. Vous devez nettoyer manuellement tous les secrets restants.

1. Exécutez la commande suivante pour rechercher les secrets nécessitant un nettoyage :

   kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
   

2. Supprimez chaque secret :

   kubectl delete secret SECRET_NAME
   

   Répétez cette opération pour chaque secret restant.

Vérifier la connectivité multicluster

Cette section explique comment déployer les exemples de services HelloWorld et Sleep dans votre environnement multicluster pour vérifier que l'équilibrage de charge interclusters fonctionne.

Remarque : Ces exemples de services se trouvent dans le répertoire samples inclus dans le fichier tar istioctl (situé dans OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) et non dans le répertoire samples téléchargé par asmcli (situé dans OUTPUT_DIR/samples).

Définir une variable pour le répertoire d'exemples

1. Accédez à l'emplacement où asmcli a été téléchargé, puis exécutez la commande suivante pour définir ASM_VERSION.

   export ASM_VERSION="$(./asmcli --version)"
   

2. Définissez un dossier de travail sur les exemples que vous utilisez pour vérifier que l'équilibrage de charge interclusters fonctionne. Les exemples se trouvent dans un sous-répertoire du répertoire --output_dir que vous avez spécifié dans la commande asmcli install. Dans la commande suivante, remplacez OUTPUT_DIR par le répertoire que vous avez spécifié dans --output_dir.

   export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
   

Activer l'injection side-car

1. Créez l'exemple d'espace de noms dans chaque cluster.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
   done
   

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

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

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

   for CTX in ${CTX_1} ${CTX_2}
   do
      kubectl label --context=${CTX} namespace sample \
         istio.io/rev- istio-injection=enabled --overwrite
   done
   

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

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

    for CTX in ${CTX_1} ${CTX_2}
    do
       kubectl label --context=${CTX} namespace sample \
          istio.io/rev- istio-injection=enabled --overwrite
    done
   

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

   1. Exécutez la commande suivante pour localiser les canaux de publication disponibles :

      kubectl -n istio-system get controlplanerevision
      

      Le résultat ressemble à ce qui suit :

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Remarque : Si deux révisions du plan de contrôle apparaissent dans la liste précédente, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans un même cluster.

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

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

      for CTX in ${CTX_1} ${CTX_2}
      do
        kubectl label --context=${CTX} namespace sample \
           istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done
      

Installer le service HelloWorld

Remarque : L'exemple du service HelloWorld utilise Docker Hub. Dans un cluster privé, l'environnement d'exécution du conteneur peut extraire les images de conteneur d'Artifact Registry par défaut. L'environnement d'exécution du conteneur ne peut pas extraire des images d'un autre registre d'images de conteneurs sur Internet. Vous pouvez télécharger l'image et la transférer vers Artifact Registry ou utiliser Cloud NAT pour fournir un accès à Internet sortant à certains nœuds privés. Pour en savoir plus, consultez les pages Migrer des conteneurs externes et Créer un cluster privé.

• Créez le service HelloWorld dans les deux clusters :

  kubectl create --context=${CTX_1} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

  kubectl create --context=${CTX_2} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

Déployer HelloWorld v1 et v2 sur chaque cluster

1. Déployez HelloWorld v1 sur CLUSTER_1 et v2 sur CLUSTER_2, ce qui vous permet de vérifier ultérieurement l'équilibrage de charge interclusters :

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. Vérifiez que HelloWorld v1 et v2 sont en cours d'exécution à l'aide des commandes suivantes. Vérifiez que le résultat ressemble à celui-ci :

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

Déployer le service Sleep

1. Déployez le service Sleep sur les deux clusters. Ce pod génère un trafic réseau artificiel à des fins de démonstration :

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. Attendez que le service Sleep démarre dans chaque cluster. Vérifiez que le résultat ressemble à celui-ci :

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

Vérifier l'équilibrage de charge interclusters

Appelez le service HelloWorld plusieurs fois et vérifiez le résultat pour vérifier l'alternance des réponses de v1 et v2 :

1. Appelez le service HelloWorld :

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Le résultat ressemble à ceci :

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. Appelez à nouveau le service HelloWorld :

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Le résultat ressemble à ceci :

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

Félicitations, vous avez vérifié votre équilibreur de charge multicluster déployé sur Cloud Service Mesh !

Maintenir le trafic dans le cluster

Dans certains cas, le comportement par défaut de l'équilibrage de charge interclusters n'est pas souhaitable. Pour que le trafic reste "local au cluster" (c'est-à-dire que le trafic envoyé depuis cluster-a n'atteigne que les destinations de cluster-a), marquez les noms d'hôte ou les caractères génériques comme clusterLocal à l'aide de MeshConfig.serviceSettings.

Par exemple, vous pouvez appliquer le trafic local au cluster pour un service individuel, tous les services d'un espace de noms particulier ou globalement pour tous les services du maillage, comme suit :

par service

serviceSettings:
- settings:
    clusterLocal: true
  hosts:
  - "mysvc.myns.svc.cluster.local"

par espace de noms

serviceSettings:
- settings:
    clusterLocal: true
  hosts:
  - "*.myns.svc.cluster.local"

global

serviceSettings:
- settings:
    clusterLocal: true
  hosts:
  - "*"

Vous pouvez également affiner l'accès aux services en définissant une règle locale globale pour le cluster et en ajoutant des exceptions explicites, qui peuvent être spécifiques ou génériques. Dans l'exemple suivant, tous les services du cluster seront conservés localement, à l'exception de tout service de l'espace de noms myns :

serviceSettings:
- settings:
    clusterLocal: true
  hosts:
  - "*"
- settings:
    clusterLocal: false
  hosts:
  - "*.myns.svc.cluster.local"

Activer le service de cluster local

1. Vérifiez le fichier ConfigMap MeshConfig dans le cluster.

   kubectl get configmap -n istio-system
   

   Vous devriez voir un fichier ConfigMap avec l'un des noms suivants : istio-asm-managed, istio-asm-managed-rapid ou istio-asm-managed-stable.

   Si vous avez migré de l'implémentation ISTIOD vers l'implémentation TRAFFIC_DIRECTOR, vous pouvez voir plusieurs fichiers ConfigMap. Dans ce cas, vous pouvez déterminer le canal en exécutant la commande suivante :

   kubectl get controlplanerevision -n istio-system
   

   Le canal de la révision du plan de contrôle réconcilié est celui que vous souhaitez sélectionner.

2. Mettez à jour le fichier ConfigMap.

   cat <<EOF > config.yaml
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: CONFIGMAP_NAME
     namespace: istio-system
   data:
     mesh: |-
       serviceSettings:
       - settings:
           clusterLocal: true
         hosts:
         - "*"
   EOF
   

   Remplacez CONFIGMAP_NAME par le nom du fichier ConfigMap que vous avez trouvé à l'étape 1, puis mettez à jour le fichier ConfigMap.

   kubectl apply --context=${CTX_1} -f config.yaml
   

3. Vérifiez que la fonctionnalité de cluster local fonctionne comme prévu à l'aide des commandes suivantes. Le résultat de l'appel de HelloWorld avec CTX_1 est semblable à :

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Vous devriez voir Only v1 is response dans le résultat :

   Hello version: v1, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...
   

   Si vous appelez HelloWorld avec CTX_2 :

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Vous devriez voir des réponses alternées de v1 et v2 dans le résultat.

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...
   

Nettoyer le service HelloWorld

Lorsque vous avez terminé la vérification de l'équilibrage de charge, supprimez les services HelloWorld et Sleep de votre cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}