Configurer un réseau maillé hybride

Preview — Hybrid and 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.

Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

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

• Hybride: GKE sur Google Cloud et Google Distributed Cloud (bêta)
• Hybride: GKE sur Google Cloud et Google Distributed Cloud (bêta)

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 externes. 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 tels que Google Distributed Cloud et Google Distributed Cloud, 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

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.

1. 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)")
   

2. Créez une variable d'environnement pour l'identifiant de maillage :

   export MESH_ID="proj-${PROJECT_NUMBER}"
   

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

   Notez que 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 à NETWORK_2.

Installer la passerelle est-ouest

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

   asm/istio/expansion/gen-eastwest-gateway.sh \
       --mesh ${MESH_ID} \
       --network ${NETWORK_1}  \
       --revision asm-1226-2 | \
       ./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 \
       --mesh ${MESH_ID} \
       --network ${NETWORK_2} \
       --revision asm-1226-2 | \
       ./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

Consultez la section Injecter des proxys side-car.