Externes Multi-Cluster-Gateway bereitstellen

In diesem Dokument wird anhand eines praktischen Beispiels gezeigt, wie Sie ein externes Multi-Cluster-Gateway bereitstellen, um Internet-Traffic 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.

Externes Multi-Cluster-/Multi-Region-Gateway

In dieser Anleitung erstellen Sie ein externes Multi-Cluster-Gateway, das externen Traffic für eine Anwendung bereitstellt, die in zwei GKE-Clustern ausgeführt wird.

store.example.com wird in zwei GKE-Clustern bereitgestellt und über ein Multi-Cluster-Gateway im Internet freigegeben.

In den nächsten Schritten führen Sie die folgenden Aufgaben aus:

  1. Stellen Sie die store-Beispielanwendung in den Clustern gke-west-1 und gke-east-1 bereit.
  2. Konfigurieren Sie Services auf jedem Cluster, die in Ihre Flotte exportiert werden sollen (Multi-Cluster-Services).
  3. Stellen Sie ein externes Multi-Cluster-Gateway und eine HTTPRoute in Ihrem Konfigurationscluster (gke-west-1) bereit.

Nachdem die Anwendungs- und Gateway-Ressourcen bereitgestellt wurden, können Sie den Traffic zwischen den beiden GKE-Clustern über pfadbasierte Routings steuern:

  • Anfragen an /west werden an store-Pods im gke-west-1-Cluster weitergeleitet.
  • Anfragen an /east werden an store-Pods im gke-east-1-Cluster weitergeleitet.
  • Anfragen an jeden anderen Pfad werden abhängig von ihrem Zustand, ihrer Kapazität und der Nähe zum anfragenden Client an einen der Cluster weitergeleitet.

Demoanwendung bereitstellen

  1. Erstellen Sie das store-Deployment und den Namespace in allen drei Clustern, die unter Umgebung für Multi-Cluster-Gateways vorbereiten bereitgestellt wurden:

    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

    In jedem Cluster werden folgende Ressourcen bereitgestellt:

    namespace/store created
deployment.apps/store created

    Für alle Beispiele auf dieser Seite wird die in diesem Schritt bereitgestellte Anwendung verwendet. Prüfen Sie, ob die Anwendung in allen drei Clustern bereitgestellt wird, bevor Sie einen der verbleibenden Schritte ausführen. In diesem Beispiel werden nur die Cluster gke-west-1 und gke-east-1 verwendet. In einem anderen Beispiel wird gke-west-2 verwendet.

Multi-Cluster-Dienste

Services werden wie Pods für Clients verfügbar gemacht. Da der GKE-Gateway-Controller containernatives Load Balancing verwendet, wird nicht das ClusterIP- oder Kubernetes-Load-Balancing verwendet, um Pods zu erreichen. Der Traffic wird direkt vom Load Balancer an die Pod-IP-Adressen gesendet. Services spielen jedoch weiterhin eine wichtige Rolle als logische Kennzeichnung für die Pod-Gruppierung.

Multi-Cluster-Service (MCS) ist ein API-Standard für Services, die Cluster umfassen. Der zugehörige GKE-Controller stellt Service Discovery in GKE-Clustern bereit. Der Multi-Cluster-Gateway-Controller verwendet MCS-API-Ressourcen, um Pods in einem Service zu gruppieren, der über mehrere Cluster adressierbar ist oder sich über mehrere Cluster erstreckt.

Die Multi-Cluster Services API definiert folgende benutzerdefinierte Ressourcen:

  • ServiceExports werden einem Kubernetes-Dienst zugeordnet und exportieren die Endpunkte dieses Dienstes auf alle Cluster, die für die Flotte registriert sind. Wenn ein Service einen entsprechenden ServiceExport hat, kann er von einem Multi-Cluster-Gateway adressiert werden.
  • ServiceImports werden vom Multi-Cluster-Service-Controller automatisch generiert. ServiceExport und ServiceImport sind paarweise verfügbar. Wenn ein ServiceExport in der Flotte vorhanden ist, wird ein entsprechender ServiceImport erstellt, damit der Service, der dem ServiceExport zugeordnet ist, über alle Cluster zugänglich ist.

Der Export von Services funktioniert auf folgende Weise. In gke-west-1 befindet sich ein Speicher-Service, der eine Gruppe von Pods in diesem Cluster auswählt. Im Cluster wird ein ServiceExport erstellt, durch den die Pods in gke-west-1 von den anderen Clustern in der Flotte zugänglich sind. Der ServiceExport wird Services zugeordnet, die denselben Namen und Namespace wie die ServiceExport-Ressource haben, und macht sie verfügbar.

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

Das folgende Diagramm zeigt, was nach der Bereitstellung eines ServiceExport geschieht. Wenn ein ServiceExport/Service-Paar vorhanden ist, stellt der Multi-Cluster-Service-Controller einen entsprechenden ServiceImport in jedem GKE-Cluster in der Flotte bereit. Der ServiceImport ist die lokale Darstellung des store-Service in jedem Cluster. Dadurch kann der client-Pod in gke-east-1 ClusterIP- oder monitorlose Services verwenden, um die store-Pods in gke-west-1 zu erreichen. Bei dieser Verwendungsart bieten Multi-Cluster-Services ein Ost-West-Load-Balancing zwischen Clustern, ohne einen internen LoadBalancer-Service zu erfordern. Informationen zum Verwenden von Multi-Cluster-Services für Cluster-zu-Cluster-Load-Balancing finden Sie unter Multi-Cluster-Services konfigurieren.

Multi-Cluster-Services exportieren Services über Cluster, wodurch die Cluster-zu-Cluster-Kommunikation ermöglicht wird

Multi-Cluster-Gateways verwenden auch ServiceImports, jedoch nicht für das Cluster-zu-Cluster-Load-Balancing. Stattdessen verwenden Gateways ServiceImports als logische Kennzeichnungen für einen Service, der in einem anderen Cluster vorhanden ist oder sich über mehrere Cluster erstreckt. Die folgende HTTPRoute verweist auf eine ServiceImport-Ressource statt auf eine Service-Ressource. Durch Verweisen auf einen ServiceImport wird angegeben, dass der Traffic an eine Gruppe von Backend-Pods weitergeleitet wird, die in einem oder mehreren Clustern ausgeführt werden.

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

Das folgende Diagramm zeigt, wie die HTTPRoute store.example.com-Traffic zu store-Pods in gke-west-1 und gke-east-1 weiterleitet. Der Load-Balancer behandelt sie als einen einzigen Pool von Back-Ends. Wenn die Pods aus einem der Cluster fehlerhaft werden, nicht mehr erreichbar sind oder keine Traffic-Kapazität haben, wird die Traffic-Last auf die verbleibenden Pods im anderen Cluster verteilt. Neue Cluster können mit dem store-Service und -ServiceExport hinzugefügt oder entfernt werden. Dadurch werden Backend-Pods transparent ohne explizite Routingkonfigurationsänderungen hinzugefügt oder entfernt.

MCS-Ressource

Services exportieren

An diesem Punkt wird die Anwendung in beiden Clustern ausgeführt. Als Nächstes machen Sie die Anwendungen verfügbar und exportieren sie, wozu Sie Services und ServiceExports in jedem Cluster bereitstellen.

  1. Wenden Sie das folgende Manifest auf den Cluster gke-west-1 an, um die Services und ServiceExports store und store-west-1 zu erstellen.

    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. Wenden Sie das folgende Manifest auf den Cluster gke-east-1 an, um die Services und ServiceExports store und store-east-1 zu erstellen.

    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. Prüfen Sie, ob im Cluster die richtigen ServiceExports erstellt wurden.

    kubectl get serviceexports --context CLUSTER_NAME --namespace store

    Ersetzen Sie CLUSTER_NAME durch gke-west-1 und gke-east-1. Die Ausgabe sollte so aussehen:

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

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

    Die Ausgabe zeigt, dass der store-Service in beiden Clustern store-Pods enthält, während die store-west-1- und store-east-1-Services in den jeweiligen Clustern nur store-Pods enthalten. Diese sich überschneidenden Services werden verwendet, um die Pods auf mehrere Cluster oder eine Teilmenge von Pods in einem einzelnen Cluster auszurichten.

  4. Prüfen Sie nach einigen Minuten, ob die zugehörigen ServiceImports vom Multi-Cluster-Services-Controller automatisch in allen Clustern der Flotte erstellt wurden.

    kubectl get serviceimports --context CLUSTER_NAME --namespace store

    Ersetzen Sie CLUSTER_NAME durch gke-west-1 und gke-east-1. Die Ausgabe sollte in etwa so aussehen:

    # 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

    Dies zeigt, dass auf alle drei Services von beiden Clustern in der Flotte aus zugegriffen werden kann. Da es jedoch nur einen aktiven Konfigurationscluster pro Flotte gibt, können Sie nur Gateways und HTTPRoutes bereitstellen, die in gke-west-1 auf diese ServiceImports verweisen. Wenn eine HTTPRoute im Konfigurationscluster auf diese ServiceImports als Back-Ends verweist, kann das Gateway Traffic an diese Services weiterleiten, unabhängig davon, aus welchem Cluster sie exportiert wurden.

Gateway und HTTPRoute bereitstellen

Wenn die Anwendungen bereitgestellt wurden, können Sie ein Gateway mithilfe der GatewayClass gke-l7-global-external-managed-mc konfigurieren. Dieses Gateway erstellt einen externen Application Load Balancer, der so konfiguriert ist, dass der Traffic auf Ihre Zielcluster verteilt wird.

  1. Wenden Sie das folgende Gateway-Manifest auf den Konfigurationscluster gke-west-1 in diesem Beispiel an:

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

    Diese Gateway-Konfiguration stellt externe Application-Load-Balancer-Ressourcen mit der folgenden Namenskonvention bereit: gkemcg1-NAMESPACE-GATEWAY_NAME-HASH.

    Die bei dieser Konfiguration erstellten Standardressourcen:

    • 1 Load Balancer: gkemcg1-store-external-http-HASH
    • 1 öffentliche IP-Adresse: gkemcg1-store-external-http-HASH
    • 1 Weiterleitungsregel: gkemcg1-store-external-http-HASH
    • 2 backend services:
      • Standard-Backend-Dienst 404: gkemcg1-store-gw-serve404-HASH
      • Standard-Backend-Dienst 500: gkemcg1-store-gw-serve500-HASH
    • 1 Systemdiagnose:
      • Standard-Systemdiagnose 404: gkemcg1-store-gw-serve404-HASH
    • 0 Weiterleitungsregeln (URL-Map ist leer)

    In dieser Phase führt jede Anfrage an GATEWAY_IP:80 zu einer Standardseite mit der folgenden Meldung: fault filter abort.

  2. Wenden Sie das folgende HTTPRoute-Manifest auf den Konfigurationscluster gke-west-1 in diesem Beispiel an:

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

    In dieser Phase führt jede Anfrage an GATEWAY_IP:80 zu einer Standardseite mit der folgenden Meldung: fault filter abort.

    Nach der Bereitstellung konfiguriert diese HTTPRoute folgendes Routingverhalten:

    • Anfragen an /west werden an store-Pods im gke-west-1-Cluster weitergeleitet, da Pods, die vom ServiceExport store-west-1 ausgewählt wurden, nur im gke-west-1-Cluster vorhanden sind.
    • Anfragen an /east werden an store-Pods im gke-east-1-Cluster weitergeleitet, da Pods, die vom ServiceExport store-east-1 ausgewählt wurden, nur im gke-east-1-Cluster vorhanden sind.
    • Anfragen an jeden anderen Pfad werden abhängig von ihrem Zustand, ihrer Kapazität und der Nähe zum anfragenden Client an store-Pods in einem der Cluster weitergeleitet.
    • Anfragen an GATEWAY_IP:80 führen zu einer Standardseite mit der folgenden Meldung: fault filter abort.

    HTTPRoute ermöglicht das Routing an verschiedene Teilmengen von Clustern durch den Einsatz von sich überschneidenden Diensten.

    Wenn alle Pods in einem bestimmten Cluster fehlerhaft oder nicht vorhanden sind, wird der Traffic zum store-Service nur an Cluster gesendet, die tatsächlich store-Pods haben. Wenn ein ServiceExport und Service in einem bestimmten Cluster vorhanden sind, wird dadurch nicht garantiert, dass Traffic an diesen Cluster gesendet wird. Pods müssen vorhanden sein und positiv auf die Systemdiagnose des Load-Balancers reagieren. Andernfalls sendet der Load-Balancer Traffic an fehlerfreie store-Pods in anderen Clustern.

    Mit dieser Konfiguration werden neue Ressourcen erstellt:

    • 3 backend services:
      • Der store-Backend-Dienst: gkemcg1-store-store-8080-HASH
      • Der store-east-1-Backend-Dienst: gkemcg1-store-store-east-1-8080-HASH
      • Der store-west-1-Backend-Dienst: gkemcg1-store-store-west-1-8080-HASH
    • 3 Systemdiagnosen:
      • Die store-Systemdiagnose: gkemcg1-store-store-8080-HASH
      • Die store-east-1-Systemdiagnose: gkemcg1-store-store-east-1-8080-HASH
      • Die store-west-1-Systemdiagnose: gkemcg1-store-store-west-1-8080-HASH
    • 1 Routingregel in der URL-Zuordnung:
      • Die store.example.com-Routingregel:
      • 1 Host: store.example.com
      • Mehrere matchRules zur Weiterleitung an die neuen Backend-Dienste

Das folgende Diagramm zeigt die Ressourcen, die Sie in beiden Clustern bereitgestellt haben. Da gke-west-1 der Gateway-Konfigurationscluster ist, ist er der Cluster, in dem unser Gateway, die HTTPRoutes und die ServiceImports vom Gateway-Controller überwacht werden. Jeder Cluster hat einen store-ServiceImport und einen weiteren ServiceImport, der für diesen Cluster spezifisch ist. Beide verweisen auf dieselben Pods. Damit kann mit der HTTPRoute genau angegeben werden, wohin der Traffic geht – zu den store-Pods in einem bestimmten Cluster oder zu den store-Pods in allen Clustern.

Dies ist das Gateway- und Multi-Cluster-Service-Ressourcenmodell für beide Cluster

Beachten Sie, dass dies ein logisches Ressourcenmodell und keine Darstellung des Trafficflusses ist. Der Trafficpfad führt direkt vom Load Balancer zu den Backend-Pods und hat keine direkte Beziehung zu dem Cluster, der der Konfigurationscluster ist.

Bereitstellung prüfen

Sie können nun Anfragen an unser Multi-Cluster-Gateway senden und den Traffic auf beide GKE-Cluster verteilen.

  1. Rufen Sie den Gateway-Status und die Ereignisse auf, um zu prüfen, ob das Gateway und die HTTPRoute erfolgreich bereitgestellt wurden.

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

    Die Ausgabe sollte in etwa so aussehen:

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

  2. Sobald das Gateway bereitgestellt wurde, rufen Sie die externe IP-Adresse vom external-http-Gateway ab.

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

    Ersetzen Sie VIP in den folgenden Schritten durch die IP-Adresse, die Sie als Ausgabe erhalten.

  3. Senden Sie Traffic an den Stammpfad der Domain. Dadurch wird der Traffic auf den store-ServiceImport verteilt, der sich in den Clustern gke-west-1 und gke-east-1 befindet. Der Load-Balancer sendet den Traffic an die nächstgelegene Region und Sie sehen möglicherweise keine Antworten aus der anderen Region.

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

    Die Ausgabe bestätigt, dass die Anfrage vom Pod aus dem Cluster gke-east-1 bereitgestellt wurde:

    {
  "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. Als Nächstes senden Sie Traffic an den Pfad /west. Dadurch wird der Traffic an den ServiceImport store-west-1 weitergeleitet, der nur Pods im Cluster gke-west-1 ausführt. Ein clusterspezifischer ServiceImport wie store-west-1 ermöglicht einem Anwendungsinhaber, Traffic explizit an einen bestimmten Cluster zu senden, statt die Entscheidung dem Load Balancer zu überlassen.

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

    Die Ausgabe bestätigt, dass die Anfrage vom Pod aus dem Cluster gke-west-1 bereitgestellt wurde:

    {
  "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. Senden Sie nun Traffic an den Pfad /east.

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

    Die Ausgabe bestätigt, dass die Anfrage vom Pod aus dem Cluster gke-east-1 bereitgestellt wurde:

    {
  "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"
}

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

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