Configurer un maillage multicloud ou hybride

{version_1.0.1 d

Preview — Hybrid and multi-cloud mesh

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment configurer un maillage multicloud ou hybride pour les plates-formes suivantes :

• Hybride: GKE sur Google Cloud et GKE sur VMware (preview)
• Hybride: GKE sur Google Cloud et GKE sur Bare Metal (preview)
• Multicloud : GKE sur Google Cloud et Amazon EKS (bêta)

Avertissement:Contactez l'assistance avant de configurer un maillage multicloud.

Remarque sur la plate-forme:La commande asmcli create-mesh que vous utilisez pour activer la détection de points de terminaison exige que tous les clusters du maillage constituent l'une des combinaisons de plates-formes multicloud/hybrides de la liste précédente. Les autres combinaisons de maillages multicloud ou hybrides sur d'autres plates-formes ne sont pas compatibles. Le maillage de services cloud géré n'est pas compatible avec les réseaux multicloud et maillés hybrides.

Les instructions suivantes vous permettent de configurer deux clusters, mais vous pouvez étendre ce processus pour intégrer autant de clusters que vous le souhaitez dans votre maillage.

Prérequis

• Tous les clusters doivent être enregistrés dans le même projet hôte de parc.
• Tous les clusters GKE doivent se trouver dans une configuration de VPC partagé sur le même réseau.
• L'adresse du plan de contrôle Kubernetes du cluster et l'adresse de la passerelle doivent être accessibles à partir de chaque cluster du maillage. Le projet Google Cloud dans lequel se trouvent les clusters GKE doit être autorisé à créer des types d'équilibrage de charge externe. Nous vous recommandons d'utiliser des réseaux autorisés et des règles de pare-feu VPC pour limiter l'accès.
• Les clusters privés, y compris les clusters privés GKE, ne sont pas compatibles. Si vous utilisez des clusters sur site, y compris GKE sur VMware et GKE sur Bare Metal, l'adresse du plan de contrôle Kubernetes et l'adresse de la passerelle doivent être accessibles à partir des pods des clusters GKE. Nous vous recommandons d'utiliser CloudVPN pour connecter le sous-réseau du cluster GKE au réseau du cluster sur site.
• Si vous utilisez Istio CA, utilisez le même certificat racine personnalisé pour tous les clusters.

Avant de commencer

Dans ce guide, nous partons du principe que vous avez installé Cloud Service Mesh à l'aide de l'outil asmcli. 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. Pour en savoir plus, consultez la page Installer des outils dépendants et valider le cluster pour découvrir comment :

• 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. Pour créer un fichier kubeconfig pour le cluster GKE, vous pouvez exporter l'environnement KUBECONFIG en spécifiant le chemin d'accès complet du fichier sous forme de valeur dans votre terminal, puis générer l'entrée kubeconfig.

Avertissement : N'utilisez que des fichiers kubeconfig provenant de sources fiables. L'utilisation d'un fichier kubeconfig spécialement conçu peut entraîner l'exécution de code malveillant ou l'exposition du fichier. Si vous devez utiliser un fichier kubeconfig non approuvé, inspectez-le soigneusement, comme vous le feriez pour un script shell.

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 des variables d'environnement pour les noms de réseau:

• Par défaut, les clusters GKE portent le nom du réseau de cluster :

  export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK"
  ``````
  

• D'autres clusters utilisent default :

  export NETWORK_2="default"
  ``````
  

Si vous avez installé Cloud Service Mesh sur d'autres clusters avec des valeurs différentes pour --network_id, vous devez transmettre les mêmes valeurs à la valeur NETWORK_2.

Installer la passerelle est-ouest

1. Installez une passerelle dans CLUSTER_1 (votre cluster GKE) dédiée au trafic east-west vers CLUSTER_2 (votre cluster multicloud ou sur site):

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --network ${NETWORK_1}  \
       --revision  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
   

   Notez que cette passerelle est publique par défaut 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.

2. Dans le CLUSTER_2, installez une passerelle dédiée au trafic est-ouest du CLUSTER_1.

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --network ${NETWORK_2} \
       --revision  | \
       ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -
   

Exposer des services

É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.

Exposer des services via la passerelle est-ouest pour chaque cluster

    kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml
    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

Remarque : Pour plus d'informations sur la détection des points de terminaison, reportez-vous à la section Détection de points de terminaison avec plusieurs plans de contrôle.

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

Remarque sur la plate-forme : Ces étapes ne s'appliquent que si vous utilisez un plan de contrôle au sein du cluster. Pour Cloud Service Mesh géré, consultez la section Injecter des proxys side-car ou Appliquer le plan de données géré.

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 tarball 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).

Activer l'injection side-car

Recherchez la valeur du libellé de révision, que vous utiliserez lors des étapes suivantes.

Remarque :Si vos clusters possèdent chacun des versions différentes de Cloud Service Mesh, vous devez exécuter la commande suivante pour chacun d'eux.

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

Le résultat 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

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é.

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

2. 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 !

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}