Créer un maillage de services multicluster sur GKE à l'aide de l'architecture multiréseau à plusieurs plans de contrôle principaux

Last reviewed 2019-10-29 UTC

Ce tutoriel explique comment déployer des applications sur plusieurs clusters Kubernetes en utilisant un maillage de services multicluster Istio. Ce maillage permet aux services qui s'exécutent sur plusieurs clusters Kubernetes de communiquer de manière sécurisée les uns avec les autres. Les clusters Kubernetes peuvent être exécutés n'importe où, même sur des plates-formes cloud différentes, par exemple des clusters Google Kubernetes Engine (GKE) exécutés dans Google Cloud ou un cluster Kubernetes exécuté dans un centre de données sur site.

Ce tutoriel est destiné aux opérateurs qui souhaitent créer un maillage de services sur plusieurs clusters GKE et sur plusieurs réseaux. Vous devez connaître Kubernetes, y compris les services, les déploiements, les entrées, etc. Il est préférable de posséder des connaissances de base sur Istio, mais ce n'est pas obligatoire.

Istio est une mise en œuvre Open Source d'un maillage de services qui vous permet de détecter les services fonctionnant sur les clusters Kubernetes, de vous y connecter en toute sécurité et d'y acheminer des données de manière dynamique. Istio propose également un framework basé sur des règles pour le routage, l'équilibrage de charge, la régulation, la télémétrie, la coupure de circuit, l'authentification et l'autorisation des appels de service au sein du maillage, avec peu ou pas d'impact sur le code de votre application. Lorsqu'Istio est installé dans un cluster Kubernetes, il utilise le registre de services de Kubernetes pour détecter et créer automatiquement un maillage de services (ou microservices) interconnectés, exécutés dans plusieurs clusters GKE. Istio utilise des proxys side-car Envoy qui sont exécutés dans chaque pod pour gérer le routage et la sécurité du trafic entre pods, et pour permettre l'observabilité de l'ensemble des microservices et des charges de travail du cluster.

Les microservices exécutés dans un cluster Kubernetes peuvent avoir besoin de communiquer avec des microservices exécutés dans d'autres clusters Kubernetes. Par exemple, les microservices peuvent avoir besoin de communiquer entre régions, et les propriétaires de microservices ou d'environnements peuvent entretenir leurs propres clusters Kubernetes. Istio vous permet de créer un maillage de services au-delà d'un seul cluster Kubernetes pour inclure des microservices exécutés dans des clusters distants et même des microservices externes exécutés sur des VM en dehors de Kubernetes.

Istio fournit deux configurations principales pour les déploiements multi-clusters :

Dans une configuration à plusieurs plans de contrôle principaux, chaque cluster dispose de sa propre installation de plan de contrôle Istio et chaque plan de contrôle gère son propre maillage de services local. En utilisant les passerelles Istio, une autorité de certification racine commune et la détection automatique de services sur plusieurs clusters GKE, vous configurez un maillage de services logique unique composé des microservices participants sur chaque cluster. De ce fait, chaque cluster gère son propre maillage de services multicluster et tous les accès entrants du cluster passent par la passerelle Istio est-ouest. Cette approche ne nécessite aucune configuration réseau particulière tant que les passerelles Istio est-ouest sont accessibles dans tous les clusters.

Dans ce tutoriel, vous allez déployer Istio dans deux clusters GKE à l'aide de l'architecture à plusieurs plans de contrôle principaux. Pour ce tutoriel, vous utiliserez une application de microservices de démonstration, baptisée Online Boutique, qui est répartie sur deux clusters GKE. Pour connaître le langage de chaque microservice, consultez la page README.

Vous allez construire l'architecture suivante dans un projet Cloud.

Istio est déployé dans deux clusters GKE à l'aide de l'architecture de plans de contrôle multiples.

Dans cette architecture, vous disposez d'un cluster west et d'un cluster central dans deux réseaux (ou VPC) distincts, chacun disposant d'une passerelle Istio est-ouest. Les clusters communiquent avec divers microservices à la fois localement (dans le même cluster) et à distance (dans l'autre cluster).

Objectifs

  • Créer deux clusters GKE, west et central, dans deux régions différentes et deux VPC différents
  • Installer Istio sur les deux clusters GKE, dans une configuration à plusieurs plans de contrôle principaux
  • Installer l'application Online Boutique répartie sur les deux clusters
  • Inspecter le maillage de services dans les deux clusters

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the GKE and Cloud Source Repositories APIs.

    Enable the APIs

    5.

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the GKE and Cloud Source Repositories APIs.

    Enable the APIs

    8.

Configurer votre environnement

Vous exécuterez toutes les commandes de terminal de ce tutoriel à partir de Cloud Shell.

  1. Dans Google Cloud Console, ouvrez Cloud Shell :

    Ouvrir Cloud Shell

  2. Téléchargez les fichiers nécessaires pour ce tutoriel en clonant le dépôt GitHub suivant :

    cd $HOME
git clone https://github.com/GoogleCloudPlatform/istio-multicluster-gke.git

  3. Définissez le dossier du dépôt comme le dossier $WORKDIR à partir duquel vous effectuez toutes les tâches liées à ce tutoriel :

    cd $HOME/istio-multicluster-gke
WORKDIR=$(pwd)

    Vous pourrez supprimer le dossier lorsque vous aurez terminé le tutoriel.

  4. Installez kubectx/kubens :

    git clone https://github.com/ahmetb/kubectx $WORKDIR/kubectx
export PATH=$PATH:$WORKDIR/kubectx

    Ces outils facilitent l'utilisation de plusieurs clusters Kubernetes en modifiant les contextes ou les espaces de noms.

Créer des VPC et des clusters GKE

Dans cette section, vous allez créer deux VPC et deux clusters GKE, un dans chaque VPC. Vous avez besoin de deux VPC distincts afin de démontrer qu'aucune configuration réseau supplémentaire n'est nécessaire pour la mise en œuvre d'Istio sur plusieurs réseaux dans une configuration à plusieurs plans de contrôle principaux. Le trafic de service à service entre les clusters circule de manière sécurisée sur Internet. Le routage du trafic sur l'Internet public entre clusters offre les avantages suivants :

  • Il accepte le chevauchement d'adresses IP entre différents clusters. Les adresses IP des nœuds, des pods et des services peuvent se chevaucher entre les clusters.
  • Il ne nécessite aucune connectivité supplémentaire entre les clusters et ne nécessite pas d'appairage ni d'interconnexion, ni de VPN entre les réseaux de cluster.
  • Il permet aux clusters d'exister dans plusieurs environnements. Cela signifie que les clusters peuvent exister dans Google Cloud et dans les centres de données sur site où les opérateurs n'ont pas nécessairement le contrôle des réseaux ou des adresses IP, mais peuvent tout de même devoir se connecter en toute sécurité aux microservices exécutés dans les clusters Kubernetes.

Notez que même dans les clusters, vous pouvez contribuer à sécuriser la communication de service à service entre les clusters en utilisant des connexions basées sur une authentification TLS mutuelle (mTLS). En vérifiant les certificats valides émis par Citadel, ces connexions permettent d'éviter les attaques MITM ("man in the middle").

Vous pouvez utiliser des adresses IP privées pour communiquer entre les clusters. Toutefois, cette approche nécessite un examen plus approfondi de la conception du réseau. Par exemple, vous pouvez inclure un adressage IP sans chevauchement entre tous les clusters participant au maillage multicluster. Vous pouvez également vous assurer que tous les pods peuvent communiquer sur l'espace d'adressage privé (RFC 1918), c'est-à-dire établir des règles de pare-feu adéquates dans un VPC mondial Google Cloud, ou encore dans une interconnexion ou un VPN si vous vous connectez à des réseaux autres que Google Cloud. Dans ce tutoriel, vous allez configurer l'architecture qui met l'accent sur la communication sécurisée de service à service via l'Internet public, ce qui vous offre une plus grande souplesse pour la mise en réseau.

  1. Dans Cloud Shell, créez les VPC :

    gcloud compute networks create vpc-west --subnet-mode=auto
gcloud compute networks create vpc-central --subnet-mode=auto

  2. Définissez la variable KUBECONFIG pour utiliser un nouveau fichier kubeconfig pour ce tutoriel :

    export KUBECONFIG=${WORKDIR}/istio-kubeconfig

  3. Créez deux clusters GKE, l'un nommé west dans la zone us-west2-a du réseau vpc-west et l'autre nommé central dans la zone us-central1-a du réseau vpc-central :

    gcloud container clusters create west --zone us-west2-a \
    --machine-type "e2-standard-2" --disk-size "100" \
    --scopes "https://www.googleapis.com/auth/compute",\
"https://www.googleapis.com/auth/devstorage.read_only",\
"https://www.googleapis.com/auth/logging.write",\
"https://www.googleapis.com/auth/monitoring",\
"https://www.googleapis.com/auth/servicecontrol",\
"https://www.googleapis.com/auth/service.management.readonly",\
"https://www.googleapis.com/auth/trace.append" \
    --num-nodes "4" --network "vpc-west" --async

gcloud container clusters create central --zone us-central1-a \
    --machine-type "e2-standard-2" --disk-size "100" \
    --scopes "https://www.googleapis.com/auth/compute",\
"https://www.googleapis.com/auth/devstorage.read_only",\
"https://www.googleapis.com/auth/logging.write",\
"https://www.googleapis.com/auth/monitoring",\
"https://www.googleapis.com/auth/servicecontrol",\
"https://www.googleapis.com/auth/service.management.readonly",\
"https://www.googleapis.com/auth/trace.append" \
    --num-nodes "4" --network "vpc-central"

  4. Attendez quelques minutes que les deux clusters soient créés. Vérifiez que l'état de chaque cluster est RUNNING :

    gcloud container clusters list

    Le résultat ressemble à ce qui suit :

    NAME     LOCATION       MASTER_VERSION    MASTER_IP        MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
central  us-central1-a  1.17.14-gke.1600  104.197.127.140  e2-standard-2  1.17.14-gke.1600  4          RUNNING
west     us-west2-a     1.17.14-gke.1600  34.94.217.4      e2-standard-2  1.17.14-gke.1600  4          RUNNING

  5. Connectez-vous aux deux clusters pour générer des entrées dans le fichier kubeconfig :

    export PROJECT_ID=$(gcloud info --format='value(config.project)')
gcloud container clusters get-credentials west --zone us-west2-a --project ${PROJECT_ID}
gcloud container clusters get-credentials central --zone us-central1-a --project ${PROJECT_ID}

    Le fichier kubeconfig vous permet de créer une authentification pour les clusters en créant un utilisateur et un contexte pour chaque cluster. Une fois que vous avez créé le fichier kubeconfig, vous pouvez rapidement basculer entre différents contextes pour les clusters.

  6. Renommez les noms de contexte pour plus de commodité à l'aide de kubectx :

    kubectx west=gke_${PROJECT_ID}_us-west2-a_west
kubectx central=gke_${PROJECT_ID}_us-central1-a_central

  7. Attribuez à votre utilisateur Google le rôle cluster-admin pour les deux clusters :

    kubectl create clusterrolebinding user-admin-binding \
    --clusterrole=cluster-admin --user=$(gcloud config get-value account) \
    --context west
kubectl create clusterrolebinding user-admin-binding \
    --clusterrole=cluster-admin --user=$(gcloud config get-value account) \
    --context central

    Ce rôle vous permet d'effectuer des tâches d'administration sur ces clusters.

Configurer les certificats sur les deux clusters

Dans Istio, l'autorité de certification est Citadel. Elle est chargée de signer et de distribuer les certificats à tous les proxys Envoy (proxys side-car de charge de travail, et proxys de passerelles d'entrée, de sortie, et de passerelles est-ouest) dans le maillage de services. Par défaut, Citadel génère un certificat racine autosigné et une clé qu'il utilise ensuite pour signer les certificats de charge de travail. Citadel peut également utiliser un certificat et une clé spécifiés par l'opérateur pour signer les certificats de charge de travail. Dans ce tutoriel, les clusters west et central gèrent des maillages de services distincts, dans lesquels les différents services Citadel signent les charges de travail respectives.

Si vous souhaitez établir une relation de confiance entre les microservices de tous les clusters, les deux certificats de signature Citadel doivent être signés par une autorité de certification racine commune. Les charges de travail ont également besoin d'un fichier de chaîne de certificats pour vérifier la chaîne de confiance de toutes les autorités de certification intermédiaires entre le certificat de signature Citadel et l'autorité de certification racine. Cette configuration est effectuée à l'aide d'un secret dans le cluster Kubernetes. Les fichiers de certificat vous sont fournis dans le cadre de ce tutoriel. Dans votre environnement de production, vous pouvez utiliser les certificats générés par votre système ou votre équipe de sécurité PKI. Par exemple, vous pouvez agir comme votre propre autorité de certification. Le secret créé est utilisé par Citadel et possède les propriétés suivantes :

  • Le secret doit être nommé cacert.
  • Le secret est créé à partir de quatre fichiers de certificat (fournis par le code Istio pour ce tutoriel), qui doivent porter les noms suivants :
    • root-cert.pem contient l'autorité de certification racine. Ce fichier est identique pour les services Citadel dans les clusters west et central. Les deux certificats Citadel sont signés par cette autorité de certification racine.
    • ca-cert.pem et ca-key.pem sont le certificat de signature et la clé privée du service Citadel. Les deux certificats Citadel doivent être signés par l'autorité de certification racine (root-cert.pem). ca-cert.pem permet de signer les charges de travail au sein de chaque cluster.
    • cert-chain.pem correspond à la chaîne de confiance entre les certificats de charge de travail et l'autorité de certification racine. Dans cet exemple, cert-chain.pem contient uniquement le certificat ca-cert.pem. Par conséquent, ces fichiers sont identiques. Ce fichier établit la confiance entre les microservices exécutés dans les clusters.

L'installation par défaut de Citadel définit les options de ligne de commande pour configurer l'emplacement des certificats et des clés en fonction des noms de fichiers et de secrets prédéfinis utilisés dans la commande, c'est-à-dire un secret nommé cacert, un certificat racine dans un fichier nommé root-cert.pem, une clé Citadel dans ca-key.pem, et ainsi de suite.

  1. Dans Cloud Shell, téléchargez Istio :

    cd ${WORKDIR}
export ISTIO_VERSION=1.9.0
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -
cd istio-${ISTIO_VERSION}
export PATH=$PWD/bin:$PATH

  2. Dans Cloud Shell, créez le secret à l'aide des fichiers de certificat appropriés :

    for cluster in $(kubectx)
do
  kubectl --context $cluster create namespace istio-system
  kubectl --context $cluster create secret generic cacerts -n istio-system \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-cert.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-key.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/root-cert.pem \
    --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/cert-chain.pem;
  done

Installer Istio

Dans cette section, vous installez Istio sur les clusters west et central.

  1. Dans Cloud Shell, définissez le réseau par défaut du cluster west.

    kubectl --context=west label namespace istio-system topology.istio.io/network=network1

  2. Créez la configuration Istio pour le cluster west avec une passerelle est-ouest dédiée :

    cd ${WORKDIR}
cat <<EOF > istio-west.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: west
      network: network1
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        label:
          istio: eastwestgateway
          app: istio-eastwestgateway
          topology.istio.io/network: network1
        enabled: true
        k8s:
          env:
            # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
            - name: ISTIO_META_ROUTER_MODE
              value: "sni-dnat"
            # traffic through this gateway should be routed inside the network
            - name: ISTIO_META_REQUESTED_NETWORK_VIEW
              value: network1
          service:
            ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: tls
                port: 15443
                targetPort: 15443
              - name: tls-istiod
                port: 15012
                targetPort: 15012
              - name: tls-webhook
                port: 15017
                targetPort: 15017
EOF

  3. Appliquez la configuration au cluster west :

    istioctl install --context=west -f istio-west.yaml

    Appuyez sur y pour continuer.

  4. Inspectez les déploiements dans l'espace de noms istio-system.

    kubectl --context=west -n istio-system get deployments

    La sortie ressemble à ceci :

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
istio-eastwestgateway   1/1     1            1           2m11s
istio-ingressgateway    1/1     1            1           8m43s
istiod                  1/1     1            1           8m56s

  5. Attendez qu'une adresse IP externe soit attribuée à la passerelle est-ouest :

    kubectl --context=west get svc istio-eastwestgateway -n istio-system

    La sortie ressemble à ceci :

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                           AGE
istio-eastwestgateway   LoadBalancer   10.3.241.43   34.94.214.249   15021:30369/TCP,15443:30988/TCP,15012:31358/TCP,15017:32625/TCP   3m42s

  6. Étant donné que les clusters se trouvent sur des réseaux distincts, vous devez exposer l'ensemble des services (*.local) sur la passerelle est-ouest des deux clusters. Étant donné que la passerelle est-ouest est visible publiquement sur Internet, les services situés derrière elle ne peuvent être accessibles que par des services disposant d'un certificat mTLS de confiance et d'un ID de charge de travail, comme s'ils se trouvaient sur le même réseau.

    kubectl --context=west apply -n istio-system -f \
${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml

  7. Définissez le réseau par défaut du cluster central.

    kubectl --context=central label namespace istio-system topology.istio.io/network=network2

  8. Créez la configuration Istio pour le cluster central avec une passerelle est-ouest dédiée :

    cd ${WORKDIR}
cat <<EOF > istio-central.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      meshID: mesh1
      multiCluster:
        clusterName: central
      network: network2
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        label:
          istio: eastwestgateway
          app: istio-eastwestgateway
          topology.istio.io/network: network2
        enabled: true
        k8s:
          env:
            # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
            - name: ISTIO_META_ROUTER_MODE
              value: "sni-dnat"
            # traffic through this gateway should be routed inside the network
            - name: ISTIO_META_REQUESTED_NETWORK_VIEW
              value: network2
          service:
            ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: tls
                port: 15443
                targetPort: 15443
              - name: tls-istiod
                port: 15012
                targetPort: 15012
              - name: tls-webhook
                port: 15017
                targetPort: 15017
EOF

  9. Appliquez la configuration au cluster central :

    istioctl install --context=central -f istio-central.yaml

    Appuyez sur y pour continuer.

  10. Inspectez les déploiements dans l'espace de noms istio-system.

    kubectl --context=central -n istio-system get deployments

    La sortie ressemble à ceci :

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
istio-eastwestgateway   1/1     1            1           2m11s
istio-ingressgateway    1/1     1            1           8m43s
istiod                  1/1     1            1           8m56s

  11. Attendez qu'une adresse IP externe soit attribuée à la passerelle est-ouest :

    kubectl --context=central get svc istio-eastwestgateway -n istio-system

    La sortie ressemble à ceci :

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                           AGE
istio-eastwestgateway   LoadBalancer   10.3.250.201   35.232.125.62   15021:30810/TCP,15443:31125/TCP,15012:30519/TCP,15017:30743/TCP   37s

  12. Exposez tous les services (*.local) sur la passerelle est-ouest du cluster central.

    kubectl --context=central apply -n istio-system -f \
${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml

Activer la détection de points de terminaison

  1. Installez un secret distant dans le cluster west, afin de permettre l'accès au serveur d'API du cluster central.

    istioctl x create-remote-secret \
--context=central \
--name=central | \
kubectl apply -f - --context=west

  2. Installez un secret distant dans le cluster central afin de permettre l'accès au serveur d'API du cluster west.

    istioctl x create-remote-secret \
--context=west \
--name=west | \
kubectl apply -f - --context=central

Déployer l'application Online Boutique

Dans cette section, vous allez installer l'application Online Boutique sur les deux clusters. Online Boutique comprend 10 microservices écrits dans différents langages de programmation. Vous allez répartir ces microservices entre les clusters central et west, comme illustré dans l'architecture suivante.

Les microservices sont répartis entre les clusters "central" et "west", avec des maillages de services qui se chevauchent. Dans le schéma, le service A

  1. Créez des espaces de noms pour l'application Online Boutique dans les deux clusters :

    kubectl --context central create namespace online-boutique
kubectl --context west create namespace online-boutique

  2. Attribuez un libellé aux espaces de noms pour l'injection automatique du proxy side-car Istio :

    kubectl --context central label namespace online-boutique istio-injection=enabled
kubectl --context west label namespace online-boutique istio-injection=enabled

  3. Déployez l'application Online Boutique sur les clusters west et central :

    kubectl --context central -n online-boutique apply -f $WORKDIR/istio-multi-primary/central
kubectl --context west -n online-boutique apply -f $WORKDIR/istio-multi-primary/west

    L'ensemble des déploiements de l'application Online Boutique nécessitent quelques minutes avant d'être opérationnels.

  4. Attendez que tous les déploiements soient disponibles sur les deux clusters.

    # In central cluster
kubectl --context=central -n online-boutique wait --for=condition=available deployment emailservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment checkoutservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment shippingservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment paymentservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment adservice --timeout=5m
kubectl --context=central -n online-boutique wait --for=condition=available deployment currencyservice --timeout=5m

# In west cluster
kubectl --context=west -n online-boutique wait --for=condition=available deployment frontend --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment recommendationservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment productcatalogservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment cartservice --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment redis-cart --timeout=5m
kubectl --context=west -n online-boutique wait --for=condition=available deployment loadgenerator --timeout=5m

    Le résultat pour l'ensemble des déploiements ressemble à ceci :

    deployment.apps/frontend condition met

Accéder à l'application Online Boutique

Vous pouvez accéder à l'application Online Boutique depuis l'adresse IP publique istio-ingressgatway, à partir de l'un ou l'autre des clusters.

  1. Obtenez l'adresse IP publique du service istio-ingressgateway depuis les deux clusters.

    kubectl --context west get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'
kubectl --context central get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'

    Le résultat affiche l'adresse IP externe.

  2. Copiez et collez l'adresse IP de la passerelle d'entrée Istio à partir de l'un ou l'autre des clusters dans un onglet du navigateur Web, puis actualisez la page. La page d'accueil de l'application Online Boutique s'affiche.

    Page d'accueil de l'application Hipster présentant des photos de différents produits, tels que vélos, appareils photo, machines à écrire, etc.

    Parcourez l'application, consultez différents produits, placez-les dans votre panier, effectuez un achat, etc.

    Vous constatez que l'application Online Boutique est entièrement opérationnelle et qu'elle s'exécute sur deux clusters Kubernetes dans deux environnements.

Surveiller le maillage de services

Vous pouvez utiliser Kiali pour surveiller et visualiser le maillage de services. Kiali est un outil d'observabilité des maillages de services, intégré à l'installation d'Istio.

  1. Déployez Prometheus et Kiali sur le cluster west.

    kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION:0:3}/samples/addons/prometheus.yaml
kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION:0:3}/samples/addons/kiali.yaml

    Si l'installation de Kiali échoue et génère des erreurs, essayez d'exécuter à nouveau la même commande. Des problèmes de synchronisation sont susceptibles de se produire, qui se résolvent lors de la réexécution de la commande.

  2. Assurez-vous que les pods Prometheus et Kiali sont en cours d'exécution :

    kubectl --context west get pods -n istio-system

    La sortie ressemble à ceci :

    kiali-6d5c4bbb64-wpsqx                   1/1     Running   0          72s
prometheus-6d87d85c88-h2cwl              2/2     Running   0          92s

  3. Dans Cloud Shell, exposez Kiali sur le cluster west :

    kubectl --context west port-forward svc/kiali 8080:20001 -n istio-system >> /dev/null &

  4. Ouvrez l'interface Web de Kiali sur le cluster west. Dans Cloud Shell, sélectionnez Aperçu sur le Web, puis Prévisualiser sur le port 8080.

  5. Dans le menu de gauche, sélectionnez Graphique.

  6. Dans la liste déroulante Sélectionner un espace de noms, sélectionnez online-boutique.

  7. Dans le menu situé sous Graphique, sélectionnez Graphique des services.

  8. Si vous le souhaitez, dans le menu Affichage, sélectionnez Animation de trafic pour voir loadgenerator générer du trafic vers votre application.

    Capture d'écran affichant une entrée de service interne avec le symbole d'un cadenas à côté de celle-ci.

Vous avez réussi à installer une application répartie sur plusieurs clusters. Les microservices communiquent en toute sécurité sur les clusters à l'aide de la passerelle Istio est-ouest, avec authentification mTLS. Chaque cluster conserve et contrôle son propre plan de contrôle Istio, évitant ainsi tout point de défaillance unique.

Nettoyer

Une fois que vous avez terminé le tutoriel, nettoyez les ressources que vous avez créées sur Google Cloud pour qu'elles ne vous soient plus facturées à l'avenir. Dans les sections suivantes, nous allons voir comment supprimer ces ressources.

Supprimer le projet

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Réinitialiser kubeconfig

  1. Réinitialisez votre fichier kubeconfig :

    unset KUBECONFIG
rm istio-kubeconfig

Étape suivante