Déployer une passerelle multicluster externe

Ce document vous guide à travers un exemple pratique pour déployer une passerelle multicluster externe afin d'acheminer le trafic Internet vers une application qui s'exécute dans deux clusters GKE différents.

Les passerelles multiclusters constituent un moyen efficace de gérer le trafic des services déployés sur plusieurs clusters GKE. En utilisant l'infrastructure d'équilibrage de charge mondial de Google, vous pouvez créer un point d'entrée unique pour vos applications, ce qui simplifie la gestion et améliore la fiabilité.

Dans ce tutoriel, vous utiliserez un exemple d'application store pour simuler un scénario réel dans lequel un service d'achats en ligne est détenu et géré par des équipes distinctes, et est déployé sur un parc de clusters GKE partagés.

Cet exemple vous montre comment configurer le routage basé sur le chemin d'accès pour rediriger le trafic vers différents clusters.

Avant de commencer

Les passerelles multiclusters nécessitent une préparation environnementale avant de pouvoir être déployées. Avant de continuer, suivez les étapes décrites dans la section Préparer votre environnement pour les passerelles multiclusters :

  1. Déployez des clusters GKE

  2. Enregistrez vos clusters dans un parc (si ce n'est pas déjà fait).

  3. Activez les contrôleurs de service et de passerelle multiclusters.

Enfin, consultez les limites et les problèmes connus du contrôleur GKE Gateway avant de l'utiliser dans votre environnement.

Passerelle externe multicluster et multirégionale

Dans ce tutoriel, vous allez créer une passerelle multicluster externe qui diffuse du trafic externe vers une application exécutée dans deux clusters GKE.

"store.example.com" est déployé sur deux clusters GKE et exposé à Internet via une passerelle multicluster

Au cours des étapes suivantes, vous allez :

  1. Déployer l'exemple d'application store sur les clusters gke-west-1 et gke-east-1.
  2. Configurer les services sur chaque cluster à exporter dans votre parc (services multiclusters).
  3. Déployer une passerelle multicluster externe et une ressource HTTPRoute sur votre cluster de configuration (gke-west-1).

Une fois les ressources d'application et de passerelle déployées, vous pouvez contrôler le trafic entre les deux clusters GKE à l'aide du routage basé sur le chemin d'accès :

  • Les requêtes adressées à /west sont acheminées vers des pods store dans le cluster gke-west-1.
  • Les requêtes adressées à /east sont acheminées vers des pods store dans le cluster gke-east-1.
  • Les requêtes vers les autres chemins sont acheminées vers l'un des clusters, en fonction de leur état, de leur capacité et de leur proximité avec le client demandeur.

Déployer l'application de démonstration

  1. Créez le déploiement et l'espace de noms store dans les trois clusters déployés dans la section Préparer votre environnement pour les passerelles multiclusters :

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-west-2 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

    Cela a pour effet de déployer les ressources suivantes sur chaque cluster :

    namespace/store created
deployment.apps/store created

    Tous les exemples de cette page utilisent l'application déployée lors de la présente étape. Assurez-vous que l'application est déployée sur les trois clusters avant d'essayer l'une des étapes restantes. Cet exemple n'utilise que les clusters gke-west-1 et gke-east-1. gke-west-2 est utilisé dans un autre exemple.

Services multiclusters

Les services sont la manière dont les pods sont exposés aux clients. Étant donné que le contrôleur GKE Gateway utilise l'équilibrage de charge natif en conteneurs, il n'utilise pas l'équilibrage de charge ClusterIP ou Kubernetes pour atteindre les pods. Le trafic est envoyé directement de l'équilibreur de charge aux adresses IP des pods. Toutefois, les services jouent toujours un rôle essentiel d'identifiant logique pour le regroupement de pods.

Les services multiclusters (MCS) sont une norme d'API pour les services couvrant plusieurs clusters et leur contrôleur GKE qui permettent la découverte des services sur les clusters GKE. Le contrôleur de passerelle multicluster utilise des ressources d'API MCS pour regrouper les pods dans un service adressable sur plusieurs clusters ou couvrant plusieurs clusters.

L'API des services multiclusters définit les ressources personnalisées suivantes :

  • Les ressources ServiceExport sont mappées à un service Kubernetes en exportant les points de terminaison de ce service vers tous les clusters enregistrés dans la Fleet. Lorsqu'un service possède une ressource serviceExport correspondante, cela signifie qu'il peut être traité par une passerelle multicluster.
  • Les ressources ServiceImports sont générées automatiquement par le contrôleur de service multicluster. Les ressources ServiceExport et ServiceImport sont disponibles par paires. Si une ressource de type ServiceExport existe dans le parc, une ressource ServiceImport correspondante est créée pour permettre l'accès au service mappé à l'exportation depuis les clusters.

L'exportation de services fonctionne de la manière suivante : Un service de magasin existe dans gke-west-1 et permet de sélectionner un groupe de pods dans ce cluster. Une ressource ServiceExport est créée dans le cluster, ce qui permet aux pods de gke-west-1 d'être accessibles à partir des autres clusters du parc. La ressource ServiceExport mappe et expose les services ayant le même nom et le même espace de noms que la ressource ServiceExport.

apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store

Le schéma suivant illustre ce qui se passe après un déploiement de ServiceExport. Si une paire ServiceExport et Service existe, le contrôleur de service multicluster déploie une ressource ServiceImport correspondante sur chaque cluster GKE du parc. La ressource ServiceImport est la représentation locale du service store dans chaque cluster. Cela permet au pod client de client dans gke-east-1 d'utiliser ClusterIP ou des services sans adresse IP de cluster pour atteindre les pods store dans gke-west-1. Lorsqu'ils sont utilisés de cette manière, les services multiclusters fournissent un équilibrage de charge est-ouest entre les clusters sans nécessiter de service LoadBalancer interne. Pour utiliser les services multiclusters pour l'équilibrage de charge cluster à cluster, consultez la page Configurer des services multicluster.

Les services multiclusters exportent des services sur un certain nombre de clusters, ce qui permet une communication de cluster à cluster

Les passerelles multiclusters utilisent également les importations de services, mais pas pour l'équilibrage de charge de cluster à cluster. Au lieu de cela, les passerelles utilisent les ressources ServiceImport comme identifiants logiques pour un service existant dans un autre cluster ou s'étendant sur plusieurs clusters. Le fichier HTTPRoute suivant fait référence à une ressource ServiceImport plutôt qu'à une ressource Service. Faire référence à une ressource ServiceImport indique que le trafic est transféré vers un groupe de pods backend qui s'exécutent sur un ou plusieurs clusters.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: multi-cluster-gateway
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080

Le schéma suivant montre comment HTTPRoute achemine le trafic store.example.com vers les pods store sur gke-west-1 et gke-east-1. L'équilibreur de charge les traite comme un seul pool de backends. Si les pods de l'un des clusters deviennent non opérationnels, inaccessibles ou sans trafic, la charge de trafic est répartie entre les pods restants de l'autre cluster. De nouveaux clusters peuvent être ajoutés ou supprimés à l'aide du service store et de ServiceExport. Cette opération ajoute et supprime de manière transparente les pods de backend sans aucune modification explicite de la configuration de routage.

Ressource MCS

Exporter des services

À ce stade, l'application s'exécute sur les deux clusters. Ensuite, vous exposerez et exporterez les applications en déployant des ressources Service et ServiceExport sur chaque cluster.

  1. Appliquez le fichier manifeste suivant au cluster gke-west-1 pour créer vos ressources store et store-west-1 Services et ServiceExport :

    cat << EOF | kubectl apply --context gke-west-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-west-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1
  namespace: store
EOF

  2. Appliquez le fichier manifeste suivant au cluster gke-east-1 pour créer vos ressources store et store-east-1 Services et ServiceExport :

    cat << EOF | kubectl apply --context gke-east-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-east-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1
  namespace: store
EOF

  3. Vérifiez que les ressources ServiceExport appropriées ont été créées dans le cluster.

    kubectl get serviceexports --context CLUSTER_NAME --namespace store

    Remplacez CLUSTER_NAME par gke-west-1 et gke-east-1. Le résultat se présente comme suit :

    # gke-west-1
NAME           AGE
store          2m40s
store-west-1   2m40s

# gke-east-1
NAME           AGE
store          2m25s
store-east-1   2m25s

    Le résultat montre que le service store contient des pods store sur les deux clusters, tandis que les services store-west-1 et store-east-1 ne contiennent que des pods store sur leurs clusters respectifs. Ces services qui se chevauchent permettent de cibler les pods de plusieurs clusters ou un sous-ensemble de pods sur un seul cluster.

  4. Après quelques minutes, vérifiez que le ServiceImports associé a bien été créé automatiquement par le contrôleur de services multicluster sur l'ensemble des clusters du parc.

    kubectl get serviceimports --context CLUSTER_NAME --namespace store

    Remplacez CLUSTER_NAME par gke-west-1 et gke-east-1. Le résultat doit ressembler à ceci :

    # gke-west-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.112.31.15"]    6m54s
store-east-1   ClusterSetIP   ["10.112.26.235"]   5m49s
store-west-1   ClusterSetIP   ["10.112.16.112"]   6m54s

# gke-east-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.72.28.226"]    5d10h
store-east-1   ClusterSetIP   ["10.72.19.177"]    5d10h
store-west-1   ClusterSetIP   ["10.72.28.68"]     4h32m

    Cela montre que les trois services sont bien accessibles à partir des deux clusters du parc. Toutefois, comme il n'existe qu'un seul cluster de configuration actif par parc, vous ne pouvez déployer dans gke-west-1 que des passerelles et des routes HTTP qui font référence à ces ressources ServiceImport. Lorsqu'une ressource HTTPRoute dans le cluster de configuration fait référence à ces objets ServiceImport en tant que backends, la passerelle peut transférer le trafic vers ces services, quel que soit le cluster à partir duquel elles sont exportées.

Déployer des ressources Gateway et HTTPRoute

Une fois les applications déployées, vous pouvez configurer une passerelle à l'aide de la GatewayClass gke-l7-global-external-managed-mc. Cette passerelle crée un équilibreur de charge d'application externe configuré pour répartir le trafic entre vos clusters cibles.

  1. Appliquez le fichier manifeste Gateway suivant au cluster de configuration, gke-west-1 dans cet exemple :

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  namespace: store
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    Cette configuration de passerelle déploie des ressources d'équilibreur de charge d'application externe avec la convention d'attribution de noms gkemcg1-NAMESPACE-GATEWAY_NAME-HASH.

    Les ressources par défaut créées avec cette configuration sont les suivantes :

    • 1 équilibreur de charge : gkemcg1-store-external-http-HASH
    • 1 adresse IP publique : gkemcg1-store-external-http-HASH
    • 1 règle de transfert : gkemcg1-store-external-http-HASH
    • 2 services de backend :
      • Service de backend 404 par défaut : gkemcg1-store-gw-serve404-HASH
      • Service de backend 500 par défaut : gkemcg1-store-gw-serve500-HASH
    • 1 vérification d'état :
      • Vérification d'état 404 par défaut : gkemcg1-store-gw-serve404-HASH
    • 0 règle de routage (le mappage d'URL est vide)

    À ce stade, toute requête envoyée à GATEWAY_IP:80 génère une page par défaut affichant le message suivant : fault filter abort.

  2. Appliquez le fichier manifeste HTTPRoute suivant au cluster de configuration, gke-west-1 dans cet exemple :

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: public-store-route
  namespace: store
  labels:
    gateway: external-http
spec:
  hostnames:
  - "store.example.com"
  parentRefs:
  - name: external-http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-east-1
        port: 8080
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080
EOF

    À ce stade, toute requête envoyée à GATEWAY_IP:80 génère une page par défaut affichant le message suivant : fault filter abort.

    Une fois déployé, cet objet HTTPRoute configure le comportement de routage suivant :

    • Les requêtes adressées à /west sont acheminées vers des pods store dans le cluster gke-west-1, car les pods sélectionnés par le ServiceExport store-west-1 n'existent que dans le cluster gke-west-1.
    • Les requêtes adressées à /east sont acheminées vers des pods store dans le cluster gke-east-1, car les pods sélectionnés par le ServiceExport store-east-1 n'existent que dans le cluster gke-east-1.
    • Les requêtes vers les autres chemins sont acheminées vers des pods store dans l'un des clusters, en fonction de leur état, de leur capacité et de leur proximité avec le client demandeur.
    • Les requêtes adressées à GATEWAY_IP:80 génèrent une page par défaut affichant le message suivant : fault filter abort.

    HTTPRoute permet le routage vers différents sous-ensembles de clusters à l&#39;aide de services qui se chevauchent

    Notez que si tous les pods d'un cluster donné ne sont pas opérationnels (ou n'existent pas), le trafic vers le service store n'est envoyé qu'aux clusters comportant effectivement des pods store. L'existence d'une ressource ServiceExport et d'un service sur un cluster donné ne garantit pas que le trafic sera envoyé vers ce cluster. Les pods doivent exister et répondre de manière positive à la vérification de l'état l'équilibreur de charge, sans quoi l'équilibreur de charge enverra simplement le trafic vers les pods store opérationnels dans d'autres clusters.

    Des ressources sont créées avec cette configuration :

    • 3 services de backend :
      • Le service de backend store : gkemcg1-store-store-8080-HASH
      • Le service de backend store-east-1 : gkemcg1-store-store-east-1-8080-HASH
      • Le service de backend store-west-1 : gkemcg1-store-store-west-1-8080-HASH
    • 3 vérifications d'état :
      • La vérification d'état store : gkemcg1-store-store-8080-HASH
      • La vérification d'état store-east-1 : gkemcg1-store-store-east-1-8080-HASH
      • La vérification d'état store-west-1 : gkemcg1-store-store-west-1-8080-HASH
    • 1 règle de routage dans le mappage d'URL :
      • La règle de routage store.example.com :
      • 1 hôte : store.example.com
      • Plusieurs matchRules pour le routage vers les nouveaux services de backend

Le schéma suivant illustre les ressources que vous avez déployées sur les deux clusters. Étant donné que gke-west-1 est le cluster de configuration de passerelle, il s'agit du cluster dans lequel notre passerelle ainsi que nos objets HTTPRoute et nos ressources ServiceImport sont surveillés par le contrôleur de passerelle. Chaque cluster possède une ressource ServiceImport store et une autre ressource ServiceImport spécifique à ce cluster. Les deux pointent vers les mêmes pods. Cela permet au protocole HTTPRoute de spécifier exactement où le trafic doit être acheminé, vers les pods store d'un cluster spécifique ou vers les pods store de tous les clusters.

Il s&#39;agit du modèle de ressource de passerelle et de service multicluster sur les deux clusters

Notez qu'il s'agit d'un modèle de ressource logique, et non d'une représentation du flux de trafic. Le trafic passe directement de l'équilibreur de charge aux pods de backend et n'a pas de relation directe avec le cluster de configuration.

Valider le déploiement

Vous pouvez désormais envoyer des requêtes à notre passerelle multicluster et répartir le trafic sur les deux clusters GKE.

  1. Vérifiez que les ressources Gateway et HTTPRoute ont bien été déployées en inspectant l'état et les événements de la passerelle.

    kubectl describe gateways.gateway.networking.k8s.io external-http --context gke-west-1 --namespace store

    La sortie obtenue devrait ressembler à ceci :

    Name:         external-http
Namespace:    store
Labels:       <none>
Annotations:  networking.gke.io/addresses: /projects/PROJECT_NUMBER/global/addresses/gkemcg1-store-external-http-laup24msshu4
              networking.gke.io/backend-services:
                /projects/PROJECT_NUMBER/global/backendServices/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/backendServices/gke...
              networking.gke.io/firewalls: /projects/PROJECT_NUMBER/global/firewalls/gkemcg1-l7-default-global
              networking.gke.io/forwarding-rules: /projects/PROJECT_NUMBER/global/forwardingRules/gkemcg1-store-external-http-a5et3e3itxsv
              networking.gke.io/health-checks:
                /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-s...
              networking.gke.io/last-reconcile-time: 2023-10-12T17:54:24Z
              networking.gke.io/ssl-certificates:
              networking.gke.io/target-http-proxies: /projects/PROJECT_NUMBER/global/targetHttpProxies/gkemcg1-store-external-http-94oqhkftu5yz
              networking.gke.io/target-https-proxies:
              networking.gke.io/url-maps: /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-store-external-http-94oqhkftu5yz
API Version:  gateway.networking.k8s.io/v1
Kind:         Gateway
Metadata:
  Creation Timestamp:  2023-10-12T06:59:32Z
  Finalizers:
    gateway.finalizer.networking.gke.io
  Generation:        1
  Resource Version:  467057
  UID:               1dcb188e-2917-404f-9945-5f3c2e907b4c
Spec:
  Gateway Class Name:  gke-l7-global-external-managed-mc
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.36.127.249
  Conditions:
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
    Observed Generation:   1
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
      Observed Generation:   1
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
Events:
  Type    Reason  Age                    From                   Message
  ----    ------  ----                   ----                   -------
  Normal  UPDATE  35m (x4 over 10h)      mc-gateway-controller  store/external-http
  Normal  SYNC    4m22s (x216 over 10h)  mc-gateway-controller  SYNC on store/external-http was a success

  2. Une fois la passerelle déployée, récupérez l'adresse IP externe à partir de la passerelle external-http.

    kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}" --context gke-west-1 --namespace store

    Dans les étapes suivantes, remplacez VIP par l'adresse IP que vous recevez en sortie.

  3. Envoyer le trafic vers le chemin racine du domaine. Cela a pour effet d'envoyer le trafic vers la ressource ServiceImport store, qui se trouve sur le cluster gke-west-1 et gke-east-1. L'équilibreur de charge envoie votre trafic vers la région la plus proche de vous et vous risquez de ne pas voir les réponses de l'autre région.

    curl -H "host: store.example.com" http://VIP

    Le résultat confirme que la requête a été diffusée par le pod à partir du cluster gke-east-1 :

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-t2lp.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-dg22z",
  "pod_name_emoji": "⏭",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:32:51"
}

  4. Envoyez ensuite du trafic vers le chemin /west. Cela a pour effet d'acheminer le trafic vers la ressource ServiceImport store-west-1 qui n'a des pods en cours d'exécution que sur le cluster gke-west-1. Une ressource ServiceImport spécifique au cluster telle que store-west-1 permet à un propriétaire d'application d'envoyer explicitement du trafic vers un cluster spécifique, plutôt que de laisser l'équilibreur de charge prendre la décision.

    curl -H "host: store.example.com" http://VIP/west

    Le résultat confirme que la requête a été diffusée par le pod à partir du cluster gke-west-1 :

    {
  "cluster_name": "gke-west-1", 
  "zone": "us-west1-a", 
  "host_header": "store.example.com",
  "node_name": "gke-gke-west-1-default-pool-65059399-2f41.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-d25m5",
  "pod_name_emoji": "🍾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:39:15",
}

  5. Enfin, envoyez le trafic vers le chemin d'accès /east.

    curl -H "host: store.example.com" http://VIP/east

    Le résultat confirme que la requête a été diffusée par le pod à partir du cluster gke-east-1 :

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-7j7z.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-hz6mw",
  "pod_name_emoji": "🧜🏾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:40:48"
}

Effectuer un nettoyage

Après avoir terminé les exercices de ce document, procédez comme suit pour supprimer les ressources afin d'éviter que des frais inutiles ne vous soient facturés sur votre compte :

  1. Supprimer les clusters

  2. Annulez l'enregistrement de vos clusters dans le parc s'ils n'ont pas besoin d'être enregistrés à d'autres fins.

  3. Désactivez la fonctionnalité multiclusterservicediscovery :

    gcloud container fleet multi-cluster-services disable

  4. Désactiver un objet Ingess multicluster

    gcloud container fleet ingress disable

  5. Désactivez les API :

    gcloud services disable \
    multiclusterservicediscovery.googleapis.com \
    multiclusteringress.googleapis.com \
    trafficdirector.googleapis.com \
    --project=PROJECT_ID

Dépannage

Aucun élément opérationnel en amont

Symptôme :

Le problème suivant peut se produire lorsque vous créez une passerelle, mais que vous ne pouvez pas accéder aux services de backend (code de réponse 503) :

no healthy upstream

Explication :

Ce message d'erreur indique que le vérificateur d'état ne parvient pas à trouver des services de backend opérationnels. Il est possible que vos services de backend soient opérationnels, mais que vous deviez personnaliser les vérifications d'état.

Solution :

Pour résoudre ce problème, personnalisez votre vérification d'état en fonction des exigences de votre application (par exemple, /health), à l'aide d'une ressource HealthCheckPolicy.

Étapes suivantes