Déployer une passerelle multicluster interne

Ce document vous guide à travers un exemple pratique pour déployer une passerelle multicluster interne afin d'acheminer le trafic au sein de votre réseau VPC 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.

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

Vous pouvez déployer des passerelles multiclusters qui fournissent un équilibrage de charge interne de couche 7 sur les clusters GKE dans plusieurs régions. Ces passerelles utilisent la GatewayClass gke-l7-cross-regional-internal-managed-mc. Cette GatewayClass provisionne un équilibreur de charge d'application interne interrégional géré par Google Cloud et qui permet d'utiliser des adresses IP virtuelles internes auxquelles les clients de votre réseau VPC peuvent accéder. Ces passerelles peuvent être exposées par des composants d'interface utilisateur dans les régions de votre choix, simplement en utilisant la passerelle pour demander des adresses dans ces régions. L'adresse IP virtuelle interne peut être une adresse IP unique ou des 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 de backend opérationnel le plus proche pouvant répondre à la requête.

Prérequis

  1. Configurez votre projet et votre shell en configurant votre environnement gcloud avec l'ID de votre 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 les services de chaque cluster en créant des ressources Kubernetes Service et ServiceExport dans chaque cluster. Les services deviennent ainsi détectables dans l'ensemble du parc. L'exemple suivant exporte un service store générique et des services spécifiques à une région (store-west-1, store-east-1) à partir 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 ServiceImports : Assurez-vous que les ressources ServiceImport sont créées dans chaque cluster de l'espace de noms store. La création des instances peut prendre quelques minutes. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store Vous devriez voir les entrées store, store-west-1 et store-east-1 (ou les entrées pertinentes en fonction de la propagation).

Configurer une passerelle multirégionale interne

Définissez une ressource Gateway qui référence la ressource GatewayClass gke-l7-cross-regional-internal-managed-mc. Vous appliquez ce fichier manifeste à votre cluster de configuration désigné, tel que 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ées.

  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/v1
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 champs du fichier YAML précédent :

    • metadata.namespace : espace de noms dans lequel la ressource Gateway est créée, par exemple store.
    • spec.gatewayClassName : nom de la 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 ressources HTTPRoute à la passerelle

Définissez les ressources HTTPRoute pour gérer le routage 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/v1
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 champs du fichier YAML précédent :

    • spec.parentRefs : associe cette route à internal-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 d'accès :
      • Le trafic /west est acheminé vers ServiceImport store-west-1.
      • Le trafic /east est acheminé vers ServiceImport store-east-1.
      • Le reste du trafic, tel que /, est dirigé vers la ressource ServiceImport générique store.
    • backendRefs :
      • group: net.gke.io et kind: ServiceImport ciblent les 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 de la route

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

    kubectl get gateway internal-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 la ressource 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 qui se trouve 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 le 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 adresses IP virtuelles, telles 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 provenant de l'application store qui indiquent le pod de backend ayant traité la requête, comme cluster_name ou zone.

Utiliser des adresses IP statiques

Au lieu d'adresses IP éphémères, vous pouvez utiliser des adresses IP internes statiques pré-alloué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 qui possède l'adresse IP que vous souhaitez attribuer. Ces sous-réseaux sont des sous-réseaux standards, pas 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/v1
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-east1/addresses/cross-region-gw-ip-east"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

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

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

Remarques spécifiques aux sous-réseaux non définis 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, telles que les adresses IP statiques, les sous-réseaux proxy réservés et les clusters GKE, doivent résider dans le même réseau VPC.

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

  • Nommage des sous-réseaux de cluster : chaque région doit disposer d'un sous-réseau portant le même nom que celui dans lequel réside le cluster de configuration MCG.

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

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

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