Configurer un maillage multicluster en dehors de Google Cloud
Ce guide explique comment configurer un maillage multicluster pour les plates-formes suivantes :
- Cloud distribué de Google
- Cloud distribué de Google
- GKE sur Azure
- GKE sur AWS
- Clusters associés, y compris les clusters Amazon EKS et Microsoft AKS
Ce guide explique comment configurer deux clusters, mais vous pouvez étendre ce processus pour intégrer à votre maillage autant de clusters que vous le souhaitez.
Avant de commencer
Dans ce guide, nous partons du principe que vous avez installé Cloud Service Mesh à l'aide de
asmcli install
Vous avez besoin de asmcli
et du package de configuration que asmcli
télécharge dans le répertoire que vous avez spécifié dans --output_dir
lors de l'exécution de asmcli install
.
Si vous devez configurer le cluster, suivez les étapes décrites dans la section Installer les outils dépendants et valider le cluster pour effectuer les opérations suivantes :
- Installer les outils nécessaires
- Télécharger
asmcli
- Accorder des autorisations d'administrateur de cluster
- Valider votre projet et votre cluster
Vous devez accéder aux fichiers kubeconfig de tous les clusters que vous configurez dans le maillage.
Configurer des variables d'environnement et des espaces réservés
Vous avez besoin des variables d'environnement suivantes lorsque vous installez la passerelle est-ouest.
Créez une variable d'environnement pour le numéro de projet. Dans la commande suivante, remplacez FLEET_PROJECT_ID par l'ID du projet hôte du parc.
export PROJECT_NUMBER=$(gcloud projects describe FLEET_PROJECT_ID \ --format="value(projectNumber)")
Créez une variable d'environnement pour l'identifiant de maillage :
export MESH_ID="proj-${PROJECT_NUMBER}"
Créez des variables d'environnement pour les noms de cluster au format requis par
asmcli
.export CLUSTER_1="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_1" export CLUSTER_2="cn-FLEET_PROJECT_ID-global-CLUSTER_NAME_2"
Obtenez les noms de contexte des clusters en utilisant les valeurs de la colonne
NAME
dans le résultat de cette commande :kubectl config get-contexts
Définissez les variables d'environnement sur les noms de contexte des clusters, qui sont utilisés dans de nombreuses étapes ultérieures de ce guide :
export CTX_1=CLUSTER1_CONTEXT_NAME export CTX_2=CLUSTER2_CONTEXT_NAME
Installer la passerelle est-ouest
Dans les commandes suivantes :
Remplacez
CLUSTER_NAME_1
etCLUSTER_NAME_2
par les noms de vos clusters.Remplacez
PATH_TO_KUBECONFIG_1
etPATH_TO_KUBECONFIG_2
par les fichiers kubeconfig de vos clusters.
Clusters Anthos
Mesh CA ou CA Service
Installez dans le cluster1 une passerelle dédiée au trafic est-ouest vers
$CLUSTER_2
. Par défaut, cette passerelle est publique sur Internet. Les systèmes de production peuvent imposer des restrictions d'accès supplémentaires, telles que des règles de pare-feu, pour empêcher les attaques externes.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=kubernetes -f -
Installez dans
$CLUSTER_2
une passerelle dédiée au trafic est-ouest du$CLUSTER_1
.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=kubernetes -f -
Istio CA
Installez dans le cluster1 une passerelle dédiée au trafic est-ouest vers
$CLUSTER_2
. Par défaut, cette passerelle est publique sur Internet. Les systèmes de production peuvent imposer des restrictions d'accès supplémentaires, telles que des règles de pare-feu, pour empêcher les attaques externes.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Installez dans
$CLUSTER_2
une passerelle dédiée au trafic est-ouest du$CLUSTER_1
.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Azure, AWS et connecté
Mesh CA
Installez dans cluster1 une passerelle dédiée à trafic est-ouest à
$CLUSTER_2
. Par défaut, cette passerelle est publique sur Internet. Les systèmes de production peuvent imposer des restrictions d'accès supplémentaires, telles que des règles de pare-feu, pour empêcher les attaques externes.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Installez dans
$CLUSTER_2
une passerelle dédiée au trafic est-ouest du$CLUSTER_1
.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Istio CA
Installez dans cluster1 une passerelle dédiée à trafic est-ouest à
$CLUSTER_2
. Par défaut, cette passerelle est publique sur Internet. Les systèmes de production peuvent imposer des restrictions d'accès supplémentaires, telles que des règles de pare-feu, pour empêcher les attaques externes.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_1} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Installez dans
$CLUSTER_2
une passerelle dédiée au trafic est-ouest du$CLUSTER_1
.asm/istio/expansion/gen-eastwest-gateway.sh \ --mesh ${MESH_ID} \ --cluster ${CLUSTER_2} \ --network default \ --revision asm-1187-26 | \ ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 \ install -y --set spec.values.global.pilotCertProvider=istiod -f -
Services associés
Étant donné que les clusters se trouvent sur des réseaux distincts, vous devez afficher l'ensemble des services (*.local
) sur la passerelle est-ouest des deux clusters. Bien que cette passerelle soit publique sur Internet, les services qui en dépendent ne sont accessibles que par les services disposant d'un certificat mTLS et d'un ID de charge de travail approuvés, comme s'ils se trouvaient sur le même réseau.
Affichez les services via la passerelle est-ouest du
CLUSTER_NAME_1
.kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \ asm/istio/expansion/expose-services.yaml
Affichez les services via la passerelle est-ouest du
CLUSTER_NAME_2
.kubectl --kubeconfig=PATH_TO_KUBECONFIG_2 apply -n istio-system -f \ asm/istio/expansion/expose-services.yaml
Activer la détection des points de terminaison
Exécutez la commande asmcli create-mesh
pour activer la détection des points de terminaison. Cet exemple n'affiche que deux clusters, mais vous pouvez exécuter la commande pour activer la détection des points de terminaison sur d'autres clusters, soumise à une limite de services GKE Hub.
./asmcli create-mesh \
FLEET_PROJECT_ID \
PATH_TO_KUBECONFIG_1 \
PATH_TO_KUBECONFIG_2
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.
Activer l'injection side-car
Recherchez la valeur du libellé de révision, que vous utiliserez lors des étapes suivantes.
Utilisez la commande suivante pour localiser le libellé de révision, que vous utiliserez lors des prochaines étapes.
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.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}')" \ -- /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 ...
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 Cloud Service Mesh multicluster équilibré en charge !
Effectuer un nettoyage
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}