Ingress-Ressource clusterübergreifend bereitstellen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite wird gezeigt, wie Sie eine Ingress-Ressource für eine Anwendung in mehreren GKE-Clustern bereitstellen. Weitere Informationen zu Multi-Cluster-Ingress finden Sie unter Multi-Cluster-Ingress.

Anleitung zum Deployment

In den folgenden Aufgaben stellen Sie eine fiktive Anwendung namens whereami und MultiClusterIngress in zwei Clustern bereit. Die Ingress-Ressource bietet eine gemeinsam genutzte virtuelle IP-Adresse (VIP) für die Anwendungs-Deployments.

Diese Seite baut auf der Arbeit unter Multi-Cluster-Ingress einrichten auf, in der Sie zwei Cluster erstellt und registriert haben. Prüfen Sie, ob Sie zwei Cluster haben, die auch bei einer Flotte registriert sind:

gcloud container clusters list

Die entsprechende Ausgabe sieht etwa so aus:

NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-b  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-b   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

Namespace erstellen

Da Flotten das Attribut der Namespace-Gleichheit haben, sollten Sie das Erstellen und Verwalten von Namespaces für die Cluster so koordinieren, dass identische Namespaces zur selben Gruppe gehören und von dieser verwaltet werden. Sie haben die Möglichkeit, Namespaces pro Team, pro Umgebung, pro Anwendung oder pro Anwendungskomponente zu erstellen. Namespaces können so detailliert wie nötig sein, solange ein Namespace ns1 in dem einen Cluster die gleiche Bedeutung wie ns1 in einem anderen Cluster hat und dort genauso genutzt wird.

In diesem Beispiel erstellen Sie für jede Anwendung in jedem Cluster einen whereami-Namespace.

  1. Erstellen Sie eine Datei namens namespace.yaml mit folgendem Inhalt:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: whereami
    
  2. Wechseln Sie zum gke-us-Kontext:

    kubectl config use-context gke-us
    
  3. Erstellen Sie den Namespace:

    kubectl apply -f namespace.yaml
    
  4. Wechseln Sie zum gke-eu-Kontext:

    kubectl config use-context gke-eu
    
  5. Erstellen Sie den Namespace:

    kubectl apply -f namespace.yaml
    

    Die entsprechende Ausgabe sieht etwa so aus:

    namespace/whereami created
    

Anwendung bereitstellen

  1. Erstellen Sie eine Datei namens deploy.yaml mit folgendem Inhalt:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: whereami-deployment
      namespace: whereami
      labels:
        app: whereami
    spec:
      selector:
        matchLabels:
          app: whereami
      template:
        metadata:
          labels:
            app: whereami
        spec:
          containers:
          - name: frontend
            image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.9
            ports:
            - containerPort: 8080
    
  2. Wechseln Sie zum gke-us-Kontext:

    kubectl config use-context gke-us
    
  3. Stellen Sie die whereami-Anwendung bereit:

    kubectl apply -f deploy.yaml
    
  4. Wechseln Sie zum gke-eu-Kontext:

    kubectl config use-context gke-eu
    
  5. Stellen Sie die whereami-Anwendung bereit:

    kubectl apply -f deploy.yaml
    
  6. Prüfen Sie, ob die whereami-Anwendung in jedem Cluster erfolgreich bereitgestellt wurde:

    kubectl get deployment --namespace whereami
    

    Die Ausgabe sollte in beiden Clustern in etwa so aussehen:

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    whereami-deployment   1/1     1            1           12m
    

Über den Konfigurationscluster bereitstellen

Nachdem die Anwendung in gke-us und gke-eu bereitgestellt wurde, stellen Sie einen Load-Balancer über die Ressourcen MultiClusterIngress und MultiClusterService im Konfigurationscluster bereit. Dies sind die Multi-Cluster-Entsprechungen für Ingress- und Service-Ressourcen.

Im Einrichtungsleitfaden haben Sie den gke-us-Cluster als Konfigurationscluster konfiguriert. Der Konfigurationscluster wird zum Bereitstellen und Konfigurieren von Ingress-Ressourcen in allen Clustern verwendet.

  1. Legen Sie den Konfigurationscluster als Kontext fest.

    kubectl config use-context gke-us
    

MultiClusterService

  1. Erstellen Sie eine Datei namens mcs.yaml mit folgendem Inhalt:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: whereami-mcs
      namespace: whereami
    spec:
      template:
        spec:
          selector:
            app: whereami
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
    
  2. Stellen Sie die MultiClusterService-Ressource bereit, die der whereami-Anwendung entspricht:

    kubectl apply -f mcs.yaml
    
  3. Prüfen Sie, ob die whereami-mcs-Ressource erfolgreich im Konfigurationscluster bereitgestellt wurde:

    kubectl get mcs -n whereami
    

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME       AGE
    whereami-mcs   9m26s
    

    Dieser MultiClusterService erstellt in jedem Cluster, der Pods mit app: whereami abgleicht, einen abgeleiteten monitorlosen Service. Sie können nun sehen, dass im gke-us-Cluster kubectl get service -n whereami ein solcher Service vorhanden ist:

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
    mci-whereami-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s
    

In gke-eu gibt es einen ähnlichen monitorlosen Dienst. Diese lokalen Dienste werden verwendet, um Pod-Endpunkte dynamisch auszuwählen und dadurch die globalen Ingress-Load-Balancer mit Back-Ends zu programmieren.

MultiClusterIngress

  1. Erstellen Sie eine Datei namens mci.yaml mit folgendem Inhalt:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: whereami-ingress
      namespace: whereami
    spec:
      template:
        spec:
          backend:
            serviceName: whereami-mcs
            servicePort: 8080
    

    Beachten Sie, dass diese Konfiguration den gesamten Traffic zur MultiClusterService-Ressource namens whereami-mcs leitet, die im whereami-Namespace vorhanden ist.

  2. Stellen Sie die MultiClusterIngress-Ressource, die auf whereami-mcs verweist, als Back-End bereit:

    kubectl apply -f mci.yaml
    

    Die entsprechende Ausgabe sieht etwa so aus:

    multiclusteringress.networking.gke.io/whereami-ingress created
    

    Beachten Sie, dass die MultiClusterIngress-Ressource das gleiche Schema wie die Kubernetes-Ingress-Ressource hat. Auch die Semantik der Ingress-Ressource ist bis auf das Feld backend.serviceName identisch.

Das Feld backend.serviceName in einer MultiClusterIngress-Ressource verweist auf eine MultiClusterService-Ressource in der Fleet API und nicht auf einen Dienst in einem Kubernetes-Cluster. Dies bedeutet, dass alle Einstellungen für die Ingress-Ressource, z. B. die TLS-Beendigung, auf die gleiche Weise konfiguriert werden können.

Deployment auf Erfolg prüfen

Das Deployment eines neuen Google Cloud-Load-Balancers kann einige Minuten dauern. Das Aktualisieren vorhandener Load-Balancer erfolgt schneller, da keine neuen Ressourcen bereitgestellt werden müssen. Die MultiClusterIngress-Ressource beschreibt die zugrunde liegenden Compute Engine-Ressourcen, die im Auftrag der MultiClusterIngress-Ressource erstellt wurden.

  1. Prüfen Sie, ob das Deployment erfolgreich war:

    kubectl describe mci whereami-ingress -n whereami
    

    Die entsprechende Ausgabe sieht etwa so aus:

    Name:         whereami-ingress
    Namespace:    whereami
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"whereami-ingress","namespace":"whe...
    API Version:  networking.gke.io/v1
    Kind:         MultiClusterIngress
    Metadata:
      Creation Timestamp:  2020-04-10T23:35:10Z
      Finalizers:
        mci.finalizer.networking.gke.io
      Generation:        2
      Resource Version:  26458887
      Self Link:         /apis/networking.gke.io/v1/namespaces/whereami/multiclusteringresses/whereami-ingress
      UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
    Spec:
      Template:
        Spec:
          Backend:
            Service Name:  whereami-mcs
            Service Port:  8080
    Status:
      Cloud Resources:
        Backend Services:
          mci-8se3df-8080-whereami-whereami-mcs
        Firewalls:
          mci-8se3df-default-l7
        Forwarding Rules:
          mci-8se3df-fw-whereami-whereami-ingress
        Health Checks:
          mci-8se3df-8080-whereami-whereami-mcs
        Network Endpoint Groups:
          zones/europe-west1-b/networkEndpointGroups/k8s1-e4adffe6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-88670678
          zones/us-central1-b/networkEndpointGroups/k8s1-a6b112b6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-609ab6c6
        Target Proxies:
          mci-8se3df-whereami-whereami-ingress
        URL Map:  mci-8se3df-whereami-whereami-ingress
      VIP:        34.98.102.37
    Events:
      Type    Reason  Age                    From                              Message
      ----    ------  ----                   ----                              -------
      Normal  ADD     3m35s                  multi-cluster-ingress-controller  whereami/whereami-ingress
      Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  whereami/whereami-ingress
    

    Es gibt mehrere Felder, die den Status dieses Ingress-Deployments wiedergeben:

    • Events ist das erste Feld, das geprüft werden sollte. Ein eventueller Fehler ist hier aufgeführt.

    • Cloud Resource listet die Compute Engine-Ressourcen wie Weiterleitungsregeln, Back-End-Dienste und Firewallregeln auf, die vom Multi-Cluster-Ingress-Controller erstellt wurden. Wenn sie nicht aufgeführt sind, wurden sie noch nicht erstellt. Sie können einzelne Compute Engine-Ressourcen mit der Console oder mit dem Befehl gcloud prüfen, um ihren Status zu ermitteln.

    • VIP listet eine IP-Adresse auf, wenn eine solche zugewiesen wurde. Beachten Sie, dass der Load-Balancer möglicherweise noch keinen Traffic verarbeitet, obwohl die VIP vorhanden ist. Wenn nach einigen Minuten keine VIP angezeigt wird oder der Load-Balancer innerhalb von 10 Minuten keine 200-Antwort ausgibt, finden Sie entsprechende Informationen unter Fehlerbehebung und Vorgänge.

    Wenn die Ausgabeereignisse den Status Normal haben, ist die MultiClusterIngress-Bereitstellung wahrscheinlich erfolgreich. Ob der vollständige Trafficpfad funktioniert, können Sie aber nur durch Testen ermitteln.

  2. Prüfen Sie, ob die Anwendung unter der VIP mit dem Endpunkt /ping bereitgestellt wird:

    curl INGRESS_VIP/ping
    

    Ersetzen Sie INGRESS_VIP durch die virtuelle IP-Adresse (VIP).

    Die entsprechende Ausgabe sieht etwa so aus:

    {
    "cluster_name": "gke-us",
    "host_header": "34.120.175.141",
    "pod_name": "whereami-deployment-954cbf78-mtlpf",
    "pod_name_emoji": "😎",
    "project_id": "my-project",
    "timestamp": "2021-11-29T17:01:59",
    "zone": "us-central1-b"
    }
    

    In der Ausgabe sollten die Region und das Back-End der Anwendung angegeben sein.

  3. Sie können auch die URL http://INGRESS_VIP in Ihrem Browser aufrufen, um eine grafische Version der Anwendung darzustellen. In dieser Version wird die Region angezeigt, aus der die Anwendung bereitgestellt wird.

    Der Cluster, an den der Traffic weitergeleitet wird, hängt von Ihrem Standort ab. Der Google Cloud-Load-Balancer hat die Aufgabe, den Clienttraffic an das nächstgelegene verfügbare Back-End mit ausreichender Kapazität weiterzuleiten.

Ressourcenspezifikationen

MultiClusterService-Spezifikation

Die MultiClusterService-Definition besteht aus zwei Teilen:

  1. Aus einem template-Abschnitt, der den Dienst definiert, der in den Kubernetes-Clustern erstellt werden soll. Der Abschnitt template enthält Felder, die in einem typischen Dienst unterstützt werden. In einem MultiClusterService werden jedoch nur zwei Felder unterstützt: selector und ports. Die anderen werden ignoriert.

  2. Aus einem optionalen clusters-Abschnitt, der definiert, welche Cluster Traffic empfangen, und der angibt, welche Load-Balancer-Attribute für jeden Cluster gelten. Wenn kein clusters-Abschnitt angegeben ist oder wenn keine Cluster aufgelistet sind, werden standardmäßig alle Cluster verwendet.

Das folgende Manifest beschreibt einen Standard-MultiClusterService:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      selector:
        app: POD_LABEL
      ports:
      - name: web
        protocol: TCP
        port: PORT
        targetPort: TARGET_PORT

Dabei gilt:

  • NAME ist der Name des MultiClusterService. Auf diesen Namen verweist das Feld serviceName in den MultiClusterIngress-Ressourcen.
  • NAMESPACE ist der Kubernetes-Namespace, in dem der MultiClusterService bereitgestellt wird. Dieser muss sich im selben Namespace wie die MultiClusterIngress und die Pods in allen Clustern der Umgebung befinden.
  • POD_LABEL ist das Label, das bestimmt, welche Pods als Back-Ends für diesen MultiClusterService in allen Clustern der Flotte ausgewählt werden.
  • PORT muss mit dem Port übereinstimmen, auf den der MultiClusterIngress verweist, der auf diesen MultiClusterService verweist.
  • TARGET_PORT ist der Port, über den Traffic von der GCLB an den Pod gesendet wird. In jedem Cluster wird eine Netzwerk-Endpunktgruppe mit diesem Port als Bereitstellungsport erstellt.

MultiClusterIngress-Spezifikation

Die folgende Datei mci.yaml beschreibt das Load-Balancer-Front-End:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  template:
    spec:
      backend:
       serviceName: DEFAULT_SERVICE
       servicePort: PORT
      rules:
        - host: HOST_HEADER
          http:
            paths:
            - path: PATH
              backend:
                serviceName: SERVICE
                servicePort: PORT

Dabei gilt:

  • NAME ist der Name der MultiClusterIngress-Ressource.
  • NAMESPACE ist der Kubernetes-Namespace, in dem der MultiClusterIngress bereitgestellt wird. Dieser muss sich im selben Namespace wie die der MultiClusterService und die Pods in allen Clustern der Flotte befinden.
  • DEFAULT_SERVICE dient als Standard-Back-End für den gesamten Traffic, der keinen Host- oder Pfadregeln entspricht. Dies ist ein Pflichtfeld. Ein Standard-Back-End muss für den MultiClusterIngress auch dann angegeben werden, wenn andere Host- oder Pfadübereinstimmungen konfiguriert sind.
  • PORT: eine beliebige gültige Portnummer. Diese muss mit dem Feld port der MultiClusterService-Ressourcen übereinstimmen.
  • HOST_HEADER gleicht Traffic anhand des HTTP-Host-Header-Felds ab. Das Feld host ist optional.
  • PATH gleicht Traffic anhand des Pfads der HTTP-URL ab. Das Feld path ist optional.
  • SERVICE ist der Name eines MultiClusterService, der im selben Namespace und Konfigurationscluster wie dieser MultiClusterIngress bereitgestellt wird.

Multi-Cluster-Ingress-Features

In diesem Abschnitt erfahren Sie, wie Sie zusätzliche Multi-Cluster-Ingress-Features konfigurieren.

Clusterauswahl

Standardmäßig sind Dienste, die von Multi-Cluster-Ingress abgeleitet sind, in jedem Mitgliedscluster geplant. Sie können jedoch auf bestimmte Cluster Regeln für eingehenden Traffic anwenden. Im Folgenden sind einige Anwendungsfälle aufgeführt:

  • Anwenden von Multi-Cluster-Ingress auf alle Cluster mit Ausnahme des Konfigurationsclusters, um den Konfigurationscluster zu isolieren
  • Ausführen der Blau/Grün-Migration von Arbeitslasten zwischen Clustern
  • Einrichten des Routings zu Anwendungs-Back-Ends, die nur in einem Teil der Cluster vorhanden sind
  • Verwenden einer einzelnen L7-VIP für das Host-/Pfad-Routing zu Back-Ends, die sich in verschiedenen Clustern befinden

Mit der Clusterauswahl können Sie Cluster nach Region/Name im MultiClusterService-Objekt festlegen. Damit wird angegeben, auf welche Cluster der MultiClusterIngress verweist und wo die abgeleiteten Dienste geplant werden. Cluster innerhalb derselben Flotte und derselben Region sollten nicht denselben Namen haben, damit Cluster eindeutig referenziert werden können.

  1. mcs.yaml öffnen

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: whereami-mcs
      namespace: whereami
    spec:
      template:
        spec:
          selector:
            app: whereami
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
    

    Von dieser Spezifikation werden derzeit in allen Clustern abgeleitete Dienste erstellt. Dies ist das Standardverhalten.

  2. Hängen Sie im Abschnitt "clusters" die folgenden Zeilen an:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: whereami-mcs
      namespace: whereami
    spec:
      template:
        spec:
          selector:
            app: whereami
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
      clusters:
      - link: "us-central1-b/gke-us"
      - link: "europe-west1-b/gke-eu"
    

    In diesem Beispiel werden abgeleitete Dienstressourcen nur in den gke-us- und gke-eu-Clustern erstellt. Um selektiv Regeln für eingehenden Traffic anzuwenden, müssen Sie Cluster auswählen. Wenn der Abschnitt "clusters" der MultiClusterService-Ressource nicht angegeben ist oder darin keine Cluster aufgeführt sind, werden standardmäßig alle Cluster verwendet.

HTTPS-Unterstützung

Das Kubernetes-Secret unterstützt HTTPS. Bevor Sie die HTTPS-Unterstützung aktivieren, müssen Sie eine statische IP-Adresse erstellen. Diese statische IP-Adresse bietet die Möglichkeit, dass HTTP und HTTPS die gleiche IP-Adresse verwenden. Weitere Informationen finden Sie unter Statische IP-Adresse erstellen.

Nachdem Sie eine statische IP-Adresse erstellt haben, können Sie ein Secret anlegen.

  1. Erstellen Sie ein Secret:

    kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE
    

    Dabei gilt:

    • SECRET_NAME der Namen Ihres Secrets.
    • PATH_TO_KEYFILE der Pfad zur TLS-Schlüsseldatei.
    • PATH_TO_CERTFILE der Pfad zur TLS-Zertifikatsdatei.
  2. Aktualisieren Sie die Datei mci.yaml mit dem Secret-Namen:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: whereami-ingress
      namespace: whereami
      annotations:
        networking.gke.io/static-ip: STATIC_IP_ADDRESS
    spec:
      template:
        spec:
          backend:
            serviceName: whereami-mcs
            servicePort: 8080
          tls:
          - secretName: SECRET_NAME
    

    Ersetzen Sie SECRET_NAME durch den Namen Ihres Secrets. Der STATIC_IP_ADDRESS ist die IP-Adresse oder die vollständige URL der Adresse, die Sie im Abschnitt Statische IP-Adresse erstellen zugewiesen haben.

  3. Stellen Sie die Ressource MultiClusterIngress noch einmal bereit:

    kubectl apply -f mci.yaml
    

    Die entsprechende Ausgabe sieht etwa so aus:

    multiclusteringress.networking.gke.io/whereami-ingress configured
    

BackendConfig-Unterstützung

Mit der BackendConfig-CRD können Sie Einstellungen für die Compute Engine-BackendService-Ressource anpassen. Beispielsweise wird folgende Spezifikation unterstützt:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: whereami-health-check-cfg
  namespace: whereami
spec:
  healthCheck:
    checkIntervalSec: [int]
    timeoutSec: [int]
    healthyThreshold: [int]
    unhealthyThreshold: [int]
    type: [HTTP | HTTPS | HTTP2 | TCP]
    port: [int]
    requestPath: [string]
  timeoutSec: [int]
  connectionDraining:
    drainingTimeoutSec: [int]
  sessionAffinity:
    affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
    affinityCookieTtlSec: [int]
  cdn:
    enabled: [bool]
    cachePolicy:
      includeHost: [bool]
      includeQueryString: [bool]
      includeProtocol: [bool]
      queryStringBlacklist: [string list]
      queryStringWhitelist: [string list]
  securityPolicy:
    name: ca-how-to-security-policy
  logging:
    enable: [bool]
    sampleRate: [float]
  iap:
    enabled: [bool]
    oauthclientCredentials:
      secretName: [string]

Zum Verwenden von BackendConfig hängen Sie diese mit einer Annotation an die MultiClusterService-Ressource an:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
  annotations:
    cloud.google.com/backend-config: '{"ports": {"8080":"whereami-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: whereami
     ports:
     - name: web
       protocol: TCP
       port: 8080
       targetPort: 8080

Weitere Informationen zur BackendConfig-Semantik finden Sie unter Dienstport einem BackendConfig-Objekt zuordnen.

gRPC-Unterstützung

Die Konfiguration von gRPC-Anwendungen auf Multi-Cluster-Ingress erfordert eine besondere Einrichtung. Im Folgenden finden Sie einige Tipps, um sicherzustellen, dass der Load-Balancer richtig konfiguriert ist:

  1. Achten Sie darauf, dass der Traffic vom Load-Balancer zu Ihrer Anwendung HTTP/2 lautet. Verwenden Sie Anwendungsprotokolle, um dies zu konfigurieren.
  2. Achten Sie darauf, dass Ihre Anwendung ordnungsgemäß für SSL konfiguriert ist, da dies eine Anforderung von HTTP/2 ist. Die Verwendung selbst signierter Zertifikate ist zulässig.
  3. Sie müssen mTLS für die Anwendung deaktivieren, da mTLS für externe 7-Load-Balancer nicht unterstützt wird.

Ressourcenlebenszyklus

Konfigurationsänderungen

Die Ressourcen MultiClusterIngress und MultiClusterService verhalten sich wie Standard-Kubernetes-Objekte, sodass Änderungen an den Objekten asynchron im System wiedergegeben werden. Alle Änderungen, die zu einer ungültigen Konfiguration führen, haben zur Folge, dass verknüpfte Google Cloud-Objekte unverändert bleiben. Sie lösen dann einen Fehler im Objektereignis-Stream aus. Fehler im Zusammenhang mit der Konfiguration werden als Ereignisse gemeldet.

Kubernetes-Ressourcen verwalten

Durch das Löschen des Ingress-Objekts wird der HTTP(S)-Load-Balancer heruntergefahren, sodass der Traffic nicht mehr an eine definierte MultiClusterService-Ressource weitergeleitet wird.

Durch Löschen der MultiClusterService-Ressource werden die zugehörigen abgeleiteten Dienste in jedem Cluster entfernt.

Cluster verwalten

Der Satz von Clustern, auf den der Load-Balancer angewendet wird, kann durch Hinzufügen oder Entfernen von Clustern aus der Flotte geändert werden.

Wenn Sie beispielsweise den gke-eu-Cluster als Back-End für eine Ingress-Ressource entfernen möchten, führen Sie folgenden Befehl aus:

gcloud container fleet memberships unregister CLUSTER_NAME \
  --gke-uri=URI

Dabei gilt:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • URI ist der URI des GKE-Clusters.

Um beispielsweise einen Cluster in Europa hinzuzufügen, führen Sie folgenden Befehl aus:

gcloud container fleet memberships register europe-cluster \
  --context=europe-cluster --enable-workload-identity

Weitere Informationen zu Clusterregistrierungsoptionen finden Sie unter GKE-Cluster registrieren.

Beachten Sie, dass sich durch das Registrieren oder Aufheben der Registrierung eines Clusters sein Status als Back-End für alle Ingress-Ressourcen ändert. Im obigen Fall wird der gke-eu-Cluster durch das Aufheben der Registrierung als verfügbares Back-End für alle von Ihnen erstellten Ingress-Ressourcen entfernt. Für das Registrieren eines neuen Clusters gilt dann umgekehrt das Gleiche.

Multi-Cluster-Ingress deaktivieren

Bevor Sie Multi-Cluster-Ingress deaktivieren, müssen Sie zuerst die Ressourcen MultiClusterIngress und MultiClusterService löschen und alle zugehörigen Netzwerkressourcen löschen.

Deaktivieren Sie Multi Cluster Ingress dann mit dem folgenden Befehl:

gcloud container fleet ingress disable

Wenn Sie die Ressourcen MultiClusterIngress und MultiClusterService vor dem Deaktivieren von Multi-Cluster-Ingress nicht löschen, kann ein Fehler wie der folgende auftreten:

Feature has associated resources that should be cleaned up before deletion.

Wenn Sie die Deaktivierung des Multi-Cluster-Ingress erzwingen möchten, verwenden Sie den folgenden Befehl:

gcloud container fleet ingress disable --force

Annotationen

Die folgenden Annotationen werden für MultiClusterIngress- und MultiClusterService-Ressourcen unterstützt.

MultiClusterIngress-Annotationen

Annotation Beschreibung
networking.gke.io/frontend-config Verweist auf eine FrontendConfig-Ressource im selben Namespace wie die MultiClusterIngress-Ressource.
networking.gke.io/static-ip Bezieht sich auf die literale IP-Adresse einer globalen statischen IP-Adresse.
networking.gke.io/pre-shared-certs Bezieht sich auf eine globale SSLCertificate-Ressource.

MultiClusterService-Annotationen

Annotation Beschreibung
networking.gke.io/app-protocols Mit dieser Annotation können Sie das Protokoll für die Kommunikation zwischen dem Load-Balancer und der Anwendung festlegen. Die Protokolle HTTP, HTTPS und HTTP/2 stehen zur Wahl. Weitere Informationen finden Sie unter HTTPS zwischen Load-Balancer und Ihrer Anwendung und HTTP/2 für Load-Balancing mit Ingress.
cloud.google.com/backend-config Mit dieser Annotation können Sie den einem ServicePort zugeordneten Back-End-Dienst konfigurieren. Weitere Informationen finden Sie unter Ingress-Features.

SSL-Richtlinien und HTTPS-Weiterleitungen

Sie können die FrontendConfig-Ressource verwenden, um SSL-Richtlinien und HTTPS-Weiterleitungen zu konfigurieren. Mit SSL-Richtlinien können Sie angeben, welche Cipher Suites und TLS-Versionen vom Load-Balancer akzeptiert werden. Mit HTTPS-Weiterleitungen können Sie die Weiterleitung von HTTP/Port 80 zu HTTPS/Port 443 erzwingen. In den folgenden Schritten werden eine SSL-Richtlinie und eine HTTPS-Weiterleitung zusammen konfiguriert. Sie können auch unabhängig voneinander konfiguriert werden.

  1. Erstellen Sie eine SSL-Richtlinie, die Anfragen mit einer niedrigeren Version als TLS v1.2 ablehnt.

    gcloud compute ssl-policies create tls-12-policy \
     --profile MODERN \
     --min-tls-version 1.2 \
     --project=PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die Projekt-ID, auf der die GKE-Cluster ausgeführt werden.

  2. Prüfen Sie, ob die Richtlinie erstellt wurde.

    gcloud compute ssl-policies list --project=PROJECT_ID
    

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME           PROFILE  MIN_TLS_VERSION
    tls-12-policy  MODERN   TLS_1_2
    
  3. Erstellen Sie ein Zertifikat für foo.example.com wie in diesem Beispiel. Sobald Sie key.pem und cert.pem haben, speichern Sie diese Anmeldeinformationen als Secret, auf das die MultiClusterIngress-Ressource verweist.

    kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem
    
  4. Speichern Sie die folgende FrontendConfig-Ressource als frontendconfig.yaml. Weitere Informationen zu den unterstützten Feldern in einer FrontendConfig finden Sie unter FrontendConfig-Ressourcen konfigurieren.

    apiVersion: networking.gke.io/v1beta1
    kind: FrontendConfig
    metadata:
      name: frontend-redirect-tls-policy
      namespace: whereami
    spec:
      sslPolicy: tls-12-policy
      redirectToHttps:
        enabled: true
    

    Diese FrontendConfig aktiviert HTTPS-Weiterleitungen und eine SSL-Richtlinie, die die TLS-Mindestversion 1.2 erzwingt.

  5. Stellen Sie frontendconfig.yaml in Ihrem Konfigurationscluster bereit.

    kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER
    

    Ersetzen Sie dabei MCI_CONFIG_CLUSTER durch den Namen Ihres Konfigurationsclusters.

  6. Speichern Sie die folgende MultiClusterIngress-Ressource als mci-frontendconfig.yaml.

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: foo-ingress
      namespace: whereami
      annotations:
        networking.gke.io/frontend-config: frontend-redirect-tls-policy
        networking.gke.io/static-ip: STATIC_IP_ADDRESS
    spec:
      template:
        spec:
          backend:
            serviceName: default-backend
            servicePort: 8080
          rules:
          - host: foo.example.com
            http:
              paths:
                - backend:
                    serviceName: whereami-mcs
                    servicePort: 8080
          tls:
          - secretName: SECRET_NAME
    
    • Ersetzen Sie STATIC_IP_ADDRESS durch eine statische globale IP-Adresse, die Sie bereits bereitgestellt haben.
    • Ersetzen Sie SECRET_NAME durch das Secret, in dem Ihr foo.example.com-Zertifikat gespeichert ist.

    Für die Aktivierung von HTTPS-Weiterleitungen gibt es zwei Anforderungen:

    • TLS muss entweder über das Feld spec.tls oder über die vorinstallierte Zertifikatannotation networking.gke.io/pre-shared-certs aktiviert werden. Die MultiClusterIngress-Ressource wird nicht bereitgestellt, wenn HTTPS-Weiterleitungen aktiviert sind, HTTPS jedoch nicht.
    • Auf eine statische IP-Adresse muss über die Annotation networking.gke.io/static-ip verwiesen werden. Wenn Sie HTTPS für eine MultiClusterIngress-Ressource aktivieren, sind statische IP-Adressen erforderlich.
  7. Stellen Sie die MultiClusterIngress-Ressource in Ihrem Konfigurationscluster bereit.

    kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
    
  8. Warten Sie ein bis zwei Minuten und prüfen Sie foo-ingress.

    kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER
    

    Eine erfolgreiche Ausgabe sieht etwa so aus:

    • Der Status Cloud Resources wird mit Ressourcennamen ausgefüllt.
    • Das Feld VIP wird mit der IP-Adresse des Load-Balancers ausgefüllt.
    Name:         foobar-ingress
    Namespace:    whereami
    
    ...
    
    Status:
      Cloud Resources:
        Backend Services:
          mci-otn9zt-8080-whereami-bar
          mci-otn9zt-8080-whereami-default-backend
          mci-otn9zt-8080-whereami-foo
        Firewalls:
          mci-otn9zt-default-l7
        Forwarding Rules:
          mci-otn9zt-fw-whereami-foobar-ingress
          mci-otn9zt-fws-whereami-foobar-ingress
        Health Checks:
          mci-otn9zt-8080-whereami-bar
          mci-otn9zt-8080-whereami-default-backend
          mci-otn9zt-8080-whereami-foo
        Network Endpoint Groups:
          zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d
          zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515
          zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de
          zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75
          zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739
          zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579
        Target Proxies:
          mci-otn9zt-whereami-foobar-ingress
          mci-otn9zt-whereami-foobar-ingress
        URL Map:  mci-otn9zt-rm-whereami-foobar-ingress
      VIP:        34.149.29.76
    Events:
      Type     Reason  Age                From                              Message
      ----     ------  ----               ----                              -------
      Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  whereami/foobar-ingress
    
  9. Prüfen Sie, ob HTTPS-Weiterleitungen ordnungsgemäß funktionieren, indem Sie eine HTTP-Anfrage über curl senden.

    curl VIP
    

    Ersetzen Sie VIP durch die MultiClusterIngress-IP-Adresse.

    In der Ausgabe sollte zu sehen sein, dass die Anfrage an den HTTPS-Port weitergeleitet wurde, was darauf hinweist, dass die Weiterleitungen ordnungsgemäß funktionieren.

  10. Prüfen Sie, ob die TLS-Richtlinie ordnungsgemäß funktioniert. Senden Sie dazu eine HTTPS-Anfrage mit der TLS-Version 1.1. Da DNS für diese Domain nicht konfiguriert ist, verwenden Sie die Option --resolve, um curl anzuweisen, die IP-Adresse direkt aufzulösen.

    curl https://foo.example.com --resolve foo.example.com:443:VIP --cacert CERT_FILE -v
    

    Für diesen Schritt ist die PEM-Zertifikatsdatei erforderlich, die zum Sichern der MultiClusterIngress-Ressource verwendet wird. Eine erfolgreiche Ausgabe sieht etwa so aus:

    ...
    * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: O=example; CN=foo.example.com
    *  start date: Sep  1 10:32:03 2021 GMT
    *  expire date: Aug 27 10:32:03 2022 GMT
    *  common name: foo.example.com (matched)
    *  issuer: O=example; CN=foo.example.com
    *  SSL certificate verify ok.
    * Using HTTP2, server supports multi-use
    * Connection state changed (HTTP/2 confirmed)
    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
    * Using Stream ID: 1 (easy handle 0x7fa10f00e400)
    > GET / HTTP/2
    > Host: foo.example.com
    > User-Agent: curl/7.64.1
    > Accept: */*
    >
    * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
    < HTTP/2 200
    < content-type: application/json
    < content-length: 308
    < access-control-allow-origin: *
    < server: Werkzeug/1.0.1 Python/3.8.6
    < date: Wed, 01 Sep 2021 11:39:06 GMT
    < via: 1.1 google
    < alt-svc: clear
    <
    {"cluster_name":"gke-us","host_header":"foo.example.com","metadata":"foo","node_name":"gke-gke-us-default-pool-22cb07b1-r5r0.c.mark-church-project.internal","pod_name":"foo-75ccd9c96d-dkg8t","pod_name_emoji":"👞","project_id":"mark-church-project","timestamp":"2021-09-01T11:39:06","zone":"us-central1-b"}
    * Connection #0 to host foo.example.com left intact
    * Closing connection 0
    

    Der Antwortcode ist 200 und TLSv1.2 wird verwendet, was darauf hinweist, dass alles ordnungsgemäß funktioniert.

    Als Nächstes können Sie prüfen, ob die SSL-Richtlinie die richtige TLS-Version erzwingt, indem Sie versuchen, eine Verbindung zu TLS 1.1 herzustellen. Diese SSL-Richtlinie muss für die Mindestversion 1.2 konfiguriert sein, damit dieser Schritt funktioniert.

  11. Senden Sie die gleiche Anfrage wie im vorherigen Schritt, aber erzwingen Sie die TLS-Version 1.1.

    curl https://foo.example.com --resolve foo.example.com:443:VIP -v \
      --cacert CERT_FILE \
      --tls-max 1.1
    

    Eine erfolgreiche Ausgabe sieht etwa so aus:

    * Added foo.example.com:443:34.149.29.76 to DNS cache
    * Hostname foo.example.com was found in DNS cache
    *   Trying 34.149.29.76...
    * TCP_NODELAY set
    * Connected to foo.example.com (34.149.29.76) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: cert.pem
      CApath: none
    * TLSv1.1 (OUT), TLS handshake, Client hello (1):
    * TLSv1.1 (IN), TLS alert, protocol version (582):
    * error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
    * Closing connection 0
    curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
    

    Der fehlgeschlagene TLS-Handshake weist darauf hin, dass TLS 1.1 von der SSL-Richtlinie erfolgreich blockiert wurde.

Statische IP-Adresse erstellen

  1. Weisen Sie eine statische IP-Adresse zu:

    gcloud compute addresses create ADDRESS_NAME --global
    

    Ersetzen Sie ADDRESS_NAME durch den Namen der statischen IP-Adresse, die zugewiesen werden soll.

    Die Ausgabe enthält die vollständige URL der von Ihnen erstellten Adresse, in etwa so:

    Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME].
    
  2. Rufen Sie die soeben erstellte IP-Adresse auf:

    gcloud compute addresses list
    

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME          ADDRESS/RANGE  TYPE      STATUS
    ADDRESS_NAME  STATIC_IP_ADDRESS  EXTERNAL  RESERVED
    

    Diese Ausgabe enthält:

    • Den von Ihnen definierten ADDRESS_NAME.
    • Die zugewiesene STATIC_IP_ADDRESS.
  3. Aktualisieren Sie die Datei mci.yaml mit der statischen IP-Adresse:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: whereami-ingress
      namespace: whereami
      annotations:
        networking.gke.io/static-ip: STATIC_IP_ADDRESS
    spec:
      template:
        spec:
          backend:
            serviceName: whereami-mcs
            servicePort: 8080
    

    Ersetzen Sie STATIC_IP_ADDRESS entweder

    • durch die zugewiesene IP-Adresse, ähnlich wie 34.102.201.47, oder
    • durch die vollständige URL der von Ihnen erstellten Adresse, ähnlich wie "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME".

    Die STATIC_IP_ADDRESS ist nicht der Ressourcenname (ADDRESS_NAME).

  4. Stellen Sie die Ressource MultiClusterIngress noch einmal bereit:

    kubectl apply -f mci.yaml
    

    Die entsprechende Ausgabe sieht etwa so aus:

    multiclusteringress.networking.gke.io/whereami-ingress configured
    
  5. Führen Sie die Schritte unter Erfolgreichen Bereitstellungsstatus überprüfen aus, um zu prüfen, ob die Bereitstellung über die STATIC_IP_ADDRESS verfügbar ist.

Vorinstallierte Zertifikate

Vorinstallierte Zertifikate sind in Google Cloud hochgeladene Zertifikate, die vom Load-Balancer anstelle von in Kubernetes-Secrets gespeicherten Zertifikaten für die TLS-Beendigung verwendet werden können. Diese Zertifikate werden im Out-of-Band-Verfahren von GKE nach Google Cloud hochgeladen. Der Verweis darauf erfolgt über eine MultiClusterIngress-Ressource. Es werden auch mehrere Zertifikate unterstützt, entweder über vorinstallierte Zertifikate oder über Kubernetes-Secrets.

Für die Verwendung der Zertifikate in Multi-Cluster-Ingress sind die Annotation networking.gke.io/pre-shared-certs und die Namen der Zertifikate erforderlich. Wenn für einen bestimmten MultiClusterIngress mehrere Zertifikate angegeben sind, legt eine vordefinierte Reihenfolge fest, welches Zertifikat dem Client präsentiert wird.

Zum Auflisten der verfügbaren SSL-Zertifikate führen Sie folgenden Befehl aus:

gcloud compute ssl-certificates list

Im folgenden Beispiel wird der Clienttraffic zu einem der angegebenen Hosts beschrieben, der den allgemeinen Namen der vorinstallierten Zertifikate abgleicht, damit jeweils das Zertifikat präsentiert wird, das mit dem Domainnamen übereinstimmt.

kind: MultiClusterIngress
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
  template:
    spec:
      rules:
      - host: my-domain1.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain1-svc
              servicePort: 443
      - host: my-domain2.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain2-svc
              servicePort: 443

Von Google verwaltete Zertifikate

Von Google verwaltete Zertifikate werden in MultiClusterIngress-Ressourcen über die Annotation networking.gke.io/pre-shared-certs unterstützt. Multi-Cluster-Ingress unterstützt das Anhängen von Zertifikaten, die von Google verwaltet werden, an eine MultiClusterIngress-Ressource. Im Gegensatz zu Single-Cluster-Ingress wird aber die deklarative Generierung einer Kubernetes-ManagedCertificate-Ressource in MultiClusterIngress-Ressourcen nicht unterstützt. Die ursprüngliche Erstellung des von Google verwalteten Zertifikats muss direkt über die compute ssl-certificates create API vorgenommen werden, bevor Sie es an einen MultiClusterIngress anhängen können. Dazu gehen Sie so vor:

  1. Erstellen Sie wie hier in Schritt 1 beschrieben ein von Google verwaltetes Zertifikat. Fahren Sie nicht mit Schritt 2 fort, da Multi-Cluster-Ingress dieses Zertifikat automatisch anhängt.

    gcloud compute ssl-certificates create my-google-managed-cert \
        --domains=my-domain.gcp.com \
        --global
    
  2. Verweisen Sie mit der Annotation networking.gke.io/pre-shared-certs auf den Namen des Zertifikats in MultiClusterIngress.

    kind: MultiClusterIngress
    metadata:
    name: shopping-service
    namespace: whereami
    annotations:
      networking.gke.io/pre-shared-certs: "my-google-managed-cert"
    spec:
    template:
      spec:
        rules:
        - host: my-domain.gcp.com
          http:
            paths:
            - backend:
                serviceName: my-domain-svc
                servicePort: 8080
    

Das vorherige Manifest hängt das Zertifikat an Ihre MultiClusterIngress-Ressource an, damit sie Traffic für Ihre Back-End-GKE-Cluster beenden kann. Google Cloud verlängert Ihr Zertifikat automatisch vor dessen Ablauf. Verlängerungen erfolgen transparent und erfordern keine Aktualisierung für Multi-Cluster-Ingress.

Anwendungsprotokolle

Für die Verbindung vom Load-Balancer-Proxy zu Ihrer Anwendung wird standardmäßig HTTP verwendet. Mithilfe der Annotation networking.gke.io/app-protocols können Sie den Load-Balancer so konfigurieren, dass er HTTPS oder HTTP/2 verwendet, um Anfragen zu Ihrer Anwendung weiterzuleiten. Im Feld annotation des folgenden Beispiels bezieht sich http2 auf den Portnamen MultiClusterService und HTTP2 auf das Protokoll, das der Load-Balancer verwendet.

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: whereami
  annotations:
    networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
  template:
    spec:
      ports:
      - port: 443
        name: http2

BackendConfig

Informationen zum Konfigurieren der Annotation finden Sie im obigen Abschnitt.

Nächste Schritte