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 Anwendung namens zoneprinter sowie Ingress for Anthos in zwei Clustern bereit. Die Ingress-Ressource bietet eine gemeinsam genutzte virtuelle IP-Adresse (VIP) für die Anwendungs-Deployments.

Dieser Seite liegt die Ausführung der unter Ingress for Anthos einrichten aufgeführten Aufgaben zugrunde. Dort haben Sie zwei Cluster erstellt und registriert. 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.

Ingress for Anthos-Features

In diesem Abschnitt wird gezeigt, wie Sie zusätzliche Ingress for Anthos-Features konfigurieren.

Clusterauswahl

Standardmäßig werden aus Ingress for Anthos abgeleitete Dienste auf 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 Ingress for Anthos 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 Ihr Ingress for Anthos verweist und wo die abgeleiteten Dienste geplant werden. 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

Das Konfigurieren von gRPC-Anwendungen auf Ingress für Anthos erfordert eine sehr spezielle 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.

Ingress for Anthos deaktivieren

In der Betaversion führt das Deaktivieren von Ingress for Anthos 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.

Deaktivieren Sie Ingress for Anthos:

gcloud alpha container hub ingress disable

Annotationen

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. Diese Zertifikate werden im Out-of-Band-Verfahren von GKE nach Google Cloud hochgeladen. Der Verweis darauf erfolgt über ein Ingress for Anthos-Objekt. Es werden auch mehrere Zertifikate unterstützt, entweder über vorinstallierte Zertifikate oder über Kubernetes-Secrets.

Für die Verwendung der Zertifikate in Ingress for Anthos sind die Annotation networking.gke.io/pre-shared-certs und die Namen der Zertifikate erforderlich. Wenn für ein bestimmtes Ingress for Anthos-Objekt 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: 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

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 bzw. Hinweise zum Verhalten von Ingress for Anthos für eine sichere und akzeptable Nutzung. 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. Für alle verwalteten Ingress for Anthos-Ressourcen in einem Projekt wird das gleiche Präfix genutzt. Dieses Präfix wird zur Verwaltung und automatischen Bereinigung von Compute Engine-Ressourcen verwendet, die von Ingress for Anthos bereitgestellt werden. Da dieses Präfix einen generierten Hash enthält, ist es unwahrscheinlich, dass ein Projekt Compute Engine-Ressourcen mit diesem Präfix enthält, die sich nicht im Bereich von Ingress for Anthos befinden. Compute Engine-Load-Balancer im selben Projekt, die nicht von Ingress for Anthos verwaltet werden, sollten dieses Präfix allerdings nicht verwenden, da sie sonst gelöscht werden.

  • Ingress for Anthos unterstützt nur Cluster innerhalb desselben Projekts. Pro Projekt kann nur eine Instanz von Ingress for Anthos bereitgestellt werden. Der Clusterbereich lässt sich jedoch per Clusterauswahl steuern. Dies bietet die Möglichkeit, MultiClusterService-Ressourcen nur für bestimmte Teilmengen von Clustern innerhalb eines Projekts bereitzustellen.

  • Ingress für Anthos und Umgebung hat 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.

  • Ingress for Anthos 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