Ingress clusterübergreifend bereitstellen

Autopilot Standard

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

Einen detaillierten Vergleich zwischen Multi-Cluster-Ingress (MCI), Multi-Cluster-Gateway (MCG) und dem Load Balancer mit eigenständigen Netzwerk-Endpunktgruppen (LB und eigenständige NEGs) finden Sie unter Multi-Cluster-Load-Balancing-API für GKE auswählen.

Anleitung zum Deployment

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

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

gcloud container clusters list

Die entsprechende Ausgabe sieht etwa so aus:

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

Namespace erstellen

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

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

Erstellen Sie eine Datei namens namespace.yaml mit folgendem Inhalt:
```
apiVersion: v1
kind: Namespace
metadata:
  name: whereami
```
Hinweis: Mit kubectl config use-context können Sie beim Bereitstellen von Ressourcen zwischen Clustern wechseln. kubectl config get-contexts bietet die Möglichkeit, festzustellen, welche Cluster verfügbar sind. Mit kubectl config rename-context können Sie Kontexte in benutzerfreundlichere Namen umbenennen.
Wechseln Sie zum gke-us-Kontext:
```
kubectl config use-context gke-us
```
Erstellen Sie den Namespace:
```
kubectl apply -f namespace.yaml
```
Wechseln Sie zum gke-eu-Kontext:
```
kubectl config use-context gke-eu
```
Erstellen Sie den Namespace:
```
kubectl apply -f namespace.yaml
```
Die entsprechende Ausgabe sieht etwa so aus:
```
namespace/whereami created
```

Anwendung bereitstellen

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

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

Wechseln Sie zum gke-us-Kontext:
```
kubectl config use-context gke-us
```
Stellen Sie die whereami-Anwendung bereit:
```
kubectl apply -f deploy.yaml
```
Wechseln Sie zum gke-eu-Kontext:
```
kubectl config use-context gke-eu
```
Stellen Sie die whereami-Anwendung bereit:
```
kubectl apply -f deploy.yaml
```

Prüfen Sie, ob die whereami-Anwendung in jedem Cluster erfolgreich bereitgestellt wurde:

kubectl get deployment --namespace whereami

Die Ausgabe sollte in beiden Clustern in etwa so aussehen:

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

Über den Konfigurationscluster bereitstellen

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

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

Legen Sie den Konfigurationscluster als Kontext fest.
```
kubectl config use-context gke-us
```
Hinweis: Es kann immer nur ein Cluster der aktive Konfigurationscluster sein. Wenn Sie MultiClusterIngress- und MultiClusterService-Ressourcen in anderen Clustern bereitstellen, sind sie für den Multi-Cluster-Ingress-Controller weder sichtbar, noch können sie von diesem verarbeitet werden.

MultiClusterService

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

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

Stellen Sie die MultiClusterService-Ressource bereit, die der whereami-Anwendung entspricht:
```
kubectl apply -f mcs.yaml
```
Prüfen Sie, ob die whereami-mcs-Ressource erfolgreich im Konfigurationscluster bereitgestellt wurde:
```
kubectl get mcs -n whereami
```
Die entsprechende Ausgabe sieht etwa so aus:
```
NAME       AGE
whereami-mcs   9m26s
```
Dieser MultiClusterService erstellt in jedem Cluster, der Pods mit app: whereami abgleicht, einen abgeleiteten monitorlosen Service. Sie können nun sehen, dass im gke-us-Cluster kubectl get service -n whereami ein solcher Service vorhanden ist:

Die entsprechende Ausgabe sieht etwa so aus:
```
NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
mci-whereami-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s
```

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

MultiClusterIngress

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

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

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

Stellen Sie die MultiClusterIngress-Ressource, die auf whereami-mcs verweist, als Backend bereit:
```
kubectl apply -f mci.yaml
```
Die entsprechende Ausgabe sieht etwa so aus:
```
multiclusteringress.networking.gke.io/whereami-ingress created
```
Beachten Sie, dass die MultiClusterIngress-Ressource das gleiche Schema wie die Kubernetes-Ingress-Ressource hat. Auch die Semantik der Ingress-Ressource ist bis auf das Feld backend.serviceName identisch.

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

Deployment auf Erfolg prüfen

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

Prüfen Sie, ob das Deployment erfolgreich war:

kubectl describe mci whereami-ingress -n whereami

Die entsprechende Ausgabe sieht etwa so aus:

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

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

Events ist das erste Feld, das geprüft werden sollte. Ein eventueller Fehler ist hier aufgeführt.
Cloud Resource listet die Compute Engine-Ressourcen wie Weiterleitungsregeln, Backend-Dienste und Firewallregeln auf, die vom Multi-Cluster-Ingress-Controller erstellt wurden. Wenn sie nicht aufgeführt sind, wurden sie noch nicht erstellt. Sie können einzelne Compute Engine-Ressourcen mit der Console oder mit dem Befehl gcloud prüfen, um ihren Status zu ermitteln.
VIP listet eine IP-Adresse auf, wenn eine solche zugewiesen wurde. Beachten Sie, dass der Load-Balancer möglicherweise noch keinen Traffic verarbeitet, obwohl die VIP vorhanden ist. Wenn nach einigen Minuten keine VIP angezeigt wird oder der Load Balancer innerhalb von 10 Minuten keine 200-Antwort ausgibt, finden Sie entsprechende Informationen unter Fehlerbehebung und Vorgänge.

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

Prüfen Sie, ob die Anwendung unter der VIP mit dem Endpunkt /ping bereitgestellt wird:
```
curl INGRESS_VIP/ping
```
Ersetzen Sie INGRESS_VIP durch die virtuelle IP-Adresse (VIP).

Die entsprechende Ausgabe sieht etwa so aus:
```
{
"cluster_name": "gke-us",
"host_header": "34.120.175.141",
"pod_name": "whereami-deployment-954cbf78-mtlpf",
"pod_name_emoji": "😎",
"project_id": "my-project",
"timestamp": "2021-11-29T17:01:59",
"zone": "us-central1-b"
}
```
In der Ausgabe sollten die Region und das Backend der Anwendung angegeben sein.
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:

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

Das folgende Manifest beschreibt einen Standard-MultiClusterService:

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

Dabei gilt:

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

MultiClusterIngress-Spezifikation

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

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

Dabei gilt:

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

Multi-Cluster-Ingress-Features

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

Clusterauswahl

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

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

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

mcs.yaml öffnen

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

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

Hängen Sie im Abschnitt "clusters" die folgenden Zeilen an:
```
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: whereami-mcs
  namespace: whereami
spec:
  template:
    spec:
      selector:
        app: whereami
      ports:
      - name: web
        protocol: TCP
        port: 8080
        targetPort: 8080
  clusters:
  - link: "us-central1-b/gke-us"
  - link: "europe-west1-b/gke-eu"
```
In diesem Beispiel werden abgeleitete Dienstressourcen nur in den gke-us- und gke-eu-Clustern erstellt. Um selektiv Regeln für eingehenden Traffic anzuwenden, müssen Sie Cluster auswählen. Wenn der Abschnitt "clusters" der MultiClusterService-Ressource nicht angegeben ist oder darin keine Cluster aufgeführt sind, werden standardmäßig alle Cluster verwendet.

HTTPS-Support

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.

Erstellen Sie ein Secret:
```
kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE
```
Dabei gilt:
- SECRET_NAME der Namen Ihres Secrets.
- PATH_TO_KEYFILE der Pfad zur TLS-Schlüsseldatei.
- PATH_TO_CERTFILE der Pfad zur TLS-Zertifikatsdatei.

Aktualisieren Sie die Datei mci.yaml mit dem Secret-Namen:

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

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

Stellen Sie die Ressource MultiClusterIngress noch einmal bereit:
```
kubectl apply -f mci.yaml
```
Die entsprechende Ausgabe sieht etwa so aus:
```
multiclusteringress.networking.gke.io/whereami-ingress configured
```

BackendConfig-Unterstützung

Mit der folgenden BackendConfig-CRD können Sie Einstellungen für die Compute Engine-BackendService-Ressource anpassen:

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

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

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

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

gRPC-Unterstützung

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

Achten Sie darauf, dass der Traffic vom Load-Balancer zu Ihrer Anwendung HTTP/2 lautet. Verwenden Sie Anwendungsprotokolle, um dies zu konfigurieren.
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.
Sie müssen mTLS für die Anwendung deaktivieren, da mTLS für externe 7-Load-Balancer nicht unterstützt wird.

Ressourcenlebenszyklus

Konfigurationsänderungen

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

Kubernetes-Ressourcen verwalten

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

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

Cluster verwalten

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

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

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

Dabei gilt:

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

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

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

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

Beachten Sie, dass sich durch das Registrieren oder Aufheben der Registrierung eines Clusters sein Status als Backend für alle Ingress-Ressourcen ändert. Wenn Sie die Registrierung des Clusters gke-eu aufheben, wird er als verfügbares Backend für alle von Ihnen erstellten Ingresses entfernt. Für das Registrieren eines neuen Clusters gilt dann umgekehrt das Gleiche.

Multi-Cluster-Ingress deaktivieren

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

Deaktivieren Sie Multi Cluster Ingress dann mit dem folgenden Befehl:

gcloud container fleet ingress disable

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

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

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

gcloud container fleet ingress disable --force

Annotationen

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

MultiClusterIngress-Annotationen

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

MultiClusterService-Annotationen

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

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 oder Port 80 zu HTTPS oder 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.

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.

Prüfen Sie, ob die Richtlinie erstellt wurde.

gcloud compute ssl-policies list --project=PROJECT_ID

Die Ausgabe sieht in etwa so aus:

NAME           PROFILE  MIN_TLS_VERSION
tls-12-policy  MODERN   TLS_1_2

Erstellen Sie ein Zertifikat für foo.example.com wie in diesem Beispiel. Sobald Sie key.pem und cert.pem haben, speichern Sie diese Anmeldeinformationen als Secret, auf das die MultiClusterIngress-Ressource verweist.
```
kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem
```
Speichern Sie die folgende FrontendConfig-Ressource als frontendconfig.yaml. Weitere Informationen zu den unterstützten Feldern in einer FrontendConfig finden Sie unter FrontendConfig-Ressourcen konfigurieren.
```
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: frontend-redirect-tls-policy
  namespace: whereami
spec:
  sslPolicy: tls-12-policy
  redirectToHttps:
    enabled: true
```
Diese FrontendConfig aktiviert HTTPS-Weiterleitungen und eine SSL-Richtlinie, die die TLS-Mindestversion 1.2 erzwingt.
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.
Speichern Sie die folgende MultiClusterIngress-Ressource als mci-frontendconfig.yaml.
```
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
  namespace: whereami
  annotations:
    networking.gke.io/frontend-config: frontend-redirect-tls-policy
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 8080
      rules:
      - host: foo.example.com
        http:
          paths:
            - backend:
                serviceName: whereami-mcs
                servicePort: 8080
      tls:
      - secretName: SECRET_NAME
```
- Ersetzen Sie STATIC_IP_ADDRESS durch eine statische globale IP-Adresse, die Sie bereits bereitgestellt haben.
- Ersetzen Sie SECRET_NAME durch das Secret, in dem Ihr foo.example.com-Zertifikat gespeichert ist.
Für die Aktivierung von HTTPS-Weiterleitungen gibt es zwei Anforderungen:
- TLS muss entweder über das Feld spec.tls oder über die vorinstallierte Zertifikatannotation networking.gke.io/pre-shared-certs aktiviert werden. Das MultiClusterIngress 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.
Hinweis: Die Bereitstellung der Anwendung oder des MultiClusterService wird in diesem Beispiel nicht gezeigt. Damit dies funktioniert, müssen sie aber auch erstellt werden.
Stellen Sie die MultiClusterIngress-Ressource in Ihrem Konfigurationscluster bereit.
```
kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
```

Warten Sie ein bis zwei Minuten und prüfen Sie foo-ingress.

kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER

Eine erfolgreiche Ausgabe sieht etwa so aus:

Der Status Cloud Resources wird mit Ressourcennamen ausgefüllt.
Das Feld VIP wird mit der IP-Adresse des Load-Balancers ausgefüllt.

Name:         foobar-ingress
Namespace:    whereami

...

Status:
  Cloud Resources:
    Backend Services:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Firewalls:
      mci-otn9zt-default-l7
    Forwarding Rules:
      mci-otn9zt-fw-whereami-foobar-ingress
      mci-otn9zt-fws-whereami-foobar-ingress
    Health Checks:
      mci-otn9zt-8080-whereami-bar
      mci-otn9zt-8080-whereami-default-backend
      mci-otn9zt-8080-whereami-foo
    Network Endpoint Groups:
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515
      zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739
      zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579
    Target Proxies:
      mci-otn9zt-whereami-foobar-ingress
      mci-otn9zt-whereami-foobar-ingress
    URL Map:  mci-otn9zt-rm-whereami-foobar-ingress
  VIP:        34.149.29.76
Events:
  Type     Reason  Age                From                              Message
  ----     ------  ----               ----                              -------
  Normal   UPDATE  38m (x5 over 62m)  multi-cluster-ingress-controller  whereami/foobar-ingress

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.

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.

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

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].
```
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.
Aktualisieren Sie die Datei mci.yaml mit der statischen IP-Adresse:
```
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: whereami-ingress
  namespace: whereami
  annotations:
    networking.gke.io/static-ip: STATIC_IP_ADDRESS
spec:
  template:
    spec:
      backend:
        serviceName: whereami-mcs
        servicePort: 8080
```
Ersetzen Sie STATIC_IP_ADDRESS entweder
- durch die zugewiesene IP-Adresse, ähnlich wie 34.102.201.47, oder
- durch die vollständige URL der von Ihnen erstellten Adresse, ähnlich wie "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME".
Die STATIC_IP_ADDRESS ist nicht der Ressourcenname (ADDRESS_NAME).
Stellen Sie die Ressource MultiClusterIngress noch einmal bereit:
```
kubectl apply -f mci.yaml
```
Die entsprechende Ausgabe sieht etwa so aus:
```
multiclusteringress.networking.gke.io/whereami-ingress configured
```
Führen Sie die Schritte unter Erfolgreichen Bereitstellungsstatus überprüfen aus, um zu prüfen, ob die Bereitstellung über die STATIC_IP_ADDRESS verfügbar ist.

Vorinstallierte Zertifikate

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

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

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

gcloud compute ssl-certificates list

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

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

Von Google verwaltete Zertifikate

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

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
```

Verweisen Sie mit der Annotation networking.gke.io/pre-shared-certs auf den Namen des Zertifikats in MultiClusterIngress.

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

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

Anwendungsprotokolle

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

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

BackendConfig

Informationen zum Konfigurieren der Annotation finden Sie im obigen Abschnitt.

Nächste Schritte

Netzwerkübersicht
HTTP-Load-Balancing mit Ingress einrichten
Multi-Cluster-Ingress mit End-to-End-HTTPS implementieren