Configurer un réseau maillé multicluster sur le maillage de services Cloud Service géré

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Istio ne sont pas compatibles avec les API Google Cloud. Pour en savoir plus, consultez Présentation de Cloud Service Mesh

Ce guide explique comment joindre deux clusters en un seul maillage de services Cloud Service Mesh à l'aide de Mesh CA ou Certificate Authority Service et 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.

La configuration multicluster de Cloud Service Mesh peut résoudre plusieurs problèmes essentiels tels que l'évolutivité, 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 clusters GKE Google Cloud répondant aux exigences suivantes :

• Cloud Service Mesh installé sur les clusters Vous devez asmcli, l'outil istioctl et les exemples téléchargés par asmcli dans que vous avez spécifié dans --output_dir.
• Les clusters de votre réseau maillé doivent être connectés entre tous les pods avant que configurer Cloud Service Mesh. De plus, si vous joignez des clusters qui ne se trouvent pas dans pour un même projet, elles doivent être enregistrées projet hôte du parc, Les clusters doivent se trouver dans une configuration de VPC partagé sur le même réseau. Nous vous recommandons également d'avoir un projet pour qui hébergent le VPC partagé, et deux projets de service pour créer des clusters. Pour en savoir plus, consultez la page Configurer des clusters avec un VPC partagé.
• Si vous utilisez Certificate Authority Service, tous les clusters doivent disposer de leur pool d'autorités de certification subordonnées respectifs au sein du même pool d'autorités de certification racine. Sinon, elles devront toutes 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 en savoir plus sur la détection des points de terminaison, consultez Détection de points de terminaison avec plusieurs plans de contrôle.

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

Activez la détection de points de terminaison entre des clusters publics ou privés à l'aide d'une API déclarative

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

Avertissement :N'utilisez pas cette méthode si vos clusters utilisent des ressources de session interne secrets distants

Il s'agit du seul moyen de configurer la détection de points de terminaison multicluster si vous disposez Implémentation du plan de contrôle géré (TD) et la méthode recommandée pour le configurer si vous avez la mise en œuvre de Managed (Istiod) mise en œuvre.

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

Activer

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

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

Si le ConfigMap asm-options n'existe pas encore dans votre cluster, alors le créer avec les données associées et activer la détection des points de terminaison pour 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 sont situés dans le Répertoire Istio samples inclus dans le fichier tar istioctl (situé dans OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples), et non 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 la mise en œuvre du plan de contrôle.

   Géré (TD)

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

   Géré (Istiod)

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

   1. Exécutez la commande suivante pour localiser les versions disponibles:

      kubectl -n istio-system get controlplanerevision
      

      Le résultat ressemble à ce qui suit :

      NAME                AGE
      asm-managed-rapid   6d7h
      

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

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

   2. Appliquez le libellé 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 maillage de services Cloud Service Mesh multicluster à équilibrage de charge !

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}