Configuration de GKE multicluster sur Anthos Service Mesh

Ce guide explique comment joindre deux clusters dans un seul réseau maillé Anthos Service Mesh à l'aide de Mesh CA ou d'Istio CA, 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 Anthos 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. En outre, vous devez optimiser vos applications pour tirer le meilleur parti d'un maillage de services. Pour en savoir plus, consultez la page Préparer une application pour Anthos Service Mesh.

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 :

• Anthos Service Mesh version 1.6.8 ou supérieure est installé sur les clusters.
  • Si vos clusters se trouvent dans le même projet, consultez la section Présentation de l'installation pour installer ou mettre à niveau les clusters vers la version requise.
  • Si vos clusters se trouvent dans des projets différents, consultez la section Installer et migrer plusieurs projets pour installer ou mettre à niveau vos clusters vers la version requise.
• Si vous joignez des clusters qui ne font pas partie du même projet, ils doivent être installés à l'aide du profil asm-gcp-multiproject et se trouver dans une configuration de 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 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 Istio CA, utilisez le même certificat racine personnalisé pour les deux clusters.
• Si votre service Anthos Service Mesh est basé sur des clusters privés, nous vous recommandons de créer un seul sous-réseau dans le même VPC. Dans le cas contraire, vous devez vous assurer que :
  1. Les plans de contrôle peuvent atteindre les plans de contrôle de cluster privés distants en utilisant les adresses IP privées du cluster.
  2. Vous pouvez ajouter les plages d'adresses IP des plans de contrôle d'appel aux réseaux autorisés des clusters privés distants. Pour plus d'informations, consultez la section Configurer la recherche de points de terminaison entre les clusters privés.

Définir des variables de projet et de cluster

1. Pour plus de commodité, définissez un dossier de travail. Il s'agit du dossier dans lequel vous avez téléchargé et extrait les fichiers Anthos Service Mesh à l'étape préalable (Préparer l'installation d'Anthos Service Mesh).

   export PROJECT_DIR=YOUR_WORKING_FOLDER

2. 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}"
   

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

   gcloud container clusters get-credentials ${CLUSTER_1}
   gcloud container clusters get-credentials ${CLUSTER_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 entre les clusters

Remarque : si vous travaillez sur des clusters privés, reportez-vous plutôt à la page Configurer la recherche de points de terminaison entre les clusters privés.

Configurez la découverte des points de terminaison pour l'équilibrage de charge interclusters à l'aide des commandes suivantes. Cette étape permet d'effectuer les tâches suivantes :

• La commande istioctl crée un secret accordant l'accès au serveur de l'API Kube pour un cluster.
• La commande kubectl applique le secret à un autre cluster afin que le second cluster puisse lire les points de terminaison de service à partir du premier.

Remarque :Ces étapes nécessitent l'outil de ligne de commande istioctl. Consultez la section Télécharger le fichier d'installation pour l'installer.

istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} | \
  kubectl apply -f - --context=${CTX_2}

istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} | \
  kubectl apply -f - --context=${CTX_1}

Remarque : Vous pouvez ajouter d'autres clusters en étendant le modèle présenté dans cette procédure. Par exemple, créez d'autres contextes (un par cluster), puis créez et appliquez d'autres secrets, garantissant ainsi la présence d'un secret entre chaque cluster.

Configurer la recherche de points de terminaison entre les clusters privés

Lorsque vous utilisez des clusters privés, vous devez configurer les adresses IP privées des clusters distants en lieu et place des adresses IP publiques car ces dernières ne sont pas accessibles.

Remarque :Ces étapes nécessitent l'outil de ligne de commande istioctl. Consultez la section Télécharger le fichier d'installation pour l'installer.

1. Enregistrez les secrets avec les adresses IP publiques dans des fichiers temporaires :

   istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} > ${CTX_1}.secret
   

   istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} > ${CTX_2}.secret
   

2. Récupérez les adresses IP privées des clusters privés, puis remplacez les adresses IP publiques par celles-ci dans les secrets des fichiers temporaires :

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
   

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
   

3. Appliquez les nouveaux secrets dans les clusters :

   kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
   

   kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
   

Configurer des réseaux autorisés pour des clusters privés

Ne suivez cette section que si toutes les conditions suivantes s'appliquent à votre maillage :

• Vous utilisez des clusters privés.
• Les clusters n'appartiennent pas au même sous-réseau.
• Les réseaux autorisés sont activés sur les clusters.

Lors du déploiement de plusieurs clusters dans Anthos Service Mesh, le service Istio de chaque cluster doit appeler le plan de contrôle GKE des clusters distants. Pour autoriser le trafic, vous devez ajouter la plage d'adresses des pods du cluster appelant aux réseaux autorisés des clusters distants.

1. Obtenez le bloc CIDR des adresses IP de pod pour chaque cluster :

   POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

   POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

2. Ajoutez les blocs CIDR d'adresses IP des pods des cluster Kubernetes aux clusters distants :

   EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
   

   EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
   

   Pour plus d'informations, consultez la section Créer un cluster avec des réseaux autorisés.

3. Vérifiez que les réseaux autorisés sont à jour :

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

Activer l'accès mondial au plan de contrôle

Ne suivez cette section que si toutes les conditions suivantes s'appliquent à votre maillage :

• Vous utilisez des clusters privés.
• Vous utilisez différentes régions pour les clusters de votre maillage.

Vous devez activer l'accès mondial au plan de contrôle pour autoriser istiod dans chaque cluster à appeler le plan de contrôle GKE des clusters distants.

1. Activer l'accès mondial au plan de contrôle :

   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-global-access
   

   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-global-access
   

2. Vérifiez que l'accès mondial au plan de contrôle est activé :

   gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1}
   

   gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2}
   

   La section privateClusterConfig de la sortie affiche l'état masterGlobalAccessConfig.

Vérifier votre déploiement

Cette section explique comment déployer un exemple de service HelloWorld dans votre environnement multicluster pour vérifier que l'équilibrage de charge interclusters fonctionne.

Activer l'injection side-car

1. Exécutez la commande suivante pour localiser la valeur du libellé de révision à partir du service istiod, que vous utiliserez dans les étapes suivantes.

   Remarque : Si vos clusters ont différentes versions d'Anthos Service Mesh, vous devez exécuter la commande suivante pour chaque cluster.

   kubectl -n istio-system get pods -l app=istiod --show-labels

   La sortie ressemble à ceci :

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586

   Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-173-3. Utilisez la valeur de révision décrite dans les étapes de la section suivante.

Installer le service HelloWorld

Créez l'exemple d'espace de noms et la définition de service dans chaque cluster. Dans la commande suivante, remplacez REVISION par le libellé de révision istiod noté à l'étape précédente.

Important : Si vous utilisez le plan de contrôle géré d'Anthos Service Mesh, remplacez REVISION par asm-managed dans les étapes suivantes.

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

où REVISION est le libellé de révision istiod que vous avez noté précédemment.

Le résultat est :

   label "istio-injection" not found.
   namespace/sample labeled
   

Vous pouvez ignorer label "istio-injection" not found. en toute sécurité

1. Créez le service HelloWorld dans les deux clusters :

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

   kubectl create --context=${CTX_2} \
       -f ${PROJECT_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 ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${PROJECT_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 ${PROJECT_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}')" \
       -- curl -sS helloworld.sample:5000/hello
   

   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}')" \
       -- curl -sS helloworld.sample:5000/hello
   

   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 Anthos Service Mesh !

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}