Déployer des passerelles multiclusters

Cette page explique comment déployer des ressources Kubernetes Gateway pour l'équilibrage de charge du trafic entrant sur plusieurs clusters Google Kubernetes Engine (GKE) (ou un parc). Avant de déployer des passerelles multiclusters, consultez la page Activer les passerelles multiclusters pour préparer votre environnement.

Pour déployer des passerelles destinées à équilibrer la charge du trafic entrant sur un seul cluster GKE, consultez la page Déployer des passerelles.

Ressources Gateway multiclusters

Une passerelle multicluster est une ressource de passerelle (Gateway) qui équilibre la charge de trafic entre plusieurs clusters Kubernetes. Dans GKE, les ressources GatewayClass gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-rilb-mc et gke-l7-gxlb-mc déploient des passerelles multiclusters qui fournissent un routage HTTP, une répartition du trafic, une mise en miroir du trafic, un basculement basé sur l'état, etc. sur différents clusters GKE et espaces de noms Kubernetes, ainsi que dans différentes régions. Les passerelles multiclusters facilitent la gestion, la sécurisation et la mise l'échelle de la mise en réseau des applications pour de nombreux clusters et équipes par les administrateurs d'infrastructure.

Une passerelle multicluster est une ressource de passerelle (Gateway) qui équilibre la charge de trafic sur plusieurs clusters Kubernetes.

Cette page présente trois exemples afin de vous apprendre à déployer des passerelles multiclusters à l'aide du contrôleur GKE Gateway :

  • Exemple 1 : passerelle multicluster externe offrant un équilibrage de charge sur deux clusters GKE pour le trafic Internet.
  • Exemple 2: Passerelle privée de couche 7 interrégionale.
  • Exemple 3: répartition du trafic bleu-vert en fonction du poids et mise en miroir du trafic sur deux clusters GKE pour le trafic VPC interne.
  • Exemple 4: une passerelle basée sur la capacité permettant d'équilibrer la charge de requêtes vers différents backends en fonction de leur capacité maximale.

Chaque exemple utilise les mêmes applications store et site pour modéliser un scénario réel dans lequel un service d'achats en ligne et un service de site Web sont gérés et exploités par des équipes distinctes, et sont déployés sur un parc de clusters GKE partagé. Chaque exemple met en évidence différentes topologies et différents cas d'utilisation rendus possibles par les passerelles multiclusters.

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 Activer les passerelles multiclusters :

  1. Déployez des clusters GKE

  2. Enregistrez vos clusters dans un parc.

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

Consultez la section Limites et 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 Activer 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/v1beta1
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 doit ressembler à ceci :

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

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

    Cela 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/v1beta1
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/v1beta1
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 d'état de 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/v1beta1
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"
}

Déployer une passerelle multicluster interne dans plusieurs régions

Vous pouvez déployer des passerelles multiclusters qui fournissent un équilibrage de charge de couche 7 interne entre les clusters GKE de plusieurs régions. Ces passerelles utilisent la classe GatewayClass gke-l7-cross-regional-internal-managed-mc. Cette classe Gateway provisionne un équilibreur de charge d'application interne interrégional géré par Google Cloud et qui permet aux clients de votre réseau VPC d'accéder aux adresses IP virtuelles internes. Ces passerelles peuvent être exposées par les frontends dans les régions de votre choix, simplement en utilisant la passerelle pour demander des adresses dans ces régions. La VIP interne peut être une seule adresse IP ou plusieurs adresses IP dans plusieurs régions, avec une adresse IP par région spécifiée dans la passerelle. Le trafic est dirigé vers le cluster GKE backend opérationnel le plus proche pouvant répondre à la requête.

Avant de commencer

  1. Configurez votre projet et votre shell en configurant votre environnement gcloud avec votre ID de projet:

    export PROJECT_ID="YOUR_PROJECT_ID"
gcloud config set project ${PROJECT_ID}

  2. Créez des clusters GKE dans différentes régions.

    Cet exemple utilise deux clusters, gke-west-1 dans us-west1 et gke-east-1 dans us-east1. Assurez-vous que l'API Gateway est activée (--gateway-api=standard) et que les clusters sont enregistrés dans un parc.

    gcloud container clusters create gke-west-1 \
    --location=us-west1-a \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --project=${PROJECT_ID} \
    --enable-fleet \
    --gateway-api=standard

gcloud container clusters create gke-east-1 \
    --location=us-east1-c \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --project=${PROJECT_ID} \
    --enable-fleet \
    --gateway-api=standard

    Renommez les contextes pour y accéder plus facilement:

    gcloud container clusters get-credentials gke-west-1 \
  --location=us-west1-a \
  --project=${PROJECT_ID}

gcloud container clusters get-credentials gke-east-1 \
  --location=us-east1-c \
  --project=${PROJECT_ID}
kubectl config rename-context gke_${PROJECT_ID}_us-west1-a_gke-west-1 gke-west1
kubectl config rename-context gke_${PROJECT_ID}_us-east1-c_gke-east-1 gke-east1

  3. Activez les services multiclusters (MCS) et Ingress multicluster (MCI/passerelle):

    gcloud container fleet multi-cluster-services enable --project=${PROJECT_ID}

# Set the config membership to one of your clusters (e.g., gke-west-1)
# This cluster will be the source of truth for multi-cluster Gateway and Route resources.
gcloud container fleet ingress enable \
    --config-membership=projects/${PROJECT_ID}/locations/us-west1/memberships/gke-west-1 \
    --project=${PROJECT_ID}

  4. Configurez des sous-réseaux proxy réservés. Un sous-réseau proxy réservé est requis dans chaque région où se trouvent vos clusters GKE et où l'équilibreur de charge fonctionnera. Pour les équilibreurs de charge d'application internes interrégionaux, l'objectif de ce sous-réseau doit être défini sur GLOBAL_MANAGED_PROXY.

    # Proxy-only subnet for us-west1
gcloud compute networks subnets create us-west1-proxy-only-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-west1 \
    --network=default \
    --range=10.129.0.0/23 # Choose an appropriate unused CIDR range

# Proxy-only subnet for us-east1
gcloud compute networks subnets create us-east1-proxy-only-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-east1 \
    --network=default \
    --range=10.130.0.0/23 # Choose an appropriate unused CIDR range

    Si vous n'utilisez pas le réseau par défaut, remplacez default par le nom de votre réseau VPC. Assurez-vous que les plages CIDR sont uniques et ne se chevauchent pas.

  5. Déployez vos applications de démonstration, telles que store, sur les deux clusters. L'exemple de fichier store.yaml de gke-networking-recipes crée un espace de noms store et un déploiement.

    kubectl apply --context gke-west1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

  6. Exportez des services à partir de chaque cluster en créant des ressources Service et ServiceExport Kubernetes dans chaque cluster, ce qui permet de les détecter dans l'ensemble du parc. L'exemple suivant exporte un service store générique et des services spécifiques à la région (store-west-1, store-east-1) de chaque cluster, le tout dans l'espace de noms store.

    Appliquer à gke-west1:

    cat << EOF | kubectl apply --context gke-west1 -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 # Specific to this cluster
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1 # Exporting the region-specific service
  namespace: store
EOF

    Appliquer à gke-east1:

    cat << EOF | kubectl apply --context gke-east1 -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 # Specific to this cluster
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1 # Exporting the region-specific service
  namespace: store
EOF

  7. Vérifiez les importations de services : vérifiez que des ressources ServiceImport sont créées dans chaque cluster de l'espace de noms store. Leur création peut prendre quelques minutes. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store store, store-west-1 et store-east-1 devraient apparaître (ou les entrées pertinentes en fonction de la propagation).

Configurer une passerelle multirégionale interne

Définissez une ressource Gateway qui fait référence à la classe GatewayClass gke-l7-cross-regional-internal-managed-mc. Vous appliquez ce fichier manifeste à votre cluster de configuration désigné, par exemple gke-west-1.

Le champ spec.addresses vous permet de demander des adresses IP éphémères dans des régions spécifiques ou d'utiliser des adresses IP statiques préalloués.

  1. Pour utiliser des adresses IP éphémères, enregistrez le fichier manifeste Gateway suivant sous le nom cross-regional-gateway.yaml:

    # cross-regional-gateway.yaml
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-cross-region-gateway
  namespace: store # Namespace for the Gateway resource
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  # Addresses across regions. Address value is allowed to be empty or matching
  # the region name.
  - type: networking.gke.io/ephemeral-ipv4-address/us-west1
    value: "us-west1"
  - type: networking.gke.io/ephemeral-ipv4-address/us-east1
    value: "us-east1"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute # Only allow HTTPRoute to attach

    La liste suivante définit certains des champs du fichier YAML précédent:

    • metadata.namespace: espace de noms dans lequel la ressource de passerelle est créée, par exemple store.
    • spec.gatewayClassName: nom de la classe GatewayClass. Doit être gke-l7-cross-regional-internal-managed-mc.
    • spec.listeners.allowedRoutes.kinds: types d'objets Route pouvant être associés, par exemple HTTPRoute.
    • spec.addresses :
      • type: networking.gke.io/ephemeral-ipv4-address/REGION: demande une adresse IP éphémère.
      • value: spécifie la région de l'adresse, par exemple "us-west1" ou "us-east1".

  2. Appliquez le fichier manifeste à votre cluster de configuration, par exemple gke-west1:

    kubectl apply --context gke-west1 -f cross-regional-gateway.yaml

Associer des HTTPRoutes à la passerelle

Définissez des ressources HTTPRoute pour gérer l'acheminement du trafic et appliquez-les à votre cluster de configuration.

  1. Enregistrez le manifeste HTTPRoute suivant sous le nom store-route.yaml :

    # store-route.yaml
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: cross-regional-internal
spec:
  parentRefs:
  - name: internal-cross-region-gateway
    namespace: store # Namespace where the Gateway is deployed
  hostnames:
  - "store.example.internal" # Hostname clients will use
  rules:
  - matches: # Rule for traffic to /west
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io # Indicates a multi-cluster ServiceImport
      kind: ServiceImport
      name: store-west-1 # Targets the ServiceImport for the west cluster
      port: 8080
  - matches: # Rule for traffic to /east
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-east-1 # Targets the ServiceImport for the east cluster
      port: 8080
  - backendRefs: # Default rule for other paths (e.g., /)
    - group: net.gke.io
      kind: ServiceImport
      name: store # Targets the generic 'store' ServiceImport (any region)
      port: 8080

    La liste suivante définit certains des champs du fichier YAML précédent:

    • spec.parentRefs: associe cette route à cross-region-gateway dans l'espace de noms store.
    • spec.hostnames: représente le nom d'hôte que les clients utilisent pour accéder au service.
    • spec.rules: définit la logique de routage. Cet exemple utilise le routage basé sur le chemin :
      • Le trafic /west est acheminé vers la ressource ServiceImport store-west-1.
      • Le trafic /east est acheminé vers la ressource ServiceImport store-east-1.
      • Tout autre trafic, tel que /, est acheminé vers la ressource ServiceImport générique store.
    • backendRefs :
      • group: net.gke.io et kind: ServiceImport ciblent des services multiclusters.

  2. Appliquez le fichier manifeste HTTPRoute à votre cluster de configuration:

    kubectl apply --context gke-west1 -f store-route.yaml

Vérifier l'état de la passerelle et du routage

  1. Vérifiez l'état de la passerelle:

    kubectl get gateway cross-region-gateway -n store -o yaml --context gke-west1

    Recherchez une condition avec l'état type:Programmedand: "True". You should see IP addresses assigned in thestatus.addressesfield, corresponding to the regions you specified (e.g., one forus-west1and one forus-east1`).

  2. Vérifiez l'état de HTTPRoute:

    kubectl get httproute store-route -n store -o yaml --context gke-west1

    Recherchez une condition dans status.parents[].conditions avec type: Accepted (ou ResolvedRefs) et status: "True".

Confirmer le trafic

Une fois que vous avez attribué les adresses IP à la passerelle, vous pouvez tester le trafic à partir d'une VM cliente située dans votre réseau VPC et dans l'une des régions, ou dans une région pouvant se connecter à l'adresse IP de la passerelle.

  1. Récupérez les adresses IP de la passerelle.

    La commande suivante tente d'analyser la sortie JSON. Vous devrez peut-être ajuster jsonpath en fonction de la structure exacte.

    kubectl get gateway cross-region-gateway -n store --context gke-west1 -o=jsonpath="{.status.addresses[*].value}".

    Le résultat de cette commande doit inclure les VIP, tels que VIP1_WEST ou VIP2_EAST.

  2. Envoyez des requêtes de test : Depuis une VM cliente de votre VPC:

    # Assuming VIP_WEST is an IP in us-west1 and VIP_EAST is an IP in us-east1
# Traffic to /west should ideally be served by gke-west-1
curl -H "host: store.example.internal" http://VIP_WEST/west
curl -H "host: store.example.internal" http://VIP_EAST/west # Still targets store-west-1 due to path

# Traffic to /east should ideally be served by gke-east-1
curl -H "host: store.example.internal" http://VIP_WEST/east # Still targets store-east-1 due to path
curl -H "host: store.example.internal" http://VIP_EAST/east

# Traffic to / (default) could be served by either cluster
curl -H "host: store.example.internal" http://VIP_WEST/
curl -H "host: store.example.internal" http://VIP_EAST/

    La réponse doit inclure des informations de l'application store indiquant le pod backend qui a traité la requête, par exemple cluster_name ou zone.

Utiliser des adresses IP statiques

Au lieu d'utiliser des adresses IP éphémères, vous pouvez utiliser des adresses IP internes statiques préalloquées.

  1. Créez des adresses IP statiques dans les régions que vous souhaitez utiliser:

    gcloud compute addresses create cross-region-gw-ip-west --region us-west1 --subnet default --project=${PROJECT_ID}
gcloud compute addresses create cross-region-gw-ip-east --region us-east1 --subnet default --project=${PROJECT_ID}

    Si vous n'utilisez pas le sous-réseau par défaut, remplacez default par le nom du sous-réseau contenant l'adresse IP que vous souhaitez allouer. Ces sous-réseaux sont des sous-réseaux standards, et non des sous-réseaux proxy réservés.

  2. Mettez à jour le fichier manifeste de la passerelle en modifiant la section spec.addresses de votre fichier cross-regional-gateway.yaml:

    # cross-regional-gateway-static-ip.yaml
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-cross-region-gateway # Or a new name if deploying alongside
  namespace: store
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  - type: networking.gke.io/named-address-with-region # Use for named static IP
    value: "regions/us-west1/addresses/cross-region-gw-ip-west"
  - type: networking.gke.io/named-address-with-region
    value: "regions/us-west1/addresses/cross-region-gw-ip-east"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

  3. Appliquez le fichier manifeste de la passerelle mis à jour.

    kubectl apply --context gke-west1 -f cross-regional-gateway.yaml

Considérations particulières pour les sous-réseaux non par défaut

Tenez compte des points suivants lorsque vous utilisez des sous-réseaux autres que ceux par défaut:

  • Même réseau VPC:toutes les ressources créées par l'utilisateur (adresses IP statiques, sous-réseaux proxy réservés et clusters GKE, par exemple) doivent se trouver sur le même réseau VPC.

  • Sous-réseau d'adresse:lorsque vous créez des adresses IP statiques pour la passerelle, elles sont attribuées à partir de sous-réseaux standards dans les régions spécifiées.

  • Nom du sous-réseau du cluster:chaque région doit disposer d'un sous-réseau portant le même nom que celui du sous-réseau dans lequel se trouve le cluster de configuration du MCS.

    • Par exemple, si votre cluster de configuration gke-west-1 se trouve dans projects/YOUR_PROJECT/regions/us-west1/subnetworks/my-custom-subnet, les régions pour lesquelles vous demandez des adresses doivent également disposer du sous-réseau my-custom-subnet. Si vous demandez des adresses dans les régions us-east1 et us-centra1, un sous-réseau nommé my-custom-subnet doit également exister dans ces régions.

Routage multicluster bleu-vert avec une passerelle

Les passerelles gke-l7-global-external-managed-*, gke-l7-regional-external-managed-* et gke-l7-rilb-* disposent de nombreuses fonctionnalités avancées de routage du trafic comme la répartition du trafic, la mise en correspondance des en-têtes, la manipulation des en-têtes, la mise en miroir du trafic, etc… Dans cet exemple, vous apprendrez à utiliser la répartition du trafic basée sur une pondération pour contrôler explicitement la proportion de trafic envoyée aux deux clusters GKE.

Cet exemple décrit certaines des étapes réelles qu'un propriétaire de service doit effectuer pour déplacer ou étendre son application vers un nouveau cluster GKE. L'objectif des déploiements bleu-vert est de réduire les risques grâce à plusieurs étapes de validation qui confirment que le nouveau cluster fonctionne correctement. Cet exemple décrit quatre étapes de déploiement :

  1. 100% – Canary basé sur l'en-tête : utilisez le routage d'en-tête HTTP pour envoyer uniquement le trafic de test ou de synthèse vers le nouveau cluster.
  2. 100% - Mise en miroir du trafic : mettez en miroir le trafic utilisateur vers le cluster Canary. Cela permet de tester la capacité du cluster Canary en copiant 100 % du trafic utilisateur vers ce cluster.
  3. 90 %-10 %  : répartition du trafic Canary de 10 % pour exposer progressivement le nouveau cluster vers le trafic en temps réel.
  4. 0 % - 100 % : basculer complète vers le nouveau cluster avec la possibilité de revenir en arrière si des erreurs sont observées.

Répartition bleu-vert du trafic sur deux clusters GKE

Cet exemple est semblable au précédent mais il utilise une passerelle multicluster interne. Il consiste à déployer un équilibreur de charge d'application interne qui n'est accessible que de manière privée depuis le VPC. Vous allez utilisez les clusters et l'application déployés lors des étapes précédentes mais les déployer via une autre passerelle.

Prérequis

L'exemple suivant s'appuie sur certaines des étapes de la section Déployer une passerelle multicluster externe. Assurez-vous d'avoir suivi les étapes suivantes avant de continuer avec cet exemple :

  1. Activer des passerelles multiclusters

  2. Déployer une application de démonstration

    Cet exemple utilise les clusters gke-west-1 et gke-west-2 que vous avez déjà configurés. Ces clusters se trouvent dans la même région, car la ressource GatewayClass gke-l7-rilb-mc est régionale et n'accepte que les backends de cluster situés dans la même région.

  3. Déployez les ressources Service et ServiceExport nécessaires sur chaque cluster. Si vous avez déployé des ressources Service et ServiceExport pour l'exemple précédent, vous avez déjà déployé certaines des ressources nécessaires.

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store-west-1-service.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-west-2-service.yaml

    Cela déploie un ensemble de ressources similaire sur chaque cluster :

    service/store created
serviceexport.net.gke.io/store created
service/store-west-2 created
serviceexport.net.gke.io/store-west-2 created

Configurer un sous-réseau proxy réservé

Si vous ne l'avez pas déjà fait, configurez un sous-réseau proxy réservé pour chaque région dans laquelle vous déployez des passerelles internes. Ce sous-réseau permet de fournir des adresses IP internes aux proxys des équilibreurs de charge et doit être configuré avec un --purpose défini sur REGIONAL_MANAGED_PROXY uniquement.

Vous devez créer un sous-réseau proxy réservé avant de créer des passerelles gérant des équilibreurs de charge d'application internes. Chaque région d'un réseau cloud privé virtuel (VPC) dans lequel vous utilisez des équilibreurs de charge d'application internes doit comporter un sous-réseau proxy réservé.

La commande gcloud compute networks subnets create crée un sous-réseau proxy réservé.

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

Remplacez les éléments suivants :

  • SUBNET_NAME : nom du sous-réseau proxy réservé.
  • REGION : région du sous-réseau proxy réservé.
  • VPC_NETWORK_NAME : nom du réseau VPC contenant le sous-réseau.
  • CIDR_RANGE : plage d'adresses IP principale du sous-réseau. Vous devez utiliser un masque de sous-réseau ne dépassant pas /26 afin qu'au moins 64 adresses IP soient disponibles pour les proxys de la région. Le masque de sous-réseau recommandé est /23.

Déployer la passerelle

La passerelle suivante est créée à partir de la GatewayClass gke-l7-rilb-mc, qui est une passerelle interne régionale qui ne peut cibler que des clusters GKE dans la même région.

  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/v1beta1
metadata:
  name: internal-http
  namespace: store
spec:
  gatewayClassName: gke-l7-rilb-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

  2. Vérifiez que la passerelle est bien opérationnelle. Vous pouvez filtrer uniquement les événements de cette passerelle en utilisant la commande suivante :

    kubectl get events --field-selector involvedObject.kind=Gateway,involvedObject.name=internal-http --context=gke-west-1 --namespace store

    Le déploiement de la passerelle a réussi si le résultat ressemble à ce qui suit :

    LAST SEEN   TYPE     REASON   OBJECT                  MESSAGE
5m18s       Normal   ADD      gateway/internal-http   store/internal-http
3m44s       Normal   UPDATE   gateway/internal-http   store/internal-http
3m9s        Normal   SYNC     gateway/internal-http   SYNC on store/internal-http was a success

Canary basé sur l'en-tête

La version Canary basée sur l'en-tête permet au propriétaire du service de mettre en correspondance le trafic de test synthétique qui ne provient pas d'utilisateurs réels. Cela vous permet de vérifier facilement que le réseau de base de l'application fonctionne sans exposer directement les utilisateurs.

  1. 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/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  # Matches for env=canary and sends it to store-west-2 ServiceImport
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-west-2
        port: 8080
  # All other traffic goes to store-west-1 ServiceImport
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
EOF

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

    • Les requêtes internes envoyées à store.example.internal sans l'en-tête HTTP env: canary sont acheminées vers les pods store sur le cluster gke-west-1.
    • Les requêtes internes envoyées à store.example.internal avec l'en-tête HTTP env: canary sont acheminées vers les pods store sur le cluster gke-west-2.

    HTTPRoute permet de router les requêtes vers différents clusters en fonction des en-têtes HTTP.

    Vérifiez que l'objet HTTPRoute fonctionne correctement en envoyant du trafic vers l'adresse IP de la passerelle.

  2. Récupérez l'adresse IP interne de internal-http.

    kubectl get gateways.gateway.networking.k8s.io internal-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. Envoyez une requête à la passerelle en utilisant l'en-tête HTTP env: canary. Cela confirme que le trafic est acheminé vers gke-west-2. Utilisez un client privé dans le même VPC que les clusters GKE afin de vérifier que les requêtes sont correctement acheminées. La commande suivante doit être exécutée sur une machine disposant d'un accès privé à l'adresse IP de la passerelle, sans quoi elle ne fonctionnera pas.

    curl -H "host: store.example.internal" -H "env: canary" http://VIP

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

    {
    "cluster_name": "gke-west-2", 
    "host_header": "store.example.internal",
    "node_name": "gke-gke-west-2-default-pool-4cde1f72-m82p.c.agmsb-k8s.internal",
    "pod_name": "store-5f5b954888-9kdb5",
    "pod_name_emoji": "😂",
    "project_id": "agmsb-k8s",
    "timestamp": "2021-05-31T01:21:55",
    "zone": "us-west1-a"
}

Mise en miroir du trafic

Cette étape envoie le trafic vers le cluster prévu, mais met également en miroir ce trafic vers le cluster Canary.

La mise en miroir permet de déterminer l'impact de la charge de trafic sur les performances de l'application, sans aucun impact sur les réponses fournies à vos clients. Elle n'est pas nécessaire pour tous les types de déploiements, mais elle peut être utile lors du déploiement de modifications importantes susceptibles d'affecter les performances ou la charge.

  1. 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/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  # Sends all traffic to store-west-1 ServiceImport
  - backendRefs:
    - name: store-west-1
      group: net.gke.io
      kind: ServiceImport
      port: 8080
    # Also mirrors all traffic to store-west-2 ServiceImport
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          group: net.gke.io
          kind: ServiceImport
          name: store-west-2
          port: 8080
EOF

  2. À l'aide de votre client privé, envoyez une requête à la passerelle internal-http. Utilisez le chemin /mirror pour identifier de manière unique cette requête dans les journaux d'application lors d'une prochaine étape.

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

  3. Le résultat confirme que le client a reçu une réponse d'un pod du cluster gke-west-1 :

    {
    "cluster_name": "gke-west-1", 
    "host_header": "store.example.internal",
    "node_name": "gke-gke-west-1-default-pool-65059399-ssfq.c.agmsb-k8s.internal",
    "pod_name": "store-5f5b954888-brg5w",
    "pod_name_emoji": "🎖",
    "project_id": "agmsb-k8s",
    "timestamp": "2021-05-31T01:24:51",
    "zone": "us-west1-a"
}

    Cela confirme que le cluster principal répond bien au trafic. Vous devez toujours vérifier que le cluster vers lequel vous effectuez la migration reçoit le trafic mis en miroir.

  4. Vérifiez les journaux d'application d'un pod store sur le cluster gke-west-2. Les journaux doivent confirmer que le pod a bien reçu le trafic mis en miroir de l'équilibreur de charge.

    kubectl logs deployment/store --context gke-west-2 -n store | grep /mirror

  5. Ce résultat confirme que les pods du cluster gke-west-2 reçoivent également les mêmes requêtes, mais que leurs réponses à ces requêtes ne sont pas renvoyées au client. Les adresses IP affichées dans les journaux sont les adresses IP internes de l'équilibreur de charge interne qui communique avec vos pods.

    Found 2 pods, using pod/store-5c65bdf74f-vpqbs
[2023-10-12 21:05:20,805] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:20] "GET /mirror HTTP/1.1" 200 -
[2023-10-12 21:05:27,158] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:27] "GET /mirror HTTP/1.1" 200 -
[2023-10-12 21:05:27,805] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:27] "GET /mirror HTTP/1.1" 200 -

Répartition du trafic

La répartition du trafic est l'une des méthodes les plus courantes pour déployer du nouveau code ou effectuer des déploiements en toute sécurité dans de nouveaux environnements. Le propriétaire du service définit un pourcentage explicite de trafic envoyé aux backends Canary, généralement une petite partie du trafic global, afin de déterminer la réussite du déploiement avec une quantité acceptable de risque pour les requêtes réelles des utilisateurs.

Une répartition du trafic avec une petite partie du trafic permet au propriétaire du service d'inspecter l'état de l'application et des réponses. Si tous les signaux semblent opérationnels, il est possible de passer au basculement complet.

  1. 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/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  - backendRefs:
    # 90% of traffic to store-west-1 ServiceImport
    - name: store-west-1
      group: net.gke.io
      kind: ServiceImport
      port: 8080
      weight: 90
    # 10% of traffic to store-west-2 ServiceImport
    - name: store-west-2
      group: net.gke.io
      kind: ServiceImport
      port: 8080
      weight: 10
EOF

  2. À l'aide de votre client privé, envoyez une requête curl continue à la passerelle internal- http.

    while true; do curl -H "host: store.example.internal" -s VIP | grep "cluster_name"; sleep 1; done

    Le résultat sera semblable à ceci, indiquant qu'une répartition du trafic de 90/10 est appliquée.

    "cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
...

Basculement du trafic

La dernière étape de la migration bleu-vert consiste à basculer entièrement vers le nouveau cluster et à supprimer l'ancien cluster. Si le propriétaire du service était en train d'intégrer un deuxième cluster à un cluster existant, cette dernière étape serait différente, car elle consisterait à répartir le trafic entre les deux clusters. Dans ce scénario, il est recommandé d'utiliser une seule ressource ServiceImport store comportant des pods provenant des clusters gke-west-1 et gke-west-2. Cela permet à l'équilibreur de charge de prendre la décision d'acheminement du trafic pour une application en mode actif/actif, en se basant sur la proximité, l'état et la capacité.

  1. 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/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
    - backendRefs:
      # No traffic to the store-west-1 ServiceImport
      - name: store-west-1
        group: net.gke.io
        kind: ServiceImport
        port: 8080
        weight: 0
      # All traffic to the store-west-2 ServiceImport
      - name: store-west-2
        group: net.gke.io
        kind: ServiceImport
        port: 8080
        weight: 100
EOF

  2. À l'aide de votre client privé, envoyez une requête curl continue à la passerelle internal- http.

    while true; do curl -H "host: store.example.internal" -s VIP | grep "cluster_name"; sleep 1; done

    Le résultat sera semblable à ceci, indiquant que tout le trafic est maintenant dirigé vers gke-west-2.

    "cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
...

Cette dernière étape vient clôturer le processus de migration bleu-vert complet d'une application, d'un cluster GKE vers un autre cluster GKE.

Déployer un équilibrage de charge basé sur la capacité

L'exercice de cette section illustre les concepts mondiaux d'équilibrage de charge et de capacité de service, en déployant une application sur deux clusters GKE dans différentes régions. Le trafic généré est envoyé à différents niveaux de requête par seconde (RPS) pour montrer comment le trafic est équilibré entre les clusters et les régions.

Le schéma suivant illustre la topologie que vous allez déployer et la manière dont le trafic déborde entre les clusters et les régions lorsque le trafic a dépassé la capacité de service :

Débordement du trafic d&#39;un cluster à un autre

Pour en savoir plus sur la gestion du trafic, consultez la page Gestion du trafic GKE.

Préparer votre environnement

  1. Pour préparer votre environnement, suivez les instructions de la section Activer les passerelles multiclusters.

  2. Vérifiez que les ressources GatewayClass sont installées sur le cluster de configuration :

    kubectl get gatewayclasses --context=gke-west-1

    Le résultat ressemble à ce qui suit :

    NAME                                  CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed        networking.gke.io/gateway   True       16h
gke-l7-global-external-managed-mc     networking.gke.io/gateway   True       14h
gke-l7-gxlb                           networking.gke.io/gateway   True       16h
gke-l7-gxlb-mc                        networking.gke.io/gateway   True       14h
gke-l7-regional-external-managed      networking.gke.io/gateway   True       16h
gke-l7-regional-external-managed-mc   networking.gke.io/gateway   True       14h
gke-l7-rilb                           networking.gke.io/gateway   True       16h
gke-l7-rilb-mc                        networking.gke.io/gateway   True       14h

Déployer une application

Déployez l'exemple de serveur d'applications Web sur les deux clusters :

kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml

Le résultat ressemble à ce qui suit :

namespace/store created
deployment.apps/store created

Déployer un service, une passerelle et une route HTTP

  1. Appliquez le fichier manifeste Service suivant aux clusters gke-west-1 et gke-east-1 :

    cat << EOF | kubectl apply --context gke-west-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: traffic-test
  annotations:
    networking.gke.io/max-rate-per-endpoint: "10"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: traffic-test
EOF

    cat << EOF | kubectl apply --context gke-east-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: traffic-test
  annotations:
    networking.gke.io/max-rate-per-endpoint: "10"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: traffic-test
EOF

    Le service est annoté avec max-rate-per-endpoint défini sur 10 requêtes par seconde. Avec deux instances dupliquées par cluster, chaque service dispose d'une capacité de 20 RPS par cluster.

    Pour plus d'informations sur le choix d'un niveau de capacité de service pour votre service, consultez la section Déterminer la capacité de votre service.

  2. 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/v1beta1
metadata:
  name: store
  namespace: traffic-test
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    Le fichier manifeste décrit une passerelle multicluster globale externe, qui déploie un équilibreur de charge d'application externe avec une adresse IP accessible publiquement.

  3. 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/v1beta1
metadata:
  name: store
  namespace: traffic-test
  labels:
    gateway: store
spec:
  parentRefs:
  - kind: Gateway
    namespace: traffic-test
    name: store
  rules:
  - backendRefs:
    - name: store
      group: net.gke.io
      kind: ServiceImport
      port: 8080
EOF

    Le fichier manifeste décrit une HTTPRoute qui configure la passerelle avec une règle de routage qui dirige tout le trafic vers la ressource ServiceImport du magasin. La ressource ServiceImport store regroupe les pods de service store sur les deux clusters et permet à l'équilibreur de charge de les traiter comme un service unique.

    Vous pouvez vérifier les événements de la passerelle après quelques minutes pour voir si le déploiement est terminé :

    kubectl describe gateway store -n traffic-test --context gke-west-1

    Le résultat ressemble à ce qui suit :

    ...
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.102.159.147
  Conditions:
    Last Transition Time:  2023-10-12T21:40:59Z
    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-12T21:40:59Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T21:40:59Z
    Message:
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T21:40:59Z
    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-12T21:40:59Z
      Message:
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T21:40:59Z
      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  ADD     12m                  mc-gateway-controller  traffic-test/store
  Normal  SYNC    6m43s                mc-gateway-controller  traffic-test/store
  Normal  UPDATE  5m40s (x4 over 12m)  mc-gateway-controller  traffic-test/store
  Normal  SYNC    118s (x6 over 10m)   mc-gateway-controller  SYNC on traffic-test/store was a success

    Ce résultat indique que la passerelle a été déployée avec succès. Le déploiement du trafic peut prendre quelques minutes après le déploiement de la passerelle. Notez l'adresse IP dans ce résultat, car elle est utilisée dans une étape suivante.

Confirmer le trafic

Vérifiez que le trafic est transmis à l'application en testant l'adresse IP de la passerelle à l'aide d'une commande curl :

curl GATEWAY_IP_ADDRESS

Le résultat ressemble à ce qui suit :

{
  "cluster_name": "gke-west-1",
  "host_header": "34.117.182.69",
  "pod_name": "store-54785664b5-mxstv",
  "pod_name_emoji": "👳🏿",
  "project_id": "project",
  "timestamp": "2021-11-01T14:06:38",
  "zone": "us-west1-a"
}

Ce résultat affiche les métadonnées du pod, qui indiquent la région depuis laquelle la requête a été diffusée.

Vérifier le trafic à l'aide de tests de charge

Pour vérifier que l'équilibreur de charge fonctionne, vous pouvez déployer un générateur de trafic dans votre cluster gke-west-1. Le générateur de trafic génère du trafic à différents niveaux de charge pour illustrer la capacité et le débordement de l'équilibreur de charge. Les trois niveaux de charge suivants sont présentés :

  • 10 RPS, ce qui est inférieur à la capacité du service de magasin dans gke-west-1
  • 30 RPS, ce qui est une surcapacité pour le service de magasin gke-west-1 et entraîne un débordement du trafic vers gke-east-1.
  • 60 RPS, ce qui correspond à la surcapacité des services dans les deux clusters.

Configurer le tableau de bord

  1. Récupérez le nom du mappage d'URL sous-jacent de votre passerelle :

    kubectl get gateway store -n traffic-test --context=gke-west-1 -o=jsonpath="{.metadata.annotations.networking\.gke\.io/url-maps}"

    Le résultat ressemble à ce qui suit :

    /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-traffic-test-store-armvfyupay1t

  2. Dans la console Google Cloud , accédez à la page Explorateur de métriques.

    Accéder à l'explorateur de métriques

  3. Sous Sélectionner une métrique, cliquez sur CODE: MQL.

  4. Saisissez la requête suivante pour observer les métriques de trafic du service de magasin sur vos deux clusters :

    fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/backend_request_count'
| filter (resource.url_map_name == 'GATEWAY_URL_MAP')
| align rate(1m)
| every 1m
| group_by [resource.backend_scope],
    [value_backend_request_count_aggregate:
        aggregate(value.backend_request_count)]

    Remplacez GATEWAY_URL_MAP par le nom de mappage d'URL de l'étape précédente.

  5. Cliquez sur Exécuter la requête. Attendez au moins cinq minutes après le déploiement du générateur de charge dans la section suivante pour que les métriques s'affichent dans le graphique.

Test avec 10 RPS

  1. Déployez un pod sur votre cluster gke-west-1 :

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 10'

    Remplacez GATEWAY_IP_ADDRESS par l'adresse IP de la passerelle de l'étape précédente.

    Le résultat ressemble à ce qui suit, indiquant que le générateur de trafic envoie du trafic :

    If you don't see a command prompt, try pressing enter.

    Le générateur de charge envoie en continu 10 RPS à la passerelle. Même si le trafic provient de la région Google Cloud , l'équilibreur de charge le considère comme du trafic client provenant de la côte ouest des États-Unis. Pour simuler une diversité de client réaliste, le générateur de charge envoie chaque requête HTTP en tant que nouvelle connexion TCP, ce qui signifie que le trafic est réparti plus uniformément entre les pods de backend.

    Le générateur prend jusqu'à 5 minutes pour générer du trafic pour le tableau de bord.

  2. Afficher le tableau de bord de l'explorateur de métriques Deux lignes apparaissent, indiquant la quantité de charge de trafic équilibrée pour chacun des clusters :

    Graphique montrant la charge de trafic équilibrée pour les clusters

    Vous devriez constater que us-west1-a reçoit environ 10 RPS de trafic, tandis que us-east1-b ne reçoit aucun trafic. Comme le générateur de trafic s'exécute dans la région us-west1, tout le trafic est envoyé au service dans le cluster gke-west-1.

  3. Arrêtez le générateur de charge à l'aide du raccourci Ctrl+C, puis supprimez le pod :

    kubectl delete pod loadgen --context gke-west-1

Test avec 30 RPS

  1. Déployez à nouveau le générateur de charge, mais configuré pour envoyer 30 RPS :

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 30'

    Le générateur prend jusqu'à 5 minutes pour générer du trafic pour le tableau de bord.

  2. Affichez votre tableau de bord Cloud Ops.

    Graphique illustrant le débordement du trafic vers gke-east-1

    Vous devriez constater qu'environ 20 RPS sont envoyées à us-west1-a et 10 RPS à us-east1-b. Cela indique que le service de gke-west-1 est pleinement utilisé et qu'il fait déborder 10 RPS du trafic vers le service dans gke-east-1.

  3. Arrêtez le générateur de charge à l'aide du raccourci Ctrl+C, puis supprimez le pod :

    kubectl delete pod loadgen --context gke-west-1

Test avec 60 RPS

  1. Déployez le générateur de charge configuré pour envoyer 60 RPS :

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 60'

  2. Attendez cinq minutes, puis affichez votre tableau de bord Cloud Ops. Vous devriez maintenant voir que les deux clusters reçoivent environ 30 RPS. Étant donné que tous les services sont surexploités à l'échelle mondiale, le trafic n'est pas en débordement et les services absorbent tout le trafic possible.

    Graphique illustrant les services surexploités

  3. Arrêtez le générateur de charge à l'aide du raccourci Ctrl+C, puis supprimez le pod :

    kubectl delete pod loadgen --context gke-west-1

Effectuer un nettoyage

Après avoir terminé les exercices de cette page, 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

Utiliser une passerelle multicluster avec un VPC partagé

Une passerelle multicluster peut également être déployée dans un environnement VPC partagé, avec différentes topologies, en fonction du cas d'utilisation.

Le tableau suivant décrit les topologies de passerelles multiclusters compatibles avec un environnement VPC partagé :

Scénario Projet hôte du parc Cluster de configuration Clusters de charge de travail
1 Projet hôte de VPC partagé Projet hôte de VPC partagé Projet hôte de VPC partagé
2 Projet de service VPC partagé Projet de service de VPC partagé
(identique à celui de service de parc)		 Projet de service de VPC partagé
(identique à celui de service de parc)

Pour créer des passerelles multiclusters dans un environnement VPC partagé, procédez comme suit :

  1. Suivez la procédure pour configurer vos services multiclusters avec un VPC partagé.

  2. Créez vos services et exportez-les vers le cluster de configuration.

  3. Si vous prévoyez d'utiliser une passerelle interne multicluster, créez un sous-réseau proxy réservé.

  4. Créez vos ressources Gateway multiclusters et HTTPRoute externes ou internes

Une fois ces étapes terminées, vous pouvez valider votre déploiement en fonction de votre topologie.

Dépannage

Le sous-réseau proxy réservé destiné à la passerelle interne n'existe pas

Si l'événement suivant apparaît sur votre passerelle interne, il n'existe pas de sous-réseau proxy réservé pour cette région. Pour résoudre ce problème, déployez un sous-réseau proxy réservé.

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/us-west1/targetHttpProxies/gkegw-x5vt-default-internal-http-2jzr7e3xclhj'. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

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