Internes Multi-Cluster-Gateway bereitstellen

In diesem Dokument wird anhand eines praktischen Beispiels gezeigt, 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 Beispielanwendung store, 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.

Hinweis

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

  1. GKE-Cluster bereitstellen.

  2. Registrieren Sie Ihre Cluster in einer 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 regionsübergreifend 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, mit einer IP-Adresse pro Region, die im Gateway angegeben ist. Der Traffic wird an den nächstgelegenen fehlerfreien Backend-GKE-Cluster weitergeleitet, der die Anfrage verarbeiten kann.

Vorbereitung

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

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

  2. Erstellen Sie GKE-Cluster in verschiedenen Regionen.

    In diesem Beispiel werden zwei Cluster verwendet: gke-west-1 in us-west1 und gke-east-1 in us-east1. Achten Sie darauf, dass die Gateway API aktiviert ist (--gateway-api=standard) und die 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

    Benennen Sie Kontexte um, um den Zugriff zu erleichtern:

    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-Services (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. Konfigurieren Sie Nur-Proxy-Subnetze. 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. Achten Sie darauf, dass die CIDR-Bereiche eindeutig sind und sich nicht überschneiden.

  5. Stellen Sie Ihre Demoanwendungen wie store in beiden Clustern bereit. Die Beispieldatei store.yaml aus gke-networking-recipes erstellt einen store-Namespace und eine Bereitstellung.

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

    Auf gke-west1 anwenden:

    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

    Auf gke-east1 anwenden:

    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 in jedem Cluster im store-Namespace ServiceImport-Ressourcen erstellt wurden. Das kann einige Minuten dauern. 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 GatewayClass gke-l7-cross-regional-internal-managed-mc verweist. Wenden Sie dieses Manifest auf Ihren angegebenen Konfigurationscluster an, z. B. gke-west-1.

Mit dem 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 sein.
    • 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 sitzungsspezifische 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: Hängt diese Route an internal-cross-region-gateway im store-Namespace an.
    • spec.hostnames: Stellt den Hostnamen dar, den Clients verwenden, um auf den Dienst zuzugreifen.
    • spec.rules: Definiert die Routinglogik. In diesem Beispiel wird pfadbasiertes Routing verwendet:
      • Der Traffic für /west wird an store-west-1 ServiceImport weitergeleitet.
      • Der Traffic für /east wird an store-east-1 ServiceImport weitergeleitet.
      • Der gesamte andere Traffic, z. B. /, wird an den generischen store ServiceImport weitergeleitet.
    • backendRefs:
      • group: net.gke.io und kind: ServiceImport zielen auf Multi-Cluster-Dienste ab.

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

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

Status des Gateways und der Route prüfen

  1. Prüfen Sie den Gateway-Status:

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

    Suchen Sie nach einer Bedingung mit type:Programmedandstatus: "True". Im Feld . You should see IP addresses assigned in thestatus.addresses sollten IP-Adressen zugewiesen sein, die den von Ihnen angegebenen Regionen entsprechen (z. B. eine für field, corresponding to the regions you specified (e.g., one forus-west1 und eine für and 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 aus testen, die sich in Ihrem VPC-Netzwerk und in einer der Regionen befindet oder in einer Region, die eine Verbindung zur Gateway-IP-Adresse herstellen kann.

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

    Der folgende Befehl 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

Anstelle von sitzungsspezifischen 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-Standard-Subnetze

Beachten Sie die folgenden Überlegungen, wenn Sie Nicht-Standard-Subnetze verwenden:

  • 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 mit demselben Namen wie das Subnetz haben, 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, müssen die Regionen, für die Sie Adressen anfordern, auch das Subnetz my-custom-subnet haben. 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