Créer un maillage de services multicluster sur GKE avec une architecture à plan de contrôle partagé dans un VPC unique

Ce tutoriel explique comment déployer des applications sur plusieurs clusters Kubernetes à l'aide d'un maillage de services multicluster Istio. Maillage de services multicluster Istio Un maillage de services multicluster Istio permet aux services qui s'exécutent sur plusieurs clusters Kubernetes de communiquer de façon sécurisée. 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.

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 rupture de circuit, l'authentification et l'autorisation des appels de service dans le 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 interconnectés (ou microservices) exécutés dans le cluster.

Les composants d'Istio peuvent être décrits en termes de plan de données et de plan de contrôle. Le plan de données est responsable de la transmission du trafic réseau dans le maillage, tandis que le plan de contrôle est responsable de la configuration et de la gestion du maillage :

  • Plan de données : Istio participe à la communication des services en injectant un conteneur side-car qui exécute un proxy dans chaque pod des services du maillage. Le side-car exécute un proxy intelligent appelé Envoy, qui fournit sécurité, routage et observabilité aux services.
  • Plan de contrôle : un composant appelé Pilot est chargé de fournir la configuration aux side-cars Envoy. Des certificats sont attribués à chaque service par un composant appelé Citadel.

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 ou environnements, et les propriétaires de microservices 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 :

La configuration à plan de contrôle partagé Istio exploite un plan de contrôle Istio exécuté sur l'un des clusters. Le composant Pilot du plan de contrôle gère la configuration des services sur les clusters locaux et distants, et configure les side-cars Envoy pour tous les clusters. Cette configuration permet d'obtenir un maillage de services Istio unique qui englobe les services exécutés dans plusieurs clusters Kubernetes. Dans une configuration à plan de contrôle partagé, le composant Pilot exécuté dans le cluster de plan de contrôle Istio doit disposer d'un accès via adresse IP à tous les pods en cours d'exécution dans chaque cluster.

Vous pouvez obtenir la connectivité pod à pod via adresse IP entre les clusters de deux façons :

  1. Vous créez tous les clusters dans un réseau plat (par exemple, un VPC unique), avec des règles de pare-feu autorisant la connectivité pod à pod via adresse IP entre les clusters. Des clusters peuvent également être présents dans les réseaux VPN connectés. Dans les deux cas, le pod Pilot du cluster de contrôle peut accéder directement à tous les pods des clusters distants via les adresses IP des pods.
  2. Vos clusters se situent dans plusieurs réseaux et dépendent de mécanismes différents pour que le pod Pilot du cluster de contrôle atteigne les pods des clusters distants. Dans ce scénario, le pod Pilot ne peut pas accéder directement aux autres pods à l'aide des adresses IP des pods. Vous allez donc utiliser des passerelles d'entrée Istio pour établir une connectivité réseau entre les clusters des différents réseaux.

Dans ce tutoriel, vous allez déployer Istio dans deux clusters GKE à l'aide d'une architecture à plan de contrôle partagé dans un réseau VPC unique. Le pod Pilot du cluster de plan de contrôle Istio dispose d'une connectivité directe via adresse IP aux pods exécutés dans le cluster distant. Pour ce tutoriel, vous utiliserez une application de démonstration de microservices à 10 niveaux appelée Online Boutique, qui est répartie sur deux clusters GKE. Les microservices sont écrits dans différents langages de programmation. Pour connaître le langage de chaque microservice, consultez la page README.

Concevez l'architecture suivante dans un projet Google Cloud.

Architecture déployant 10 microservices sur deux clusters.

Dans cette architecture, vous disposez d'un cluster control et d'un cluster remote. Le plan de contrôle Istio est déployé sur le cluster control. 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, control et remote, dans un même VPC
  • Installer Istio en mode multicluster sur les deux clusters GKE, puis déployer le plan de contrôle Istio sur le cluster control
  • Installer l'application Online Boutique répartie sur les deux clusters
  • Inspecter le maillage de services développé dans les deux clusters

Coûts

Ce tutoriel utilise 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é ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Avant de commencer

  1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
  2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  3. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Activer les API GKE and Cloud Source Repositories.

    Activer les API

Configurer votre environnement

Dans ce tutoriel, vous allez exécuter toutes les commandes de terminal à 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 une fois le tutoriel terminé.

  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 clusters GKE

Dans cette section, vous allez créer deux clusters GKE dans le VPC par défaut avec les adresses IP d'alias activées. Les plages d'adresses IP d'alias permettent aux clusters GKE d'attribuer des adresses IP provenant d'un bloc CIDR connu de Google Cloud. Cette configuration permet d'obtenir des adresses IP de pods pouvant être acheminées en mode natif au sein du VPC. Ainsi, les pods de différents clusters disposent d'une connectivité directe via adresse IP.

  1. Dans Cloud Shell, créez deux clusters GKE : un premier cluster appelé control sur lequel le plan de contrôle Istio est installé, et un second cluster appelé remote à ajouter au maillage de services multicluster Istio. Créez les deux clusters dans le VPC par défaut, mais dans des régions différentes.

    gcloud container clusters create control --zone us-west2-a --username "admin" \
        --machine-type "n1-standard-2" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-stackdriver-kubernetes --enable-ip-alias --async
    
    gcloud container clusters create remote --zone us-central1-f --username "admin" \
        --machine-type "n1-standard-2" --disk-size "100" \
        --num-nodes "4" --network "default" --enable-stackdriver-kubernetes --enable-ip-alias
    
  2. 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
    remote   us-central1-f  1.16.15-gke.6000  104.197.183.119  n1-standard-2  1.16.15-gke.6000  4          RUNNING
    control  us-west2-a     1.16.15-gke.6000  34.94.180.21     n1-standard-2  1.16.15-gke.6000  4          RUNNING
    
  3. Définissez la variable KUBECONFIG pour utiliser un nouveau fichier kubeconfig pour ce tutoriel :

    touch ${WORKDIR}/istiokubecfg
    export KUBECONFIG=${WORKDIR}/istiokubecfg
    
  4. 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 control --zone us-west2-a --project ${PROJECT_ID}
    gcloud container clusters get-credentials remote --zone us-central1-f --project ${PROJECT_ID}
    

    Un fichier kubeconfig est utilisé afin de définir l'authentification pour les clusters. Une fois que vous avez créé le fichier kubeconfig, vous pouvez rapidement basculer entre différents contextes pour les clusters.

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

    kubectx control=gke_${PROJECT_ID}_us-west2-a_control
    kubectx remote=gke_${PROJECT_ID}_us-central1-f_remote
    

Configurer le réseau

Dans cette section, vous allez configurer des routes VPC pour fournir aux pods des deux clusters une connectivité directe via adresse IP. Lorsque vous activez les plages d'adresses IP d'alias pour les clusters GKE, deux sous-réseaux secondaires sont créés pour chaque cluster. Le sous-réseau principal est utilisé pour les adresses IP des nœuds, tandis que les deux sous-réseaux secondaires sont utilisés pour les plages CIDR des pods et les adresses IP des services.

  1. Dans Cloud Shell, inspectez les adresses IP secondaires des deux clusters :

    gcloud compute networks subnets describe default --region=us-west2 --format=json | jq '.secondaryIpRanges[]'
    gcloud compute networks subnets describe default --region=us-central1 --format=json | jq '.secondaryIpRanges[]'
    

    Pour le cluster control, le résultat ressemble à celui-ci :

    {
      "ipCidrRange": "10.56.0.0/14",
      "rangeName": "gke-control-pods-47496b0c"
    }
    {
      "ipCidrRange": "10.0.0.0/20",
      "rangeName": "gke-control-services-47496b0c"
    }
    

    Pour le cluster remote, le résultat ressemble à celui-ci :

    {
      "ipCidrRange": "10.0.16.0/20",
      "rangeName": "gke-remote-services-66101313"
    }
    {
      "ipCidrRange": "10.60.0.0/14",
      "rangeName": "gke-remote-pods-66101313"
    }
    
  2. Stockez la plage d'adresses IP de pod des clusters et la plage d'adresses IP principale dans des variables pour une utilisation ultérieure :

    CONTROL_POD_CIDR=$(gcloud container clusters describe control --zone us-west2-a --format=json | jq -r '.clusterIpv4Cidr')
    REMOTE_POD_CIDR=$(gcloud container clusters describe remote --zone us-central1-f --format=json | jq -r '.clusterIpv4Cidr')
    CONTROL_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-west2 --format=json | jq -r '.ipCidrRange')
    REMOTE_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-central1 --format=json | jq -r '.ipCidrRange')
    
  3. Créez une variable de liste pour les deux plages d'adresses IP CIDR :

    ALL_CLUSTER_CIDRS=$CONTROL_POD_CIDR,$REMOTE_POD_CIDR,$CONTROL_PRIMARY_CIDR,$REMOTE_PRIMARY_CIDR
    

    Tous les nœuds doivent pouvoir communiquer entre eux et avec les plages CIDR des pods.

  4. Stockez les tags réseau des nœuds de cluster dans une variable :

    ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --format=json | jq -r '.[].tags.items[0]' | uniq | awk -vORS=, '{ print $1 }' | sed 's/,$/\n/')
    

    Vous utiliserez ces tags réseau ultérieurement dans les règles de pare-feu.

  5. Créez une règle de pare-feu autorisant le trafic entre les nœuds et les plages CIDR des pods des clusters.

    gcloud compute firewall-rules create istio-multicluster-rule \
        --allow=tcp,udp,icmp,esp,ah,sctp \
        --direction=INGRESS \
        --priority=900 \
        --source-ranges="${ALL_CLUSTER_CIDRS}" \
        --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet
    

Installer Istio sur les deux clusters GKE

Dans cette section, vous allez installer et configurer Istio dans une configuration multicluster sur les deux clusters GKE à l'aide de Istio Operator.

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

    cd ${WORKDIR}
    export ISTIO_VER=1.8.2
    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VER} TARGET_ARCH=x86_64 sh -
    

    En production, nous vous recommandons de coder en dur une version de l'application, c'est-à-dire d'utiliser le numéro d'une version connue et testée pour garantir un comportement cohérent.

Un déploiement de maillage de services multicluster nécessite d'établir une relation de confiance entre tous les clusters du maillage. Vous pouvez utiliser une autorité de certification racine commune pour générer des certificats intermédiaires pour les différents clusters. Par défaut, tous les clusters créent des certificats autosignés. Une autorité de certification racine est utilisée par toutes les charges de travail au sein d'un maillage en tant que racine de confiance. Chaque autorité de certification Istio utilise une clé et un certificat de signature CA intermédiaire, signés par l'autorité de certification racine. Lorsque plusieurs autorités de certification Istio existent dans un maillage, cela établit une hiérarchie de confiance entre les autorités de certification. Le dépôt Istio est fourni avec des exemples de certificats que vous n'utilisez qu'à des fins pédagogiques. Dans chaque cluster, vous créez l'espace de noms istio-system et un secret nommé cacrts avec les certificats de cluster que vous avez créés précédemment.

  1. Créez un espace de noms istio-system et un secret cacerts dans les deux clusters GKE :

    kubectl --context control create namespace istio-system
    kubectl --context control create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    kubectl --context remote create namespace istio-system
    kubectl --context remote create secret generic cacerts -n istio-system \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
      --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
    
  2. Créez la configuration Istio pour le cluster control :

    cat <<EOF > ${WORKDIR}/istio_control.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    metadata:
      name: istio-control
    spec:
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: control
          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
              serviceAnnotations:
                cloud.google.com/load-balancer-type: "Internal"
                networking.gke.io/internal-load-balancer-allow-global-access: "true"
              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. Installez le plan de contrôle Istio sur le cluster control :

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context control -f ${WORKDIR}/istio_control.yaml
    

    Saisissez y pour poursuivre l'installation. L'installation d'Istio prend deux à trois minutes.

  4. Vérifiez que tous les déploiements Istio sont en cours d'exécution :

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

    Istio est prêt lorsque tous les pods sont en cours d'exécution ou terminés.

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    istio-eastwestgateway-69b49b9785-f5msp   1/1     Running   0          9m11s
    istio-ingressgateway-5c65f88f66-rdd2r    1/1     Running   0          52m
    istiod-6c56d9cbd8-k9klt                  1/1     Running   0          52m
    
  5. Attendez qu'une adresse IP externe soit attribuée au service istio-eastwestgateway. Inspectez l'adresse IP externe de istio-eastwestgateway :

    kubectl --context control get svc istio-eastwestgateway -n istio-system
    

    Le résultat ressemble à ce qui suit :

    NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                           AGE
    istio-eastwestgateway   LoadBalancer   10.60.7.19   10.168.0.6    15021:31557/TCP,15443:30306/TCP,15012:31791/TCP,15017:32341/TCP   14m
    

    Notez que l'adresse IP externe est une adresse IP d'équilibreur de charge interne. Vous avez besoin d'un équilibreur de charge interne, car les deux clusters sont sur le même VPC et peuvent communiquer via un équilibreur de charge interne.

  6. Exposez le service istiod dans le cluster control à l'aide de la passerelle istio-eastwestgateway et d'une ressource VirtualService. Les proxys Envoy du cluster remote doivent pouvoir communiquer avec le service istiod dans le cluster control. Créez la passerelle et la ressource VirtualService en exécutant la commande suivante :

    kubectl --context control apply -f ${WORKDIR}/istio-1.8.2/samples/multicluster/expose-istiod.yaml
    

    Le résultat ressemble à ce qui suit :

    gateway.networking.istio.io/istiod-gateway created
    virtualservice.networking.istio.io/istiod-vs created
    

    Accordez au plan de contrôle Istio du cluster control l'accès au serveur d'API du cluster remote. Les résultats sont les suivants :

    1. Permet au plan de contrôle d'authentifier les requêtes de connexion à partir des charges de travail exécutées dans le cluster remote. Sans accès au serveur d'API, le plan de contrôle rejette les requêtes.
    2. Active la détection des points de terminaison de service exécutés dans le cluster remote.
  7. Exécutez la commande suivante pour permettre au plan de contrôle Istio du cluster control d'accéder au serveur d'API du cluster remote.

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl x create-remote-secret \
    --context=remote \
    --name=remote | \
    kubectl apply -f - --context=control
    

    Le résultat ressemble à ce qui suit :

    secret/istio-remote-secret-remote created
    

    Dans les étapes suivantes, vous allez configurer le cluster control pour l'autoriser à accéder aux ressources du cluster remote.

    Le plan de contrôle Istio nécessite un accès à tous les clusters du maillage pour détecter les services, les points de terminaison et les attributs des pods. Pour obtenir cet accès, créez un fichier kubeconfig pour le cluster remote ajouté en tant que secret dans le cluster control. Le chart Helm istio-remote crée un compte de service Kubernetes nommé istio-multi dans le cluster remote, avec l'accès minimal requis du contrôle des accès basé sur les rôles. Les étapes suivantes décrivent comment générer le fichier kubeconfig du cluster remote à l'aide des identifiants du compte de service istio-multi.

  8. Obtenez l'adresse de l'équilibreur de charge interne istio-eastwestgateway :

    export DISCOVERY_ADDRESS=$(kubectl --context control -n istio-system get svc istio-eastwestgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    

    Cette adresse est utilisée par les proxys side-car Envoy exécutés dans le cluster remote pour se connecter à istiod dans le cluster control.

  9. Créez la configuration Istio pour le cluster remote :

    cat <<EOF > ${WORKDIR}/istio_remote.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      profile: remote
      values:
        global:
          meshID: mesh1
          multiCluster:
            clusterName: remote
          network: network1
          remotePilotAddress: ${DISCOVERY_ADDRESS}
    EOF
    
  10. Installez Istio sur le cluster remote :

    ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context=remote -f ${WORKDIR}/istio_remote.yaml
    

    Saisissez y pour poursuivre l'installation. L'installation d'Istio prend deux à trois minutes.

  11. Inspectez le déploiement Istio dans le cluster remote :

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

    Le résultat ressemble à ce qui suit :

    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-c68779485-4fpmm   1/1     Running   0          3m50s
    istiod-866555cf49-w6qsx                1/1     Running   0          3m57s
    

    Les deux clusters sont maintenant configurés avec le cluster control, qui fournit le plan de contrôle Istio au cluster remote. Dans la section suivante, vous allez déployer un exemple d'application réparti entre les deux clusters.

Déployer l'application Online Boutique

Dans cette section, vous allez installer l'application Online Boutique sur les deux clusters.

  1. Dans Cloud Shell, créez l'espace de noms online-boutique dans les deux clusters :

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl create namespace online-boutique;
    done
    
  2. Ajoutez un libellé à l'espace de noms online-boutique dans les deux clusters pour l'injection automatique du proxy side-car :

    for cluster in $(kubectx);
    do
        kubectx $cluster;
        kubectl label namespace online-boutique istio-injection=enabled
    done
    

    Cette étape permet de s'assurer que le conteneur side-car Envoy est déployé sur tous les pods créés dans l'espace de noms online-boutique.

  3. Installez les ressources de l'application Online Boutique dans le cluster control :

    kubectl --context control -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/control
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/emailservice created
    deployment.apps/checkoutservice created
    deployment.apps/frontend created
    deployment.apps/paymentservice created
    deployment.apps/productcatalogservice created
    deployment.apps/currencyservice created
    deployment.apps/shippingservice created
    deployment.apps/adservice created
    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    serviceentry.networking.istio.io/currency-provider-external created
    virtualservice.networking.istio.io/frontend created
    serviceentry.networking.istio.io/whitelist-egress-googleapis created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  4. Installez les ressources de l'application Online Boutique dans le cluster remote :

    kubectl --context remote -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/remote
    

    Le résultat ressemble à ce qui suit :

    deployment.apps/loadgenerator created
    deployment.apps/cartservice created
    deployment.apps/recommendationservice created
    service/emailservice created
    service/checkoutservice created
    service/recommendationservice created
    service/frontend created
    service/paymentservice created
    service/productcatalogservice created
    service/cartservice created
    service/currencyservice created
    service/shippingservice created
    service/redis-cart created
    service/adservice created
    
  5. Vérifiez que toutes les charges de travail sont en cours d'exécution dans le cluster control :

    kubectl --context control -n online-boutique get pods
    

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-5db678b487-zs6g9               2/2     Running   0          69s
    checkoutservice-b5b8858c7-djnzk          2/2     Running   0          70s
    currencyservice-954d8c5f-mv7kh           2/2     Running   0          70s
    emailservice-5c5555556b-9jk59            2/2     Running   0          71s
    frontend-6fbb48ffc6-gmnsv                2/2     Running   0          70s
    paymentservice-5684b97df7-l9ccn          2/2     Running   0          70s
    productcatalogservice-55479b967c-vqw6w   2/2     Running   0          70s
    shippingservice-59bd8c7b8c-wln4v         2/2     Running   0          69s
    
  6. Vérifiez que toutes les charges de travail sont en cours d'exécution dans le cluster remote :

    kubectl --context remote -n online-boutique get pods
    

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    cartservice-5db5d5c5f9-vvwgx             2/2     Running   0          63s
    loadgenerator-8bcfd68db-gmlfk            2/2     Running   0          63s
    recommendationservice-859c7c66d5-f2x9m   2/2     Running   0          63s
    

Le résultat des deux étapes précédentes montre que les microservices de l'application Online Boutique sont répartis entre les clusters control et remote.

Accéder à l'application Online Boutique

  1. Dans Cloud Shell, récupérez l'adresse IP de la passerelle d'entrée Istio pour le cluster control :

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

    Le résultat indique l'adresse IP de la passerelle d'entrée Istio.

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

    Page d&#39;accueil de l&#39;application Online Boutique 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 fonctionne sur deux clusters Kubernetes dans deux environnements.

Surveiller le maillage de services

Vous pouvez visualiser le maillage de services à l'aide de Kiali. Kiali est un outil d'observabilité des maillages de services. Pour utiliser Kiali, vous devez installer Prometheus et Kiali sur le cluster control.

  1. Déployez les modules complémentaires Prometheus et Kiali sur le cluster control :

    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-1.8/samples/addons/prometheus.yaml
    kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-1.8/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 control get pods -n istio-system
    

    Le résultat ressemble à ce qui suit :

    kiali-cb9fb9554-x2r5z                    1/1     Running   0          7m46s
    prometheus-6d87d85c88-zv8cr              2/2     Running   0          3m57s
    
  3. Dans Cloud Shell, exposez Kiali sur le cluster control :

    kubectl --context control port-forward svc/kiali 8080:20001 -n istio-system --context control >> /dev/null &
    
  4. Ouvrez l'interface Web de Kiali sur le cluster control. Cliquez sur Aperçu sur le Web, puis sélectionnez Prévisualiser sur le port 8080.

  5. À l'invite de connexion de Kiali, connectez-vous avec le nom d'utilisateur admin et le mot de passe admin.

  6. Dans le menu, sélectionnez Graphique.

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

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

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

    Animation de trafic qui montre &quot;loadgenerator&quot; générant du trafic vers l&#39;application.

L'image précédente illustre un maillage de services partagé Istio pour des microservices répartis sur deux clusters. Quel que soit le cluster, à mesure que de nouveaux microservices sont ajoutés, ils sont automatiquement détectés et ajoutés au maillage. La connectivité au réseau plat permet de disposer de plusieurs clusters tout en facilitant la gestion des microservices via un plan de contrôle partagé.

Effectuer un nettoyage

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. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Réinitialiser kubeconfig

  • Désactivez la variable KUBECONFIG :

    unset KUBECONFIG
    rm ${WORKDIR}/istiokubecfg
    

Étape suivante