De la périphérie au réseau : déployer les applications d'un maillage de services via GKE Gateway

Last reviewed 2025-04-03 UTC

Ce déploiement explique comment combiner Cloud Service Mesh à Cloud Load Balancing pour exposer les applications d'un maillage de services à des clients Internet.

Vous pouvez exposer une application à des clients de différentes manières selon l'emplacement des clients. Ce déploiement explique comment exposer une application à des clients en associant Cloud Load Balancing à Cloud Service Mesh afin d'intégrer des équilibreurs de charge à un maillage de services. Ce déploiement s'adresse aux professionnels avancés qui utilisent Cloud Service Mesh, mais il fonctionne également pour Istio sur Google Kubernetes Engine.

Architecture

Le schéma suivant montre comment utiliser des passerelles d'entrée de maillage pour intégrer des équilibreurs de charge à un maillage de services :

Un équilibreur de charge externe achemine les clients externes vers le maillage via des proxys de passerelle d'entrée.

L'entrée cloud fait office de passerelle pour le trafic externe vers le maillage via le réseau VPC.

Dans la topologie du schéma précédent, la couche d'entrée cloud, programmée via GKE Gateway, récupère le trafic depuis l'extérieur du maillage de services et le dirige vers la couche d'entrée du maillage. La couche d'entrée du maillage dirige ensuite le trafic vers les backends d'application hébergés par le maillage.

Le contrôleur d'entrée cloud vérifie l'état de l'entrée du maillage, tandis que l'entrée de maillage vérifie l'état des backends de l'application.

La topologie précédente implique les considérations suivantes :

  • Entrée cloud : dans cette architecture de référence, vous configurez l'équilibreur de chargeGoogle Cloud via GKE Gateway pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés.
  • Entrée de maillage : dans l'application de maillage, vous effectuez directement les vérifications de l'état des backends afin de pouvoir exécuter l'équilibrage de charge et gérer le trafic localement.

La sécurité est mise en œuvre à l'aide de certificats gérés en dehors du réseau maillé et de certificats internes à l'intérieur du maillage.

Le schéma précédent illustre le chiffrement HTTPS du client vers l'équilibreur de charge Google Cloud , de l'équilibreur de charge vers le proxy d'entrée du maillage, et du proxy d'entrée vers le proxy side-car.

Objectifs

  • Déployer un cluster Google Kubernetes Engine (GKE) sur Google Cloud.
  • Déployer un service Cloud Service Mesh basé sur Istio sur votre cluster GKE.
  • Configurer GKE Gateway pour arrêter le trafic HTTPS public et le diriger vers des applications hébergées par le maillage de services.
  • Déployer l'application Boutique en ligne sur le cluster GKE que vous exposez à des clients sur Internet.

Optimisation des coûts

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

Vous pouvez obtenir 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, supprimez les ressources que vous avez créées pour éviter que des frais vous soient facturés. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

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

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Vous exécutez toutes les commandes de terminal de ce déploiement depuis Cloud Shell.

  4. Passez à la dernière version de Google Cloud CLI :

    gcloud components update
    
  5. Définissez votre projet Google Cloud par défaut :

    export PROJECT=PROJECT
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    

    Remplacez PROJECT par l'ID de projet que vous souhaitez utiliser pour ce déploiement.

  6. Créez un répertoire de travail :

    mkdir -p ${HOME}/edge-to-mesh
    cd ${HOME}/edge-to-mesh
    export WORKDIR=`pwd`
    

    Une fois le déploiement terminé, vous pouvez supprimer le répertoire de travail.

  7. Créer des clusters GKE

    Les fonctionnalités décrites dans ce déploiement nécessitent un cluster GKE version 1.16 ou ultérieure.

    1. Dans Cloud Shell, créez un fichier kubeconfig. Cette étape vous permet de ne pas créer de conflit avec votre fichier kubeconfig (par défaut) existant.

      touch edge2mesh_kubeconfig
      export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
      
    2. Définissez des variables d'environnement pour le cluster GKE :

      export CLUSTER_NAME=edge-to-mesh
      export CLUSTER_LOCATION=us-central1
      
    3. Activez l'API Google Kubernetes Engine :

      gcloud services enable container.googleapis.com
      
    4. Créez un cluster GKE Autopilot :

      gcloud container --project ${PROJECT} clusters create-auto \
      ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
      
    5. Assurez-vous que le cluster est en cours d'exécution :

      gcloud container clusters list
      

      Le résultat ressemble à ce qui suit :

      NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
      edge-to-mesh  us-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
      

    Installer un maillage de services

    Dans cette section, vous configurez le service Cloud Service Mesh géré avec l'API Fleet.

    1. Dans Cloud Shell, activez les API nécessaires :

      gcloud services enable mesh.googleapis.com
      
    2. Activez Cloud Service Mesh sur le parc :

      gcloud container fleet mesh enable
      
    3. Enregistrez le cluster dans le parc :

      gcloud container fleet memberships register ${CLUSTER_NAME} \
        --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME}
      
    4. Appliquez le libellé mesh_id au cluster edge-to-mesh :

      gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
      
    5. Activez la gestion automatique du plan de contrôle et le plan de données géré :

      gcloud container fleet mesh update \
        --management automatic \
        --memberships ${CLUSTER_NAME}
      
    6. Après quelques minutes, vérifiez que l'état du plan de contrôle est ACTIVE :

      gcloud container fleet mesh describe
      

      Le résultat ressemble à ce qui suit :

      ...
      membershipSpecs:
        projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
          mesh:
            management: MANAGEMENT_AUTOMATIC
      membershipStates:
        projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
          servicemesh:
            controlPlaneManagement:
              details:
              - code: REVISION_READY
                details: 'Ready: asm-managed-rapid'
              implementation: TRAFFIC_DIRECTOR
              state: ACTIVE
            dataPlaneManagement:
              details:
              - code: OK
                details: Service is running.
              state: ACTIVE
          state:
            code: OK
            description: 'Revision(s) ready for use: asm-managed-rapid.'
            updateTime: '2023-08-04T02:54:39.495937877Z'
      name: projects/e2m-doc-01/locations/global/features/servicemesh
      resourceState:
        state: ACTIVE
      ...
      

    Déployer GKE Gateway

    Dans les étapes suivantes, vous allez déployer l'équilibreur de charge d'application externe via le GKE Gateway Controller. La ressource GKE Gateway automatise le provisionnement de l'équilibreur de charge et la vérification d'état du backend. De plus, vous utilisez le gestionnaire de certificats pour provisionner et gérer un certificat TLS, et les points de terminaison pour provisionner automatiquement un nom DNS public pour l'application.

    Installer une passerelle d'entrée du maillage de services

    Pour des raisons de sécurité, nous vous recommandons de déployer la passerelle d'entrée dans un espace de noms différent du plan de contrôle.

    1. Dans Cloud Shell, créez un espace de noms ingress-gateway dédié :

      kubectl create namespace ingress-gateway
      
    2. Ajoutez un libellé d'espace de noms à l'espace de noms ingress-gateway :

      kubectl label namespace ingress-gateway istio-injection=enabled
      

      Le résultat ressemble à ce qui suit :

      namespace/ingress-gateway labeled
      

      L'ajout d'un libellé istio-injection=enabled à l'espace de noms ingress-gateway indique à Cloud Service Mesh d'injecter automatiquement des proxys side-car Envoy lors du déploiement d'une application.

    3. Créez un certificat autosigné utilisé par la passerelle d'entrée pour interrompre les connexions TLS entre l'équilibreur de charge Google Cloud (à configurer ultérieurement via GKE Gateway Controller) et la passerelle d'entrée, puis stockez le certificat autosigné en tant que secret Kubernetes :

      openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
       -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
       -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
       -out frontend.endpoints.${PROJECT}.cloud.goog.crt
      
      kubectl -n ingress-gateway create secret tls edge2mesh-credential \
       --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
       --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
      

      Pour plus d'informations sur les exigences liées au certificat de passerelle d'entrée, consultez le guide sur les protocoles de backend sécurisé.

    4. Exécutez les commandes suivantes pour créer le fichier YAML de ressource de passerelle d'entrée :

      mkdir -p ${WORKDIR}/ingress-gateway/base
      cat <<EOF > ${WORKDIR}/ingress-gateway/base/kustomization.yaml
      resources:
        - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
      EOF
      
      mkdir ${WORKDIR}/ingress-gateway/variant
      cat <<EOF > ${WORKDIR}/ingress-gateway/variant/role.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: asm-ingressgateway
      rules:
      - apiGroups: [""]
        resources: ["secrets"]
        verbs: ["get", "watch", "list"]
      EOF
      
      cat <<EOF > ${WORKDIR}/ingress-gateway/variant/rolebinding.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: asm-ingressgateway
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: asm-ingressgateway
      subjects:
        - kind: ServiceAccount
          name: asm-ingressgateway
      EOF
      
      cat <<EOF > ${WORKDIR}/ingress-gateway/variant/service-proto-type.yaml
      apiVersion: v1
      kind: Service
      metadata:
        name: asm-ingressgateway
      spec:
        ports:
        - name: status-port
          port: 15021
          protocol: TCP
          targetPort: 15021
        - name: http
          port: 80
          targetPort: 8080
        - name: https
          port: 443
          targetPort: 8443
          appProtocol: HTTP2
        type: ClusterIP
      EOF
      
      cat <<EOF > ${WORKDIR}/ingress-gateway/variant/gateway.yaml
      apiVersion: networking.istio.io/v1beta1
      kind: Gateway
      metadata:
        name: asm-ingressgateway
      spec:
        servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
          - "*" # IMPORTANT: Must use wildcard here when using SSL, as SNI isn't passed from GFE
          tls:
            mode: SIMPLE
            credentialName: edge2mesh-credential
      EOF
      
      cat <<EOF > ${WORKDIR}/ingress-gateway/variant/kustomization.yaml
      namespace: ingress-gateway
      resources:
      - ../base
      - role.yaml
      - rolebinding.yaml
      patches:
      - path: service-proto-type.yaml
        target:
          kind: Service
      - path: gateway.yaml
        target:
          kind: Gateway
      EOF
      
    5. Appliquez les CRD de passerelle d'entrée :

      kubectl apply -k ${WORKDIR}/ingress-gateway/variant
      
    6. Assurez-vous que tous les déploiements sont opérationnels :

      kubectl wait --for=condition=available --timeout=600s deployment --all -n ingress-gateway
      

      Le résultat ressemble à ce qui suit :

      deployment.apps/asm-ingressgateway condition met
      

    Appliquer une vérification d'état à la passerelle d'entrée du maillage de services

    Lors de l'intégration d'une passerelle d'entrée de maillage de services à un équilibreur de charge d'application Google Cloud , celui-ci doit être configuré pour effectuer des vérifications d'état sur les pods de la passerelle d'entrée. L'objet CRD HealthCheckPolicy fournit une API permettant de configurer cette vérification de l'état.

    1. Dans Cloud Shell, créez le fichier HealthCheckPolicy.yaml :

      cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
      apiVersion: networking.gke.io/v1
      kind: HealthCheckPolicy
      metadata:
        name: ingress-gateway-healthcheck
        namespace: ingress-gateway
      spec:
        default:
          checkIntervalSec: 20
          timeoutSec: 5
          #healthyThreshold: HEALTHY_THRESHOLD
          #unhealthyThreshold: UNHEALTHY_THRESHOLD
          logConfig:
            enabled: True
          config:
            type: HTTP
            httpHealthCheck:
              #portSpecification: USE_NAMED_PORT
              port: 15021
              portName: status-port
              #host: HOST
              requestPath: /healthz/ready
              #response: RESPONSE
              #proxyHeader: PROXY_HEADER
          #requestPath: /healthz/ready
          #port: 15021
        targetRef:
          group: ""
          kind: Service
          name: asm-ingressgateway
      EOF
      
    2. Appliquer la fonctionHealthCheckPolicy:

      kubectl apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
      

    Définir des règles de sécurité

    Cloud Armor fournit une défense contre les attaques DDoS et des règles de sécurité personnalisables que vous pouvez associer à un équilibreur de charge via des ressources Ingress. Dans les étapes suivantes, vous créez une règle de sécurité qui utilise des règles préconfigurées pour bloquer les attaques de script intersites (XSS). Cette règle bloque le trafic correspondant aux signatures d'attaque connues, mais autorise tout autre trafic. Votre environnement peut utiliser des règles différentes en fonction de votre charge de travail.

    1. Dans Cloud Shell, créez une règle de sécurité appelée edge-fw-policy :

      gcloud compute security-policies create edge-fw-policy \
        --description "Block XSS attacks"
      
    2. Créez une règle de sécurité qui utilise les filtres XSS préconfigurés :

      gcloud compute security-policies rules create 1000 \
          --security-policy edge-fw-policy \
          --expression "evaluatePreconfiguredExpr('xss-stable')" \
          --action "deny-403" \
          --description "XSS attack filtering"
      
    3. Créez le fichier GCPBackendPolicy.yaml à associer au service de passerelle d'entrée :

      cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: cloud-armor-backendpolicy
        namespace: ingress-gateway
      spec:
        default:
          securityPolicy: edge-fw-policy
        targetRef:
          group: ""
          kind: Service
          name: asm-ingressgateway
      EOF
      
    4. Appliquez le fichier GCPBackendPolicy.yaml :

      kubectl apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
      

    Configurer l'adressage IP et DNS

    1. Dans Cloud Shell, créez une adresse IP statique globale pour l'équilibreur de chargeGoogle Cloud  :

      gcloud compute addresses create e2m-gclb-ip --global
      

      Cette adresse IP statique est utilisée par la ressource GKE Gateway et permet à l'adresse IP de rester identique, même si l'équilibreur de charge externe est modifié.

    2. Obtenez l'adresse IP statique :

      export GCLB_IP=$(gcloud compute addresses describe e2m-gclb-ip \
      --global --format "value(address)")
      echo ${GCLB_IP}
      

      Pour créer un mappage stable et lisible avec l'adresse IP statique de l'équilibreur de charge de votre application, vous devez disposer d'un enregistrement DNS public. Vous pouvez utiliser le fournisseur DNS de votre choix et l'automatisation de votre choix. Ce déploiement utilise les points de terminaison au lieu de créer une zone DNS gérée. Les points de terminaison offrent un enregistrement DNS géré par Google gratuit pour une adresse IP publique.

    3. Exécutez la commande suivante pour créer le fichier de spécification YAML nommé dns-spec.yaml :

      cat <<EOF > ${WORKDIR}/dns-spec.yaml
      swagger: "2.0"
      info:
        description: "Cloud Endpoints DNS"
        title: "Cloud Endpoints DNS"
        version: "1.0.0"
      paths: {}
      host: "frontend.endpoints.${PROJECT}.cloud.goog"
      x-google-endpoints:
      - name: "frontend.endpoints.${PROJECT}.cloud.goog"
        target: "${GCLB_IP}"
      EOF
      

      La spécification YAML définit l'enregistrement DNS public sous la forme frontend.endpoints.${PROJECT}.cloud.goog, où ${PROJECT} est votre identifiant de projet unique.

    4. Déployez le fichier dns-spec.yaml dans votre projet Google Cloud  :

      gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
      

      Le résultat ressemble à ce qui suit :

      project [e2m-doc-01]...
      Operation "operations/acat.p2-892585880385-fb4a01ad-821d-4e22-bfa1-a0df6e0bf589" finished successfully.
      
      Service Configuration [2023-08-04r0] uploaded for service [frontend.endpoints.e2m-doc-01.cloud.goog]
      

      Maintenant que l'adresse IP et les DNS sont configurés, vous pouvez générer un certificat public pour sécuriser l'interface. Pour l'intégration à GKE Gateway, vous devez utiliser des certificats TLS du gestionnaire de certificats.

    Provisionner un certificat TLS

    Dans cette section, vous allez créer un certificat TLS à l'aide du gestionnaire de certificats et l'associer à un mappage de certificats via une entrée de mappage de certificats. L'équilibreur de charge d'application, configuré via GKE Gateway, utilise le certificat pour fournir des communications sécurisées entre le client et Google Cloud. Une fois créée, l'entrée de mappage de certificat est référencée par la ressource GKE Gateway.

    1. Dans Cloud Shell, activez l'API Certificate Manager :

      gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}
      
    2. Créez le certificat TLS :

      gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \
          --domains="frontend.endpoints.${PROJECT}.cloud.goog"
      
    3. Créez le mappage de certificat :

      gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map
      
    4. Associez le certificat au mappage de certificats avec une entrée de mappage de certificat :

      gcloud --project=${PROJECT} certificate-manager maps entries create edge2mesh-cert-map-entry \
          --map="edge2mesh-cert-map" \
          --certificates="edge2mesh-cert" \
          --hostname="frontend.endpoints.${PROJECT}.cloud.goog"
      

    Déployer la passerelle GKE Gateway et les ressources HTTPRoute

    Dans cette section, vous allez configurer la ressource GKE Gateway qui provisionne l'équilibreur de charge d'application Google Cloud à l'aide de gke-l7-global-external-managed gatewayClass. En outre, vous configurez des ressources HTTPRoute qui acheminent les requêtes vers l'application et effectuent des redirections HTTP vers HTTP(S).

    1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste Gateway sous le nom gke-gateway.yaml :

      cat <<EOF > ${WORKDIR}/gke-gateway.yaml
      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1
      metadata:
        name: external-http
        namespace: ingress-gateway
        annotations:
          networking.gke.io/certmap: edge2mesh-cert-map
      spec:
        gatewayClassName: gke-l7-global-external-managed # gke-l7-gxlb
        listeners:
        - name: http # list the port only so we can redirect any incoming http requests to https
          protocol: HTTP
          port: 80
        - name: https
          protocol: HTTPS
          port: 443
        addresses:
        - type: NamedAddress
          value: e2m-gclb-ip # reference the static IP created earlier
      EOF
      
    2. Appliquez le fichier manifeste Gateway pour créer un objet Gateway appelé external-http :

      kubectl apply -f ${WORKDIR}/gke-gateway.yaml
      
    3. Créez le fichier HTTPRoute.yaml par défaut :

      cat << EOF > ${WORKDIR}/default-httproute.yaml
      apiVersion: gateway.networking.k8s.io/v1
      kind: HTTPRoute
      metadata:
        name: default-httproute
        namespace: ingress-gateway
      spec:
        parentRefs:
        - name: external-http
          namespace: ingress-gateway
          sectionName: https
        rules:
        - matches:
          - path:
              value: /
          backendRefs:
          - name: asm-ingressgateway
            port: 443
      EOF
      
    4. Appliquez la valeur par défaut HTTPRoute :

      kubectl apply -f ${WORKDIR}/default-httproute.yaml
      
    5. Créez un fichier HTTPRoute.yaml supplémentaire pour effectuer des redirections HTTP vers HTTP(S) :

      cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
      kind: HTTPRoute
      apiVersion: gateway.networking.k8s.io/v1
      metadata:
        name: http-to-https-redirect-httproute
        namespace: ingress-gateway
      spec:
        parentRefs:
        - name: external-http
          namespace: ingress-gateway
          sectionName: http
        rules:
        - filters:
          - type: RequestRedirect
            requestRedirect:
              scheme: https
              statusCode: 301
      EOF
      
    6. Appliquez la redirection HTTPRoute :

      kubectl apply -f ${WORKDIR}/default-httproute-redirect.yaml
      

      Le rapprochement prend du temps. Exécutez la commande suivante jusqu'à ce que programmed=true :

      kubectl get gateway external-http -n ingress-gateway -w
      

    Installer l'exemple d'application Online Boutique

    1. Dans Cloud Shell, créez un espace de noms onlineboutique dédié :

      kubectl create namespace onlineboutique
      
    2. Ajoutez un libellé à l'espace de noms onlineboutique :

      kubectl label namespace onlineboutique istio-injection=enabled
      

      L'ajout d'un libellé istio-injection=enabled à l'espace de noms onlineboutique indique à Cloud Service Mesh d'injecter automatiquement des proxys side-car Envoy lors du déploiement d'une application.

    3. Téléchargez les fichiers YAML Kubernetespour l'exemple d'application Boutique en ligne :

      curl -LO \
      https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
      
    4. Déployez l'application Boutique en ligne :

      kubectl apply -f kubernetes-manifests.yaml -n onlineboutique
      

      Le résultat ressemble à ce qui suit (y compris des avertissements concernant la définition de demandes et de limites de ressources par défaut dans GKE Autopilot) :

      Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/emailservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
      deployment.apps/emailservice created
      service/emailservice created
      Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/checkoutservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
      deployment.apps/checkoutservice created
      service/checkoutservice created
      Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/recommendationservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
      deployment.apps/recommendationservice created
      service/recommendationservice created
      ...
      
    5. Assurez-vous que tous les déploiements sont opérationnels :

      kubectl get pods -n onlineboutique
      

      Le résultat ressemble à ce qui suit :

      NAME                                     READY   STATUS    RESTARTS   AGE
      adservice-64d8dbcf59-krrj9               2/2     Running   0          2m59s
      cartservice-6b77b89c9b-9qptn             2/2     Running   0          2m59s
      checkoutservice-7668b7fc99-5bnd9         2/2     Running   0          2m58s
      ...
      

      Attendez quelques minutes que le cluster GKE Autopilot provisionne l'infrastructure de calcul nécessaire à la prise en charge de l'application.

    6. Exécutez la commande suivante pour créer le fichier manifeste VirtualService en tant que frontend-virtualservice.yaml :

      cat <<EOF > frontend-virtualservice.yaml
      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: frontend-ingress
        namespace: onlineboutique
      spec:
        hosts:
        - "frontend.endpoints.${PROJECT}.cloud.goog"
        gateways:
        - ingress-gateway/asm-ingressgateway
        http:
        - route:
          - destination:
              host: frontend
              port:
                number: 80
      EOF
      

      VirtualService est créé dans l'espace de noms de l'application (onlineboutique). En règle générale, le propriétaire de l'application choisit et configure le mode de routage du trafic vers l'application frontend afin de déployer VirtualService.

    7. Déployez frontend-virtualservice.yaml dans votre cluster :

      kubectl apply -f frontend-virtualservice.yaml
      
    8. Cliquez sur le lien suivant :

      echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
      

      L'interface de votre boutique en ligne s'affiche.

      Produits affichés sur la page d&#39;accueil de la boutique en ligne.

    9. Pour afficher les détails de votre certificat, cliquez sur Afficher les informations sur le site dans la barre d'adresse de votre navigateur, puis cliquez sur Certificat (valide).

      La visionneuse de certificats affiche les détails du certificat géré, y compris la date d'expiration et l'auteur.

    Vous disposez maintenant d'un équilibreur de charge HTTPS global servant d'interface à votre application hébergée par le maillage de services.

    Effectuer un nettoyage

    Une fois le déploiement terminé, vous pouvez nettoyer les ressources que vous avez créées sur Google Cloud afin qu'elles ne vous soient plus facturées. Vous pouvez soit supprimer entièrement le projet, soit supprimer les ressources du cluster, puis le supprimer.

    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.

    Supprimer les ressources individuelles

    Si vous souhaitez conserver le projet Google Cloud que vous avez utilisé dans ce déploiement, supprimez les différentes ressources :

    1. Dans Cloud Shell, supprimez les ressources HTTPRoute :

      kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml
      kubectl delete -f ${WORKDIR}/default-httproute.yaml
      
    2. Supprimez la ressource GKE Gateway :

      kubectl delete -f ${WORKDIR}/gke-gateway.yaml
      
    3. Supprimez les ressources de certificat TLS (y compris l'entrée de mappage de certificat et son mappage de certificat parent) :

      gcloud --project=${PROJECT} certificate-manager maps entries delete edge2mesh-cert-map-entry --map="edge2mesh-cert-map" --quiet
      gcloud --project=${PROJECT} certificate-manager maps delete edge2mesh-cert-map --quiet
      gcloud --project=${PROJECT} certificate-manager certificates delete edge2mesh-cert --quiet
      
    4. Supprimez l'entrée Endpoints DNS :

      gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
      

      Le résultat ressemble à ce qui suit :

      Are you sure? This will set the service configuration to be deleted, along
      with all of the associated consumer information. Note: This does not
      immediately delete the service configuration or data and can be undone using
      the undelete command for 30 days. Only after 30 days will the service be
      purged from the system.
      
    5. Lorsque vous êtes invité à continuer, saisissez Y.

      Le résultat ressemble à ce qui suit :

      Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
      Operation finished successfully. The following command can describe the Operation details:
       gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
      
    6. Supprimez l'adresse IP statique :

      gcloud compute addresses delete ingress-ip --global
      

      Le résultat ressemble à ce qui suit :

      The following global addresses will be deleted:
      
       - [ingress-ip]
      
    7. Lorsque vous êtes invité à continuer, saisissez Y.

      Le résultat ressemble à ce qui suit :

      Deleted
      [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
      
    8. Supprimez le cluster GKE :

      gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
      

      Le résultat ressemble à ce qui suit :

      The following clusters will be deleted.
      - [edge-to-mesh] in [us-central1]
      
    9. Lorsque vous êtes invité à continuer, saisissez Y.

      Après quelques minutes, le résultat est semblable à celui-ci :

      Deleting cluster edge-to-mesh...done.
      Deleted
      [https://container.googleapis.com/v1/projects/e2m-doc-01/zones/us-central1/clusters/edge-to-mesh].
      

    Étapes suivantes