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 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. Prüfen Sie, ob Sie zwei Cluster haben, die auch bei einer Flotte registriert sind:

gcloud container clusters list

Die Ausgabe sieht etwa so aus:

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 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 zoneprinter-Namespace.

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

    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
    

    Die Ausgabe sieht etwa so aus:

    namespace/zoneprinter created
    

Anwendung bereitstellen

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

    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   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 (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 namens mcs.yaml mit folgendem Inhalt:

    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 namens mci.yaml mit folgendem Inhalt:

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

    multiclusteringress.networking.gke.io/zone-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 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 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:        34.98.102.37
    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 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 das MCI-Deployment 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 Ausgabe sieht 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.

  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 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: 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 Flotte befinden.
  • POD_LABEL ist das Label, das bestimmt, welche Pods als Back-Ends für diese MCS-Ressource in allen Clustern der Flotte 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: 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 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 die MCI-Ressource 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 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 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: 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 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: 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
    

    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/zone-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/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: 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 hub memberships register europe-cluster \
  --context=europe-cluster --service-account-key-file=PATH_TO_SERVICE_ACCOUNT_KEY_FILE

Ersetzen Sie PATH_TO_SERVICE_ACCOUNT_KEY_FILE durch den Pfad zur Schlüsseldatei des Dienstkontos.

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 alpha container hub 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 alpha container hub 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.
beta.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 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 multi-cluster-demo 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: multi-cluster-demo
    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: multi-cluster-demo
      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: foo
                    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:    multi-cluster-demo
    
    ...
    
    Status:
      Cloud Resources:
        Backend Services:
          mci-otn9zt-8080-multi-cluster-demo-bar
          mci-otn9zt-8080-multi-cluster-demo-default-backend
          mci-otn9zt-8080-multi-cluster-demo-foo
        Firewalls:
          mci-otn9zt-default-l7
        Forwarding Rules:
          mci-otn9zt-fw-multi-cluster-demo-foobar-ingress
          mci-otn9zt-fws-multi-cluster-demo-foobar-ingress
        Health Checks:
          mci-otn9zt-8080-multi-cluster-demo-bar
          mci-otn9zt-8080-multi-cluster-demo-default-backend
          mci-otn9zt-8080-multi-cluster-demo-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-multi-cluster-demo-foobar-ingress
          mci-otn9zt-multi-cluster-demo-foobar-ingress
        URL Map:  mci-otn9zt-rm-multi-cluster-demo-foobar-ingress
      VIP:        34.149.29.76
    Events:
      Type     Reason  Age                From                              Message
      ----     ------  ----               ----                              -------
      Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  multi-cluster-demo/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: zone-ingress
      namespace: zoneprinter
    annotations:
      networking.gke.io/static-ip: STATIC_IP_ADDRESS
    spec:
      template:
        spec:
          backend:
            serviceName: zone-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/zone-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. 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 Multi-Cluster-Ingress ü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-Ressourcen wird aber die deklarative Generierung einer Kubernetes-ManagedCertificate-Ressource in Multi-Cluster-Ingress 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 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: 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 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: 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 -Flotten 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