Ingress-Ressource clusterübergreifend bereitstellen

Auf dieser Seite wird gezeigt, wie Sie eine Ingress-Ressource für eine Anwendung in mehreren GKE-Clustern bereitstellen.

Anleitung zum Deployment

In den folgenden Aufgaben stellen Sie eine fiktive App mit dem Namen zoneprinter und Multi-Cluster-Ingress 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. An dieser Stelle sollten Sie zwei Cluster haben, die ebenfalls in einem environ registriert sind:

$ gcloud container clusters list
NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-c  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-a   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

Namespace erstellen

Da Umgebungen die Eigenschaft 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 zoneprinter-Namespace.

  1. Erstellen Sie namespace.yaml aus dem folgenden Manifest:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: zoneprinter
    
  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
    

Anwendung bereitstellen

  1. Erstellen Sie deploy.yaml aus dem folgenden Manifest:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: zone-ingress
      namespace: zoneprinter
      labels:
        app: zoneprinter
    spec:
      selector:
        matchLabels:
          app: zoneprinter
      template:
        metadata:
          labels:
            app: zoneprinter
        spec:
          containers:
          - name: frontend
            image: gcr.io/google-samples/zone-printer:0.2
            ports:
            - containerPort: 8080
    
  2. Wechseln Sie zum gke-us-Kontext:

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

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

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

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

    kubectl get deployment --namespace zoneprinter
    

    Die Ausgabe sollte in beiden Clustern in etwa so aussehen:

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    zone-ingress   2/2     2            2           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 (MCI) und MultiClusterService (MCS) im Konfigurationscluster bereit. MCI und MCS sind benutzerdefinierte Ressourcen (Custom Resources Definitions, CRDs) und stellen die Multiclusteräquivalente von Ingress- und Dienstressourcen dar.

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 mit dem Namen mcs.yaml aus dem folgenden Manifest:

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

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

    kubectl get mcs -n zoneprinter
    

    Die Ausgabe sieht etwa so aus:

    NAME       AGE
    zone-mcs   9m26s
    

    Diese MCS-Ressource erstellt in jedem Cluster, der Pods mit app: zoneprinter abgleicht, einen abgeleiteten monitorlosen Dienst. Sie können nun sehen, dass im gke-us-Cluster kubectl get service -n zoneprinter ein solcher Dienst vorhanden ist:

    Die Ausgabe sieht etwa so aus:

    NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
    mci-zone-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 mit dem Namen mci.yaml aus dem folgenden Manifest:

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

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

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

    kubectl apply -f mci.yaml
    

    Die Ausgabe sieht in etwa so aus:

    multiclusteringress.networking.gke.io/zone-mci 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 Hub 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 MCI-Ressource beschreibt die zugrunde liegenden Compute Engine-Ressourcen, die im Auftrag der MCI-Ressource erstellt wurden.

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

    kubectl describe mci zone-ingress -n zoneprinter
    

    Die Ausgabe sieht in etwa so aus:

    Name:         zone-ingress
    Namespace:    zoneprinter
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"zone-ingress","namespace":"zon...
    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/zoneprinter/multiclusteringresses/zone-ingress
      UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
    Spec:
      Template:
        Spec:
          Backend:
            Service Name:  zone-mcs
            Service Port:  8080
    Status:
      Cloud Resources:
        Backend Services:
          mci-8se3df-8080-zoneprinter-zone-mcs
        Firewalls:
          mci-8se3df-default-l7
        Forwarding Rules:
          mci-8se3df-fw-zoneprinter-zone-ingress
        Health Checks:
          mci-8se3df-8080-zoneprinter-zone-mcs
        Network Endpoint Groups:
          zones/europe-west1-c/networkEndpointGroups/k8s1-e4adffe6-zoneprint-mci-zone-mcs-svc-lgq966x5m-808-88670678
          zones/us-central1-a/networkEndpointGroups/k8s1-a6b112b6-zoneprint-mci-zone-mcs-svc-lgq966x5m-808-609ab6c6
        Target Proxies:
          mci-8se3df-zoneprinter-zone-ingress
        URL Map:  mci-8se3df-zoneprinter-zone-ingress
      VIP:        ingress-vip
    Events:
      Type    Reason  Age                    From                              Message
      ----    ------  ----                   ----                              -------
      Normal  ADD     3m35s                  multi-cluster-ingress-controller  zoneprinter/zone-ingress
      Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  zoneprinter/zone-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 Anthos 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 das MCI-Deployment wahrscheinlich erfolgreich. Ob der vollständige Trafficpfad funktioniert, können Sie aber nur durch Testen ermitteln.

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

    curl ingress-vip/ping
    

    Die Ausgabe sieht in etwa so aus:

    {"Hostname":"34.98.102.37","Version":"1.0","GCPZone":"us-central1-a","Backend":"zone-ingress-5554bb95b4-svv5d"}
    

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

  2. 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 eine Standard-MCS-Ressource:

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 der MCS-Ressource. Auf diesen Namen verweist das Feld serviceName in den MCI-Ressourcen.
  • namespace ist der Kubernetes-Namespace, in dem die MCS-Ressource bereitgestellt wird. Diese muss sich im selben Namespace wie die MCI-Ressource und die Pods in allen Clustern der Umgebung befinden.
  • pod-label ist das Label, das bestimmt, welche Pods als Back-Ends für diese MCS-Ressource in allen Clustern der Umgebung ausgewählt werden.
  • port muss mit dem Port übereinstimmen, auf den die MCI-Ressource verweist, die auf diese MCS-Ressource 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 MCI-Ressource.
  • namespace ist der Kubernetes-Namespace, in dem die MCI-Ressource bereitgestellt wird. Dies muss sich im selben Namespace wie die MCS-Ressource und die Pods in allen Clustern der Umgebung 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 die MCI-Ressource auch dann angegeben werden, wenn andere Host- oder Pfadübereinstimmungen konfiguriert sind.
  • port ist eine gültige Portnummer. Diese muss mit dem Feld port der MCS-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 einer MCS-Ressource, die im selben Namespace und Konfigurationscluster wie diese MCI-Ressource 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 gesteuert, auf welche Cluster Ihr Multi-Cluster-Ingress verweist und wo die abgeleiteten Dienste geplant sind. Cluster innerhalb desselben Hubs 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: zone-mcs
      namespace: zoneprinter
    spec:
      template:
        spec:
          selector:
            app: zoneprinter
          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: zone-mcs
      namespace: zoneprinter
    spec:
      template:
        spec:
          selector:
            app: zoneprinter
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
      clusters:
      - link: "us-central1-a/gke-us"
      - link: "europe-west1-c/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 prod create secret tls secret-name --key /path/to/keyfile --cert/path/to/certfile
    

    Dabei ist secret-name der Name Ihres Secrets.

  2. Aktualisieren Sie die Datei mci.yaml mit der statischen IP-Adresse und mit dem Secret:

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: zone-ingress
      namespace: zoneprinter
      annotations:
        networking.gke.io/static-ip: static-ip-address
    spec:
      template:
        spec:
          backend:
            serviceName: zone-mcs
            servicePort: 8080
          tls:
          - secretName: secret-name
    

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/v1beta1
kind: BackendConfig
metadata:
  name: zone-health-check-cfg
  namespace: zoneprinter
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: zone-mcs
  namespace: zoneprinter
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"8080":"zone-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: zoneprinter
     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 einer Mitgliedschaft 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 hub memberships unregister cluster-name \
  --gke-uri=uri

Dabei gilt:

  • cluster-name ist der Name des Clusters.
  • uri ist der URI des GKE-Clusters.

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

gcloud container hub memberships register europe-cluster \
  --context=europe-cluster --service-account-key-file=/path/to/service-account-key-file

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

In der Betaphase führt das Deaktivieren von Multi-Cluster-Ingress zu verwaisten Netzwerkressourcen. Um dies zu vermeiden, löschen Sie die MultiClusterIngress- und MultiClusterService-Ressourcen und prüfen Sie, ob alle zugehörigen Netzwerkressourcen entfernt wurden.

Multi-Cluster-Ingress deaktivieren:

gcloud alpha container hub ingress disable

Anmerkungen

Statische IP-Adresse erstellen

  1. Weisen Sie eine statische IP-Adresse zu:

    gcloud compute addresses create address-name --global
    

    Dabei ist address-name der Name der zu erstellenden Adresse.

    Die Ausgabe sieht in etwa so aus:

    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 Ausgabe sieht in etwa so aus:

    NAME          ADDRESS/RANGE  TYPE      STATUS
    address-name  34.102.201.47  EXTERNAL  RESERVED
    
  3. Wenden Sie die statische IP-Adresse an und aktualisieren Sie dafür mci.yaml:

    kubectl get mci zone-mci -o yaml
    

    Die Ausgabe sieht in etwa so aus:

    kind: MultiClusterIngress
    metadata:
      name: shopping-service
      namespace: prod
      annotations:
        networking.gke.io/static-ip: static-ip-address
    spec:
      template:
        spec:
           backend:
             serviceName: shopping-service
              servicePort: 80
    

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. Die Zertifikate werden von GKE in Google Cloud hochgeladen und von einem Multi-Cluster-Ingress-Objekt referenziert. 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 mehrere Zertifikate für ein bestimmtes Multi-Cluster-Ingress-Objekt angegeben sind, bestimmt eine vordefinierte Reihenfolge, 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: prod
  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 MCI über die Annotation networking.gke.io/pre-shared-certs unterstützt. MCI unterstützt das Anhängen von von Google verwalteten Zertifikaten an eine MultiClusterIngress-Ressource. Im Gegensatz zu Single-Cluster-Ingress-Ressourcen wird aber die deklarative Generierung einer Kubernetes-ManagedCertificate-Ressource in MCI 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 eine MultiClusterIngress-Ressource 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 MCI 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: prod
    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 MCI.

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.

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: prod
  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.

Bekannte Probleme, Produkteinschränkungen und Anleitungen

Im Folgenden finden Sie wichtige Einschränkungen oder Hinweise zum Multi-Cluster-Ingress-Verhalten, mit denen eine sichere und akzeptable Nutzung gewährleistet wird. Bei Fragen wenden Sie sich an Ihr Account-Management-Team oder an gke-mci-feedback@google.com.

  • Compute Engine-Load-Balancer-Ressourcen werden mit einem Namen erstellt, der das Präfix mci-[6 char hash] enthält. Alle verwalteten Multi-Cluster-Ingress-Ressourcen in einem Projekt verwenden dasselbe Präfix. Mit diesem Präfix werden die Multi-Cluster-Ingress-Deployments der Compute Engine-Ressourcen verwaltet und die Speicher automatisch bereinigt. Da dieses Präfix einen generierten Hash enthält, ist es unwahrscheinlich, dass ein Projekt Compute Engine-Ressourcen außerhalb des Bereichs von Multi-Cluster-Ingress mit diesem Präfix enthält. Compute Engine-Load-Balancer in diesem Projekt, die nicht von Multi-Cluster-Ingress verwaltet werden, sollten dieses Präfix jedoch nicht verwenden, da sie sonst gelöscht werden.

  • Multi-Cluster-Ingress unterstützt nur Cluster im selben Projekt. Pro Projekt kann nur eine Instanz von Multi-Cluster-Ingress bereitgestellt werden, wobei die Anwendungsbereiche mit Clusterauswahl gesteuert werden können. Dies bietet die Möglichkeit, MultiClusterService-Ressourcen nur für bestimmte Teilmengen von Clustern innerhalb eines Projekts bereitzustellen.

  • Multi-Cluster-Ingress und -Environs haben ein vorkonfiguriertes Kontingent von maximal 15 Clustern pro Projekt. Dieses kann bei Bedarf erhöht werden. Wenden Sie sich an Ihr Account-Management-Team, um ein höheres Clusterlimit pro Projekt anzufordern, wenn Sie weitere Cluster registrieren müssen.

  • Multi-Cluster-Ingress hat ein vorkonfiguriertes Kontingent von 50 MultiClusterIngress- und 100 MultiClusterService-Ressourcen pro Projekt. Auf diese Weise können bis zu 50 MCI- und 100 MCS-Ressourcen für eine beliebige Anzahl an Back-End-Clustern bis zur maximalen Clusteranzahl des Projekts in einem Konfigurationscluster erstellt werden. Dieses Kontingent kann bei Bedarf erhöht werden. Wenden Sie sich an Ihr Account-Management-Team, um höhere MCI- und MCS-Kontingente pro Projekt anzufordern, wenn Sie hochskalieren müssen.

  • Die Konfiguration von HTTPS erfordert eine vorab zugewiesene statische IP-Adresse. HTTPS wird derzeit nicht für sitzungsspezifische IP-Adressen unterstützt.

Nächste Schritte