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.
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 :
Vous devez installer la version 1.11 ou une version ultérieure d'Anthos Service Mesh sur les clusters en exécutant la commande
asmcli install
. Vous avez besoin deasmcli
, de l'outilistioctl
et d'exemples queasmcli
télécharge dans le répertoire que vous avez spécifié dans--output_dir
lors de l'exécution deasmcli install
. Si vous devez effectuer la configuration, suivez les étapes décrites dans la section Premiers pas pour effectuer les tâches suivantes :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 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 :
- 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.
- 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.
Le serveur d'API doit être accessible par les autres instances du plan de contrôle Anthos Service Mesh dans le maillage multicluster.
- Assurez-vous que l'accès mondial est activé pour les clusters.
- Vérifiez que l'adresse IP du plan de contrôle d'Anthos Service Mesh a été correctement autorisée via la liste d'autorisation avec le réseau autorisé maître.
Définir des variables de projet et de cluster
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 commandeasmcli install
. Dans la commande suivante, remplacezOUTPUT_DIR
par le répertoire que vous avez spécifié dans--output_dir
, et remplacez ASM_VERSION pour qu'il corresponde à la version d'Anthos Service Mesh, par exemple :1.11.8-asm.4
.export SAMPLES_DIR=OUTPUT_DIR/istio-ASM_VERSION
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}"
S'il s'agit de nouveaux clusters, veillez à récupérer les identifiants de chaque cluster à l'aide des commandes
gcloud
suivantes. Sinon, la variablecontext
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
.
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}"))
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
Pour configurer la découverte des points de terminaison entre les clusters GKE, exécutez la commande asmcli create-mesh
. Cette commande :
- enregistre tous les clusters dans le même parc ;
- configure le réseau maillé pour approuver l'identité de charge de travail du parc ;
- crée des secrets distants.
Vous pouvez spécifier l'URI de chaque cluster ou le chemin d'accès au fichier kubeconfig.
URI des clusters
Dans la commande suivante, remplacez FLEET_PROJECT_ID
par l'ID du projet hôte de parc, et l'URI du cluster par le nom, la zone ou la région, et l'ID de projet de chaque cluster.
Cet exemple n'affiche que deux clusters, mais vous pouvez exécuter la commande pour activer la découverte de points de terminaison sur d'autres clusters, soumise à une limite de services GKE Hub.
./asmcli create-mesh \
FLEET_PROJECT_ID \
${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}
Fichier kubeconfig
Dans la commande suivante, remplacez FLEET_PROJECT_ID
par l'ID du projet hôte de parc etPATH_TO_KUBECONFIG
par le chemin d'accès à chaque fichier kubeconfig
. Cet exemple n'affiche que deux clusters, mais vous pouvez exécuter la commande pour activer la découverte des points de terminaison sur des clusters supplémentaires, jusqu'au nombre maximal de clusters autorisé que vous pouvez ajouter à votre parc.
./asmcli create-mesh \
FLEET_PROJECT_ID \
PATH_TO_KUBECONFIG_1 \
PATH_TO_KUBECONFIG_2
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.
Lorsque vous déployez plusieurs clusters privés, le plan de contrôle Anthos Service Mesh 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.
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)"`
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.
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 le plan de contrôle Anthos Service Mesh de chaque cluster à appeler le plan de contrôle GKE des clusters distants.
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
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'étatmasterGlobalAccessConfig
.
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.
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
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}
Vérifier votre déploiement
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.
Activer l'injection side-car
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.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évisionistiod
, qui suit le préfixeistio.io/rev=
. Dans cet exemple, la valeur estasm-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.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é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
Déployez
HelloWorld v1
surCLUSTER_1
etv2
surCLUSTER_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
Vérifiez que
HelloWorld v1
etv2
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
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
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 :
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 ...
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}