Internes Multi-Cluster-Gateway bereitstellen

In diesem Dokument wird anhand eines praktischen Beispiels beschrieben, wie Sie ein internes Multi-Cluster-Gateway bereitstellen, um Traffic in Ihrem VPC-Netzwerk an eine Anwendung weiterzuleiten, die in zwei verschiedenen GKE-Clustern ausgeführt wird.

Multi-Cluster-Gateways bieten eine leistungsstarke Möglichkeit, Traffic für Dienste zu verwalten, die in mehreren GKE-Clustern bereitgestellt werden. Mit der globalen Load-Balancing-Infrastruktur von Google können Sie einen einzigen Einstiegspunkt für Ihre Anwendungen erstellen, was die Verwaltung vereinfacht und die Zuverlässigkeit verbessert.

In dieser Anleitung verwenden Sie eine store-Beispielanwendung, um ein reales Szenario zu simulieren, in dem ein Online-Shopping-Dienst von separaten Teams betrieben und über eine Flotte freigegebener GKE-Cluster bereitgestellt wird.

In diesem Beispiel wird gezeigt, wie Sie pfadbasiertes Routing einrichten, um Traffic an verschiedene Cluster weiterzuleiten.

Hinweise

Multi-Cluster-Gateways erfordern eine gewisse Umgebungsvorbereitung, bevor sie bereitgestellt werden können. Bevor Sie fortfahren, führen Sie die Schritte unter Umgebung für Multi-Cluster-Gateways vorbereiten aus:

  1. GKE-Cluster bereitstellen.

  2. Registrieren Sie Ihre Cluster für eine Flotte, falls noch nicht geschehen.

  3. Aktivieren Sie den Multi-Cluster-Service und die Multi-Cluster-Gateway-Controller.

Prüfen Sie dann vor der Verwendung in der Umgebung die Einschränkungen und bekannten Probleme des GKE Gateway-Controllers.

Internes Multi-Cluster-Gateway in mehreren Regionen bereitstellen

Sie können Multi-Cluster-Gateways bereitstellen, die internes Layer-7-Load-Balancing für GKE-Cluster in mehreren Regionen bieten. Diese Gateways verwenden die GatewayClass gke-l7-cross-regional-internal-managed-mc. Diese GatewayClass stellt einen regionenübergreifenden internen Application Load Balancer bereit, der von Google Cloud verwaltet wird und interne VIPs ermöglicht, auf die Clients in Ihrem VPC-Netzwerk zugreifen können. Diese Gateways können über Frontends in den Regionen Ihrer Wahl verfügbar gemacht werden, indem Sie einfach das Gateway verwenden, um Adressen in diesen Regionen anzufordern. Die interne VIP kann eine einzelne IP-Adresse oder IP-Adressen in mehreren Regionen sein, wobei im Gateway eine IP-Adresse pro Region angegeben ist. Der Traffic wird an den nächstgelegenen fehlerfreien GKE-Cluster weitergeleitet, der die Anfrage verarbeiten kann.

Vorbereitung

  1. Richten Sie Ihr Projekt und Ihre Shell ein, indem Sie die Umgebungsvariable gcloud mit Ihrer Projekt-ID konfigurieren:

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

  2. GKE-Cluster in verschiedenen Regionen erstellen.

    In diesem Beispiel werden zwei Cluster verwendet: gke-west-1 in us-west1 und gke-east-1 in us-east1. Prüfen Sie, ob die Gateway API aktiviert (--gateway-api=standard) und Cluster in einer Flotte registriert sind.

    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

    Kontexte für einen einfacheren Zugriff umbenennen:

    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. Aktivieren Sie Multi-Cluster-Dienste (MCS) und Multi-Cluster-Ingress (MCI/Gateway):

    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. Nur-Proxy-Subnetze konfigurieren In jeder Region, in der sich Ihre GKE-Cluster befinden und in der der Load Balancer ausgeführt wird, ist ein Nur-Proxy-Subnetz erforderlich. Für regionenübergreifende interne Application Load Balancer muss der Zweck dieses Subnetzes auf GLOBAL_MANAGED_PROXY festgelegt werden.

    # 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

    Wenn Sie nicht das Standardnetzwerk verwenden, ersetzen Sie default durch den Namen Ihres VPC-Netzwerk. Die CIDR-Bereiche müssen eindeutig sein und dürfen sich nicht überschneiden.

  5. Stellen Sie Ihre Demoanwendungen, z. B. store, in beiden Clustern bereit. Im Beispiel wird mit der Datei store.yaml aus gke-networking-recipes ein store-Namespace und eine Bereitstellung erstellt.

    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. Exportieren Sie Services aus jedem Cluster, indem Sie Kubernetes-Service-Ressourcen und ServiceExport-Ressourcen in jedem Cluster erstellen. Dadurch werden die Services in der gesamten Flotte auffindbar. Im folgenden Beispiel werden ein generischer store-Dienst und regionsspezifische Dienste (store-west-1, store-east-1) aus jedem Cluster exportiert, alle im Namespace store.

    Gültig für 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

    Gültig für 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. ServiceImports prüfen: Prüfen Sie, ob ServiceImport-Ressourcen in jedem Cluster im Namespace store erstellt werden. Es kann einige Minuten dauern, bis sie erstellt sind. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store Sie sollten store, store-west-1 und store-east-1 sehen (oder relevante Einträge basierend auf der Weitergabe).

Internes Multi-Region-Gateway konfigurieren

Definieren Sie eine Gateway-Ressource, die auf die gke-l7-cross-regional-internal-managed-mc-GatewayClass verweist. Sie wenden dieses Manifest auf Ihren Konfigurationscluster an, z. B. gke-west-1.

Im Feld spec.addresses können Sie sitzungsspezifische IP-Adressen in bestimmten Regionen anfordern oder vorab zugewiesene statische IP-Adressen verwenden.

  1. Wenn Sie sitzungsspezifische IP-Adressen verwenden möchten, speichern Sie das folgende Gateway-Manifest als 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

    In der folgenden Liste werden einige der Felder in der vorherigen YAML-Datei definiert:

    • metadata.namespace: Der Namespace, in dem die Gateway-Ressource erstellt wird, z. B. store.
    • spec.gatewayClassName: Der Name der GatewayClass. Muss gke-l7-cross-regional-internal-managed-mc lauten.
    • spec.listeners.allowedRoutes.kinds: Die Arten von Routenobjekten, die angehängt werden können, z. B. HTTPRoute.
    • spec.addresses:
      • type: networking.gke.io/ephemeral-ipv4-address/REGION: fordert eine temporäre IP-Adresse an.
      • value: Gibt die Region für die Adresse an, z. B. "us-west1" oder "us-east1".

  2. Wenden Sie das Manifest auf Ihren Konfigurationscluster an, z. B. gke-west1:

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

HTTPRoutes an das Gateway anhängen

Definieren Sie HTTPRoute-Ressourcen, um das Traffic-Routing zu verwalten, und wenden Sie sie auf Ihren Konfigurationscluster an.

  1. Speichern Sie das folgende HTTPRoute-Manifest als 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

    In der folgenden Liste werden einige der Felder in der vorherigen YAML-Datei definiert:

    • spec.parentRefs: Diese Route wird an internal-cross-region-gateway im Namespace store angehängt.
    • spec.hostnames: Der Hostname, den Clients für den Zugriff auf den Dienst verwenden.
    • spec.rules: Definiert die Routinglogik. In diesem Beispiel wird pfadbasiertes Routing verwendet:
      • Der Traffic an /west wird an den ServiceImport store-west-1 weitergeleitet.
      • Der Traffic an /east wird an den ServiceImport store-east-1 weitergeleitet.
      • Der gesamte andere Traffic, z. B. /, wird an den generischen store-ServiceImport weitergeleitet.
    • backendRefs:
      • group: net.gke.io und kind: ServiceImport sind auf Multi-Cluster-Dienste ausgerichtet.

  2. Wenden Sie das Manifest HTTPRoute auf Ihren Konfigurationscluster an:

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

Status des Gateways und der Route prüfen

  1. Gateway-Status prüfen:

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

    Suchen Sie nach einer Bedingung mit dem type:Programmedand-Status: „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. Prüfen Sie den HTTPRoute-Status:

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

    Suchen Sie in status.parents[].conditions nach einer Bedingung mit type: Accepted (oder ResolvedRefs) und status: "True".

Traffic bestätigen

Nachdem Sie dem Gateway die IP-Adressen zugewiesen haben, können Sie den Traffic von einer Client-VM testen, die sich in Ihrem VPC-Netzwerk und in einer der Regionen oder in einer Region befindet, die eine Verbindung zur Gateway-IP-Adresse herstellen kann.

  1. Rufen Sie die Gateway-IP-Adressen ab.

    Mit dem folgenden Befehl wird versucht, die JSON-Ausgabe zu parsen. Möglicherweise müssen Sie jsonpath an die genaue Struktur anpassen.

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

    Die Ausgabe dieses Befehls sollte die VIPs enthalten, z. B. VIP1_WEST oder VIP2_EAST.

  2. Testanfragen senden: Von einer Client-VM in Ihrer 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/

    Die Antwort sollte Details aus der store-Anwendung enthalten, die angeben, welcher Backend-Pod die Anfrage verarbeitet hat, z. B. cluster_name oder zone.

Statische IP-Adressen verwenden

Statt sitzungsspezifischer IP-Adressen können Sie vorab zugewiesene statische interne IP-Adressen verwenden.

  1. Erstellen Sie statische IP-Adressen in den Regionen, die Sie verwenden möchten:

    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}

    Wenn Sie nicht das Standardsubnetz verwenden, ersetzen Sie default durch den Namen des Subnetzes mit der IP-Adresse, die Sie zuweisen möchten. Diese Subnetze sind reguläre Subnetze und nicht die Nur-Proxy-Subnetze.

  2. Aktualisieren Sie das Gateway-Manifest, indem Sie den Abschnitt spec.addresses in der Datei cross-regional-gateway.yaml ändern:

    # 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. Wenden Sie das aktualisierte Gateway-Manifest an.

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

Besondere Überlegungen für nicht standardmäßige Subnetze

Beachten Sie bei der Verwendung von Nicht-Standard-Subnetzen die folgenden Aspekte:

  • Dasselbe VPC-Netzwerk:Alle vom Nutzer erstellten Ressourcen wie statische IP-Adressen, Nur-Proxy-Subnetze und GKE-Cluster müssen sich im selben VPC-Netzwerk befinden.

  • Adress-Subnetz:Wenn Sie statische IP-Adressen für das Gateway erstellen, werden sie aus regulären Subnetzen in den angegebenen Regionen zugewiesen.

  • Benennung von Cluster-Subnetzen:Jede Region muss ein Subnetz haben, das denselben Namen wie das Subnetz hat, in dem sich der MCG-Konfigurationscluster befindet.

    • Wenn sich Ihr gke-west-1-Konfigurationscluster beispielsweise in projects/YOUR_PROJECT/regions/us-west1/subnetworks/my-custom-subnet befindet, muss für die Regionen, für die Sie Adressen anfordern, auch das my-custom-subnet-Subnetz vorhanden sein. Wenn Sie Adressen in den Regionen us-east1 und us-centra1 anfordern, muss in diesen Regionen auch ein Subnetz mit dem Namen my-custom-subnet vorhanden sein.

Bereinigen

Wenn Sie mit den Übungen in diesem Dokument fertig sind, entfernen Sie mit den folgenden Schritten die Ressourcen, damit Sie unerwünschte Kosten für Ihr Konto vermeiden:

  1. Löschen Sie die Cluster.

  2. Heben Sie die Registrierung der Cluster für die Flotte auf, wenn sie nicht für einen anderen Zweck registriert werden müssen.

  3. Deaktivieren Sie die Funktion multiclusterservicediscovery.

    gcloud container fleet multi-cluster-services disable

  4. Deaktivieren sie Multi-Cluster-Ingress:

    gcloud container fleet ingress disable

  5. Deaktivieren Sie die APIs:

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

Fehlerbehebung

Nur-Proxy-Subnetz für internes Gateway nicht vorhanden

Wenn das folgende Ereignis auf Ihrem internen Gateway angezeigt wird, ist für diese Region kein Nur-Proxy-Subnetz vorhanden. Stellen Sie ein Nur-Proxy-Subnetz bereit, um dieses Problem zu beheben.

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.

Kein gesunder Upstream

Symptom:

Das folgende Problem kann auftreten, wenn Sie ein Gateway erstellen, aber nicht auf die Backend-Dienste zugreifen können (Antwortcode 503):

no healthy upstream

Grund:

Diese Fehlermeldung gibt an, dass der Prüfer für die Systemdiagnose keine fehlerfreien Backend-Dienste finden kann. Möglicherweise sind Ihre Back-End-Dienste in Ordnung, aber Sie müssen die Systemdiagnosen möglicherweise anpassen.

Workaround:

Um dieses Problem zu beheben, passen Sie Ihre Systemdiagnose anhand der Anforderungen Ihrer Anwendung (z. B. /health) mithilfe einer HealthCheckPolicy an.

Nächste Schritte