De la périphérie au réseau : Exposer les applications de maillage de services via GKE Ingress

Last reviewed 2022-09-29 UTC

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

Anthos Service Mesh est un maillage de services géré, basé sur Istio, qui fournit une couche de communication observable, standardisée et à la sécurité renforcée pour les applications. Que vous utilisiez Anthos Service Mesh, Traffic Director ou Istio, un maillage de services fournit une plate-forme de communication globale pour les clients qui communiquent via le maillage. Toutefois, il reste un défi à relever pour connecter des clients situés en dehors du maillage à des applications hébergées dans le maillage.

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

Passerelle d'entrée du réseau maillé

Istio 0.8 a introduit la passerelle d'entrée du maillage, qui fournit un ensemble dédié de proxys dont les ports sont exposés au trafic provenant de l'extérieur du maillage de services. Ces proxys d'entrée du maillage vous permettent de contrôler le comportement d'exposition de la couche 4 séparément du comportement de routage des applications. Les proxys vous permettent également d'appliquer le routage et la règle au trafic externe au réseau maillé avant qu'il n'atteigne un side-car d'application. L'entrée de réseau maillé définit le traitement du trafic lorsqu'il atteint un nœud du maillage, mais les composants externes doivent définir la façon dont le trafic arrive au maillage.

Pour gérer ce trafic externe, vous avez besoin d'un équilibreur de charge externe au maillage. Ce tutoriel utilise Google Cloud Load Balancing provisionné via des ressources GKE Ingress afin d'automatiser le déploiement. L'exemple canonique de cette configuration est un service d'équilibrage de charge externe qui, dans le cas de Google Cloud, déploie un équilibreur de charge TCP/UDP public. Cet équilibreur de charge pointe vers les NodePorts d'un cluster GKE. Ces NodePorts exposent les pods de passerelle d'entrée Istio, qui acheminent le trafic vers les proxys side-car du réseau maillé en aval. Le schéma suivant illustre cette topologie. L'équilibrage de charge pour le trafic privé interne ressemble à cette architecture, à la différence que vous déployez un équilibreur de charge TCP/UDP interne à la place.

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

L'utilisation de l'équilibrage de charge transparent de couche 4 avec une passerelle d'entrée du réseau maillé offre les avantages suivants :

  • Cette configuration simplifie le déploiement de l'équilibreur de charge.
  • L'équilibreur de charge fournit une adresse IP virtuelle (VIP) stable, une vérification d'état et une répartition du trafic fiable en cas de modifications du cluster, d'interruptions de nœud ou de pannes de processus.
  • Toutes les règles de routage, l'arrêt TLS et la règle de trafic sont gérés de façon centralisée dans la passerelle d'entrée du maillage.

GKE Ingress et services

Il existe de nombreuses façons d'accorder l'accès aux applications aux clients situés en dehors du cluster. Le tableau suivant répertorie les primitives Kubernetes disponibles pour le déploiement d'équilibreurs de charge sur Google Cloud. Le type d'équilibreur de charge que vous utilisez pour exposer les applications aux clients dépend principalement du type de client externe ou interne, du type de compatibilité de protocole requis et de la disponibilité du maillage de services sur plusieurs clusters GKE ou sur un seul cluster.

Tous les types d'équilibreurs de charge figurant dans le tableau suivant peuvent exposer les applications hébergées sur un réseau maillé, en fonction du cas d'utilisation.

Ressource GKE Équilibreur de charge basé sur le cloud Caractéristiques
Ingress pour les équilibreurs de charge HTTP(S) externes Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les points de présence périphériques (PoP) de Google

Adresse IP virtuelle publique

À l'échelle globale

Cluster unique
Ingress pour les équilibreurs de charge HTTP(S) internes Équilibreur de charge HTTP(S) interne

Proxys de couche 7 dans un réseau de cloud privé virtuel (VPC)

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique
Service externe LoadBalancer Équilibreur de charge réseau

Direct de la couche 4 aux PoP de Google

Adresse IP virtuelle publique

À l'échelle de la région

Cluster unique
Service LoadBalancer interne Équilibreur de charge TCP/UDP interne

Direct de la couche 4 au réseau de routage VPC

Adresse IP virtuelle privée

À l'échelle de la région

Cluster unique
Ingress multicluster (entrée multicluster externe) Équilibreur de charge HTTP(S) externe

Proxys de couche 7 dans les PoP de Google

Adresse IP virtuelle publique

À l'échelle globale

Multicluster

Bien que l'équilibreur de charge par défaut pour Anthos Service Mesh soit l'équilibreur de charge TCP/UDP externe, ce tutoriel se concentre sur l'équilibreur de charge HTTP(S) externe. L'équilibreur de charge HTTP(S) externe fournit une intégration avec des services de périphérie tels que Identity-Aware Proxy (IAP), Google Cloud Armor et Cloud CDN, ainsi qu'un réseau distribué de proxys de périphérie à l'échelle mondiale. La section suivante décrit l'architecture et les avantages liés à l'utilisation de deux couches d'équilibrage de charge HTTP.

Entrée cloud et entrée du réseau maillé

Le déploiement de l'équilibrage de charge de couche 7 externe en dehors du maillage avec une couche d'entrée du maillage offre des avantages considérables, en particulier pour le trafic Internet. Même si Anthos Service Mesh et les passerelles d'entrée Istio fournissent un routage et une gestion de trafic avancés dans le maillage, certaines fonctions sont mieux adaptées à la périphérie du réseau. L'utilisation de la mise en réseau en périphérie d'Internet via l'équilibreur de charge HTTP(S) externe de Google Cloud peut offrir des avantages significatifs en termes de performances, de fiabilité ou de sécurité par rapport à une entrée basée sur le maillage. En voici quelques exemples :

Cette couche externe de l'équilibrage de charge de couche 7 est appelée entrée cloud, car elle est basée sur des équilibreurs de charge gérés par le cloud et non sur les proxys auto-hébergés utilisés par l'entrée de maillage. La combinaison de l'entrée cloud et de l'entrée de maillage utilise les fonctionnalités complémentaires de l'infrastructure Google Cloud et du maillage. Le schéma suivant montre comment associer l'entrée cloud et l'entrée de maillage afin de créer deux couches d'équilibrage de charge pour le trafic Internet.

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

Dans cette topologie, la couche d'entrée cloud 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.

Topologie d'entrée dans le cloud et dans le réseau maillé

Cette section décrit les rôles complémentaires de chaque couche d'entrée lorsque vous les utilisez conjointement. Ces rôles ne constituent pas des règles concrètes mais plutôt des consignes qui permettent d'exploiter au mieux les avantages de chaque couche. Il existe probablement des variantes de ce modèle, en fonction de votre cas d'utilisation.

  • Entrée cloud. Lorsqu'elle est associée à une entrée de maillage, la couche d'entrée cloud est mieux adaptée à la sécurité périphérique et à l'équilibrage de charge global. Étant donné que la couche d'entrée cloud bénéficie de fonctions intégrées pour la protection contre les attaques DDoS, les pare-feu cloud, l'authentification et les produits de chiffrement en périphérie, cette couche excelle dans l'exécution de ces services en dehors du maillage. La logique de routage est généralement simple à ce niveau, mais elle peut devenir plus complexe pour les environnements multicluster et multirégionaux. En raison de la fonction essentielle des équilibreurs de charge Internet, la couche d'entrée cloud est souvent gérée par une équipe chargée de l'infrastructure qui dispose d'un contrôle exclusif sur l'exposition et la sécurité des applications sur Internet. Ce contrôle rend cette couche moins flexible et dynamique qu'une infrastructure axée sur le développeur, ce qui peut influer sur les personnes auxquelles vous choisissez d'accorder un accès administrateur et sur la manière dont vous procédez pour accorder un tel accès.
  • Entrée de réseau maillé Lorsqu'elle est associée à un objet d'entrée cloud, la couche d'entrée du maillage permet un routage flexible proche de l'application. En raison de sa flexibilité, l'entrée de maillage est préférable à l'entrée cloud pour une logique de routage complexe et pour une visibilité au niveau de l'application. La séparation entre les couches d'entrée permet également aux propriétaires d'applications de contrôler directement cette couche sans affecter les autres équipes. Lorsque vous exposez des applications de maillage de services via un équilibreur de charge de niveau 4 au lieu d'un équilibreur de charge de niveau 7, vous devez interrompre le protocole TLS client sur la couche d'entrée du maillage au sein du maillage afin de sécuriser les applications.

Vérification de l'état

La vérification de l'état peut être compliquée lorsque vous utilisez deux couches d'équilibrage de charge de couche 7. Vous devez configurer chaque équilibreur de charge pour qu'il vérifie l'état de la couche suivante afin de garantir la réception du trafic. La topologie du schéma suivant montre comment l'entrée cloud vérifie l'état des proxys d'entrée du maillage et comment le maillage, en retour, vérifie l'état des backends d'application.

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.

Cette topologie implique les considérations suivantes :

  • Entrée cloud. Dans ce tutoriel, vous allez configurer l'équilibreur de charge Google Cloud via une entrée pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés. Si un proxy de réseau maillé est indisponible, ou si le cluster, le maillage ou la région n'est pas disponible, l'équilibreur de charge de Google Cloud détecte cette condition et n'envoie pas de trafic au proxy de réseau maillé.
  • Entrée de réseau maillé 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.

Sécurité

La topologie précédente implique plusieurs éléments de sécurité. L'un des éléments les plus critiques concerne la configuration du chiffrement et du déploiement des certificats. Ingress pour les équilibreurs de charge HTTP(S) externes s'intègre parfaitement aux certificats gérés par Google. Cette intégration provisionne automatiquement les certificats publics, les associe à un équilibreur de charge, puis renouvelle et effectue la rotation des certificats via l'interface GKE Ingress déclarative. Les clients Internet s'authentifient auprès des certificats publics et se connectent à l'équilibreur de charge externe en tant que premier saut dans le cloud privé virtuel (VPC).

Le saut suivant, situé entre Google Front End (GFE) et le proxy d'entrée du maillage, est chiffré par défaut. Le chiffrement au niveau du réseau entre les GFE et leurs backends est appliqué automatiquement. Toutefois, si vos exigences de sécurité impliquent que le propriétaire de la plate-forme conserve la propriété des clés de chiffrement, vous pouvez activer HTTPS/2 avec chiffrement TLS entre l'entrée du cluster (GFE) et l'entrée de maillage (l'instance de proxy Envoy). Lorsque vous activez HTTP/2 avec le chiffrement TLS pour ce chemin d'accès, vous pouvez utiliser un certificat autosigné ou public pour chiffrer le trafic, car le GFE ne s'authentifie pas auprès de celui-ci. Cette couche de chiffrement supplémentaire est décrite dans ce guide. Pour éviter une mauvaise gestion des certificats, ne réutilisez pas le certificat public de l'équilibreur de charge public à un autre endroit. Nous vous recommandons plutôt d'utiliser des certificats distincts dans le maillage de services.

Si le maillage de services exige l'utilisation du protocole TLS, tout le trafic est chiffré entre les proxys side-car et l'entrée de maillage. Le schéma suivant 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.

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.

Objectifs

  • Déployer un cluster Google Kubernetes Engine (GKE) sur Google Cloud.
  • Déployer un service Anthos Service Mesh basé sur Istio sur votre cluster GKE.
  • Configurer GKE Ingress 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.

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

  2. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  3. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

    Vous exécutez toutes les commandes de terminal de ce tutoriel 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 tutoriel.

  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 tutoriel terminé, vous pouvez supprimer le répertoire de travail.

Créer des clusters GKE

Les fonctionnalités décrites dans ce tutoriel 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-west1-a

  3. Activez l'API Google Kubernetes Engine.

    gcloud

    gcloud services enable container.googleapis.com

    Config Connector

    Ce tutoriel inclut les ressources de Config Connector. Vous pouvez utiliser ces ressources pour effectuer les mêmes tâches que celles effectuées dans l'onglet gcloud. Pour utiliser ces ressources, installez Config Connector et appliquez-les de la manière la plus adaptée à votre environnement.

    Utilisez le fichier manifeste Services suivant :

    apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: container.googleapis.com
spec:
  resourceID: container.googleapis.com
  projectRef:
    external: PROJECT

  4. créer un cluster GKE ;

    gcloud

    gcloud container clusters create ${CLUSTER_NAME} \
    --machine-type=e2-standard-4 \
    --num-nodes=4 \
    --zone ${CLUSTER_LOCATION} \
    --enable-ip-alias \
    --workload-pool=${PROJECT}.svc.id.goog \
    --release-channel rapid \
    --addons HttpLoadBalancing \
    --labels mesh_id=proj-${PROJECT_NUMBER}

    Config Connector

    Utilisez les fichiers manifestes ContainerCluster et ContainerNodePool suivants :

    apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  clusterRef:
    name: edge-to-mesh
  location: us-west1-a
  nodeConfig:
    machineType: e2-standard-4
  nodeCount: 4
---
apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
    cnrm.cloud.google.com/remove-default-node-pool: "true"
  labels:
    mesh_id: proj-PROJECT_NUMBER
  name: edge-to-mesh
spec:
  addonsConfig:
    httpLoadBalancing:
      disabled: false
  location: us-west1-a
  initialNodeCount: 1
  releaseChannel:
    channel: RAPID
  workloadIdentityConfig:
    workloadPool: PROJECT.svc.id.goog

    Remplacez PROJECT_NUMBER par la valeur de la variable d'environnement PROJECT_NUMBER récupérée précédemment.

    Pour utiliser une entrée cloud, vous devez activer le module complémentaire d'équilibrage de charge HTTP. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

    Pour utiliser Anthos Service Mesh géré, vous devez appliquer le libellé mesh_id sur le cluster.

  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-west1-a  v1.22.6-gke.300   35.233.195.59  e2-standard-4  v1.22.6-gke.300   4          RUNNING

  6. Connectez-vous au cluster :

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION} \
    --project ${PROJECT}

Installer un maillage de services

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

  1. Activez les API requises :

    gcloud

    gcloud services enable mesh.googleapis.com

    Config Connector

    Utilisez le fichier manifeste Services suivant :

    apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: mesh.googleapis.com
spec:
  resourceID: mesh.googleapis.com
  projectRef:
    external: PROJECT

  2. Activez Anthos Service Mesh dans le parc :

    gcloud

    gcloud container fleet mesh enable

    Config Connector

    Utilisez le fichier manifeste GKEHubFeature suivant :

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeature
metadata:
  name: servicemesh
spec:
  projectRef:
    external: PROJECT
  location: global
  resourceID: servicemesh

  3. Enregistrez le cluster dans le parc :

    gcloud

    gcloud container fleet memberships register ${CLUSTER_NAME} \
    --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME} \
    --enable-workload-identity

    Config Connector

    Utilisez le fichier manifeste GKEHubMembership suivant :

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubMembership
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  location: global
  authority:
    issuer: https://container.googleapis.com/v1/projects/PROJECT/locations/us-west1-a/clusters/edge-to-mesh
  endpoint:
    gkeCluster:
      resourceRef:
        name: edge-to-mesh

  4. Activez la gestion automatique du plan de contrôle et le plan de données géré :

    gcloud

    gcloud container fleet mesh update \
    --management automatic \
    --memberships ${CLUSTER_NAME}

    Config Connector

    Utilisez le fichier manifeste GKEHubFeatureMembership suivant :

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeatureMembership
metadata:
  name: servicemesh-membership
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  membershipRef:
    name: edge-to-mesh
  featureRef:
    name: servicemesh
  mesh:
    management: MANAGEMENT_AUTOMATIC

  5. 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/841956571429/locations/global/memberships/edge-to-mesh:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/841956571429/locations/global/memberships/edge-to-mesh:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-rapid'
        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: '2022-09-29T05:30:28.320896186Z'
name: projects/your-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
...

Déployer GKE Ingress

Dans les étapes suivantes, vous allez déployer l'équilibreur de charge HTTP(S) externe via le contrôleur GKE Ingress. La ressource Ingress automatise le provisionnement de l'équilibreur de charge, de ses certificats TLS et de la vérification de l'état du backend. De plus, vous utilisez Cloud Endpoints pour provisionner automatiquement un nom DNS public pour l'application.

Installer une passerelle d'entrée

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 asm-ingress dédié :

    kubectl create namespace asm-ingress

  2. Ajoutez un libellé d'espace de noms à l'espace de noms asm-ingress :

    kubectl label namespace asm-ingress istio-injection=enabled

    Le résultat ressemble à ce qui suit :

    namespace/asm-ingress labeled

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

  3. Exécutez la commande suivante pour créer le fichier manifeste Deployment en tant que ingress-deployment.yaml :

    cat <<EOF > ingress-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        asm: ingressgateway
    spec:
      securityContext:
        fsGroup: 1337
        runAsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      - name: istio-proxy
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - all
          privileged: false
          readOnlyRootFilesystem: true
        image: auto # The image will automatically update each time the pod starts.
        resources:
          limits:
            cpu: 2000m
            memory: 1024Mi
          requests:
            cpu: 100m
            memory: 128Mi
      serviceAccountName: asm-ingressgateway
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  maxReplicas: 5
  minReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: asm-ingressgateway
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: asm-ingressgateway
subjects:
  - kind: ServiceAccount
    name: asm-ingressgateway
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
EOF

    Ce Deployment possède son propre ServiceAccount avec les éléments Role et RoleBinding associés, permettant à la passerelle d'accéder aux certificats.

  4. Déployez ingress-deployment.yaml dans votre cluster pour créer la ressource Deployment :

    kubectl apply -f ingress-deployment.yaml

    Le résultat ressemble à ce qui suit :

    deployment.apps/asm-ingressgateway configured
role.rbac.authorization.k8s.io/asm-ingressgateway configured
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway configured
serviceaccount/asm-ingressgateway created

    Assurez-vous que tous les déploiements sont opérationnels :

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

    Le résultat ressemble à ce qui suit :

    deployment.apps/asm-ingressgateway condition met

  5. Exécutez la commande suivante pour créer le fichier manifeste Service en tant que ingress-service.yaml :

    cat <<EOF > ingress-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
    cloud.google.com/app-protocols: '{"https":"HTTP2"}' # HTTP/2 with TLS encryption
  labels:
    asm: ingressgateway
spec:
  ports:
  # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks
  - name: status-port
    port: 15021
    protocol: TCP
    targetPort: 15021
  # Any ports exposed in Gateway resources should be exposed here.
  - name: http2
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443
  selector:
    asm: ingressgateway
  type: ClusterIP
EOF

    Ce Service comporte les annotations suivantes, qui définissent les paramètres de l'équilibreur de charge Ingress lors de son déploiement :

    • cloud.google.com/backend-config fait référence au nom d'une ressource personnalisée appelée BackendConfig. Le contrôleur Ingress utilise BackendConfig pour définir les paramètres de la ressource Google Cloud BackendService. Utilisez cette ressource à l'étape suivante pour définir des paramètres personnalisés de la vérification d'état de Google Cloud.
    • cloud.google.com/neg: '{"ingress": true}' active les backends Ingress (les proxys d'entrée du maillage, dans ce cas) pour l'équilibrage de charge natif en conteneurs. Pour un équilibrage de charge plus efficace et stable, ces backends utilisent des groupes de points de terminaison du réseau (NEG) plutôt que des groupes d'instances.
    • cloud.google.com/app-protocols: '{"https":"HTTP2"}' demande au GFE de se connecter à la passerelle d'entrée du maillage de services à l'aide de HTTP2 avec TLS, comme décrit dans les sections Entrée pour l'équilibrage de charge HTTP(S) externe et Présentation de l'équilibrage de charge HTTP(S) externe, qui fournit une couche de chiffrement supplémentaire.

  6. Déployez ingress-service.yaml dans votre cluster pour créer la ressource Service :

    kubectl apply -f ingress-service.yaml

    Le résultat ressemble à ce qui suit :

    service/asm-ingressgateway created

Appliquer les paramètres du service de backend

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste BackendConfig sous le nom ingress-backendconfig.yaml :

    cat <<EOF > ingress-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: ingress-backendconfig
  namespace: asm-ingress
spec:
  healthCheck:
    requestPath: /healthz/ready
    port: 15021
    type: HTTP
  securityPolicy:
    name: edge-fw-policy
EOF

    BackendConfig est une définition de ressource personnalisée (CRD, Custom Resource Definition) qui définit les paramètres du backend pour l'équilibrage de charge Ingress. Pour obtenir la liste complète des paramètres de backend et de frontend que vous pouvez configurer via une GKE Ingress, consultez la page Fonctionnalités Ingress.

    Dans ce tutoriel, le fichier manifeste BackendConfig spécifie des vérifications d'état personnalisées pour les proxys d'entrée du maillage. Anthos Service Mesh et Istio exposent leurs vérifications de l'état du proxy side-car sur le port 15021 au chemin /healthz/ready. Des paramètres de vérification d'état personnalisés sont requis, car le port de diffusion (443) des proxys d'entrée du réseau maillé est différent de celui de la vérification d'état (15021). GKE Ingress utilise les paramètres de vérification d'état suivants dans BackendConfig pour configurer les vérifications de l'état de l'équilibreur de charge Google Cloud. Il existe également une règle de sécurité qui protège le trafic de l'équilibrage de charge de différents types d'attaques de réseau.

    • healthCheck.port définit le port qui reçoit une vérification de l'état par l'équilibreur de charge Google Cloud sur l'adresse IP de chaque pod.
    • healthCheck.requestPath définit le chemin HTTP qui reçoit une vérification de l'état sur le port spécifié.
    • type définit le protocole de la vérification de l'état (dans le cas présent, HTTP).
    • securityPolicy.name fait référence au nom d'une règle de sécurité Cloud Armor.

  2. Déployez ingress-backendconfig.yaml dans votre cluster pour créer la ressource BackendConfig :

    kubectl apply -f ingress-backendconfig.yaml

    Le résultat ressemble à ce qui suit :

    backendconfig.cloud.google.com/ingress-backendconfig created

    Les paramètres BackendConfig et les annotations du service asm-ingressgateway ne sont appliqués à un équilibreur de charge Google Cloud qu'une fois la ressource Ingress déployée. Le déploiement Ingress associe toutes ces ressources.

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

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

gcloud

  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"

Config Connector

Utilisez le fichier manifeste ComputeSecurityPolicy suivant :

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSecurityPolicy
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: edge-fw-policy
spec:
  rule:
  - action: allow
    description: "Default rule"
    match:
      versionedExpr: SRC_IPS_V1
      config:
        srcIpRanges:
        - "*"
    priority: 2147483647
  - action: deny-403
    description: "XSS attack filtering"
    match:
      expr:
        expression: "evaluatePreconfiguredExpr('xss-stable')"
    priority: 1000

Le edge-fw-policy a été référencé par ingress-backendconfig à la section précédente. Lorsque la ressource Ingress est déployée, elle associe cette règle de sécurité à l'équilibreur de charge pour protéger les backends du service asm-ingressgateway.

Configurer l'adressage IP et DNS

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

    gcloud

    gcloud compute addresses create ingress-ip --global

    Config Connector

    Utilisez le fichier manifeste ComputeAddress suivant :

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: ingress-ip
spec:
  location: global

    Cette adresse IP statique est utilisée par la ressource Ingress 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 ingress-ip --global --format "value(address)")
echo ${GCLB_IP}

    Pour créer un mappage stable et lisible avec votre adresse IP Ingress, vous devez disposer d'un enregistrement DNS public. Vous pouvez utiliser le fournisseur DNS de votre choix et l'automatisation de votre choix. Ce tutoriel 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 > 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 numéro de projet unique.

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

    gcloud endpoints services deploy dns-spec.yaml

    Le résultat ressemble à ce qui suit :

    Operation finished successfully. The following command can describe the Operation details:
 gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08

Service Configuration [2021-11-14r0] uploaded for service [frontend.endpoints.edge2mesh.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 Ingress. GKE Ingress accepte les certificats gérés par Google en tant que ressources Kubernetes. Cela vous permet de les provisionner via des moyens déclaratifs.

Provisionner un certificat TLS

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste ManagedCertificate sous le nom managed-cert.yaml :

    cat <<EOF > managed-cert.yaml
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: gke-ingress-cert
  namespace: asm-ingress
spec:
  domains:
    - "frontend.endpoints.${PROJECT}.cloud.goog"
EOF

    Ce fichier YAML spécifie que le nom DNS créé via les points de terminaison est utilisé pour provisionner un certificat public. Étant donné que Google gère entièrement le cycle de vie de ces certificats publics, ils sont automatiquement générés et renouvelés régulièrement, sans intervention directe de l'utilisateur.

  2. Déployez le fichier managed-cert.yaml dans votre cluster GKE :

    kubectl apply -f managed-cert.yaml

    Le résultat ressemble à ce qui suit :

    managedcertificate.networking.gke.io/gke-ingress-cert created

  3. Inspectez la ressource ManagedCertificate pour vérifier la progression de la génération du certificat :

    kubectl describe managedcertificate gke-ingress-cert -n asm-ingress

    Le résultat ressemble à ce qui suit :

    Name:         gke-ingress-cert
Namespace:    asm-ingress
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.gke.io/v1","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
API Version:  networking.gke.io/v1
Kind:         ManagedCertificate
Metadata:
  Creation Timestamp:  2020-08-05T20:44:49Z
  Generation:          2
  Resource Version:    1389781
  Self Link:           /apis/networking.gke.io/v1/namespaces/asm-ingress/managedcertificates/gke-ingress-cert
  UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
Spec:
  Domains:
    frontend.endpoints.edge2mesh.cloud.goog
Status:
  Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  Certificate Status:  Provisioning
  Domain Status:
    Domain:  frontend.endpoints.edge2mesh.cloud.goog
    Status:  Provisioning
Events:
  Type    Reason  Age   From                            Message
  ----    ------  ----  ----                            -------
  Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced

    Lorsque le certificat est prêt, la valeur Certificate Status est définie sur Active.

Déployer la ressource Ingress

  1. Dans Cloud Shell, exécutez la commande suivante pour créer le fichier manifeste Ingress sous le nom ingress.yaml :

    cat <<EOF > ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gke-ingress
  namespace: asm-ingress
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
    networking.gke.io/managed-certificates: "gke-ingress-cert"
    kubernetes.io/ingress.class: "gce"
spec:
  defaultBackend:
    service:
      name: asm-ingressgateway
      port:
        number: 443
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: asm-ingressgateway
            port:
              number: 443
EOF

    Ce fichier manifeste définit une ressource Ingress qui associe toutes les ressources précédentes. Le fichier manifeste spécifie les champs suivants :

    • kubernetes.io/ingress.allow-http: "false" désactive le trafic HTTP sur le port 80 de l'équilibreur de charge Google Cloud. Cela empêche efficacement les connexions de clients avec du trafic non chiffré, car le port 443 n'écoute que le protocole HTTPS et le port 80 est désactivé.
    • kubernetes.io/ingress.global-static-ip-name: "ingress-ip" associe l'adresse IP précédemment créée à l'équilibreur de charge. Cette association permet de créer l'adresse IP séparément de l'équilibreur de charge afin de pouvoir la réutiliser séparément du cycle de vie de l'équilibreur de charge.
    • networking.gke.io/managed-certificates: "gke-ingress-cert" associe cet équilibreur de charge à la ressource de certificat SSL géré par Google créée au préalable.

  2. Déployez ingress.yaml dans votre cluster :

    kubectl apply -f ingress.yaml

  3. Inspectez la ressource Ingress pour vérifier la progression du déploiement de l'équilibreur de charge :

    kubectl describe ingress gke-ingress -n asm-ingress

    Le résultat ressemble à ce qui suit :

    ...
Annotations:
  ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
  networking.gke.io/managed-certificates:            gke-ingress-cert
  kubernetes.io/ingress.global-static-ip-name:  ingress-ip
  ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-asm-ingress-asm-ingressgateway-443-228c1881":"HEALTHY"}
  ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
...

    La ressource Ingress est prête lorsque les annotations ingress.kubernetes.io/backends indiquent que les backends sont HEALTHY. Les annotations indiquent également les noms des différentes ressources Google Cloud provisionnées, y compris les services de backend, les certificats SSL et les proxys HTTPS.

Installer le certificat de passerelle d'entrée autosigné

Dans les étapes suivantes, vous allez générer et installer un certificat (en tant que ressource secret Kubernetes) qui permet au GFE d'établir une connexion TLS à la passerelle d'entrée du maillage de services. 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é.

  1. Dans Cloud Shell, créez la clé privée et le certificat à l'aide de openssl :

    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

  2. Créez le Secret dans l'espace de noms asm-ingress:

    kubectl -n asm-ingress create secret tls edge2mesh-credential \
 --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
 --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt

Configurer la passerelle d'entrée pour l'équilibrage de charge externe

Dans les étapes suivantes, vous allez créer une ressource Gateway partagée dans l'espace de noms asm-ingress. Les passerelles appartiennent généralement aux administrateurs de plate-forme ou aux administrateurs réseau. Par conséquent, la ressource Gateway est créée dans l'espace de noms asm-ingress appartenant à l'administrateur de la plate-forme et peut être utilisée dans d'autres espaces de noms via leurs propres entrées VirtualService.

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

    cat <<EOF > ingress-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
    name: asm-ingressgateway
    namespace: asm-ingress
spec:
  selector:
    asm: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
    tls:
      mode: SIMPLE
      credentialName: edge2mesh-credential
EOF

    Notez que vous devez utiliser l'entrée générique * dans le champ hosts du fichier Gateway. GCLB n'utilise pas l'extension SNI pour les backends. L'utilisation du caractère générique permet d'envoyer le paquet chiffré (depuis GCLB) vers la passerelle d'entrée ASM. La passerelle d'entrée ASM déchiffre le paquet et utilise l'en-tête HTTP de l'hôte (dans le paquet déchiffré) pour prendre des décisions de routage (en fonction des entrées VirtualService).

  2. Déployez ingress-gateway.yaml dans votre cluster :

    kubectl apply -f ingress-gateway.yaml

    Le résultat ressemble à ce qui suit :

    gateway.networking.istio.io/asm-ingressgateway created

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é d'espace de noms à l'espace de noms onlineboutique :

    kubectl label namespace onlineboutique istio-injection=enabled

    Le résultat ressemble à ce qui suit :

    namespace/onlineboutique labeled

    L'ajout d'un libellé istio-injection=enabled à l'espace de noms onlineboutique indique à Anthos 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 :

    deployment.apps/frontend created
service/frontend created
service/frontend-external 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-d854d8786-fjb7q                2/2     Running   0          3m
cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
...

  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/v1alpha3
kind: VirtualService
metadata:
  name: frontend-ingress
  namespace: onlineboutique
spec:
  hosts:
  - "frontend.endpoints.${PROJECT}.cloud.goog"
  gateways:
  - asm-ingress/asm-ingressgateway
  http:
  - route:
    - destination:
        host: frontend
        port:
          number: 80
EOF

    Notez que le 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

    Le résultat ressemble à ce qui suit :

    virtualservice.networking.istio.io/frontend-virtualservice created

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

Nettoyer

Une fois que vous avez terminé le tutoriel, 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. Dans la console Google Cloud, 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.

Supprimer les ressources individuelles

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

  1. Supprimez la ressource Ingress :

    kubectl delete -f ingress.yaml

  2. Supprimez le certificat géré :

    kubectl delete -f managed-cert.yaml

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

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

  5. 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]

  6. 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].

  7. Supprimez le cluster GKE :

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION

Étape suivante