Mehrere SSL-Zertifikate beim HTTPS-Load-Balancing mit Ingress verwenden

Autopilot Standard

---

Auf dieser Seite wird gezeigt, wie Sie mehrere SSL-Zertifikate für Ingress-Ressourcen in GKE-Clustern (Google Kubernetes Engine) konfigurieren.

Überblick

Wenn HTTPS-Anfragen von den Clients angenommen werden sollen, benötigt der Application Load Balancer ein Zertifikat, damit er seine Identität gegenüber den Clients nachweisen kann. Der Load-Balancer benötigt außerdem einen privaten Schlüssel, um den HTTPS-Handshake abzuschließen.

Wenn der Load-Balancer eine HTTPS-Anfrage von einem Client akzeptiert, wird der Traffic zwischen dem Client und dem Load-Balancer mit TLS verschlüsselt. Der Load-Balancer beendet jedoch die TLS-Verschlüsselung und leitet die Anfrage ohne Verschlüsselung an die Anwendung weiter. Wenn Sie einen Application Load Balancer über Ingress konfigurieren, können Sie festlegen, dass dem Client bis zu zehn TLS-Zertifikate angezeigt werden.

Der Load-Balancer ermittelt mit "Server Name Indication" (SNI) anhand des Domainnamens im TLS-Handshake, welches Zertifikat dem Client präsentiert werden soll. Wenn der Client kein SNI verwendet oder einen Domainnamen, der nicht mit dem "Common Name" (CN) in einem der Zertifikate übereinstimmt, verwendet der Load-Balancer das erste in Ingress aufgeführte Zertifikat.

Das folgende Diagramm zeigt den Load Balancer, der Traffic an verschiedene Backends sendet, je nach dem in der Anfrage verwendeten Domainnamen:

Sie können eine der folgenden Methoden verwenden, um einen Application Load Balancer mit SSL-Zertifikaten bereitzustellen:

• Von Google verwaltete SSL-Zertifikate. Wie Sie die Zertifikate verwenden, erfahren Sie auf der Seite der zu verwalteten Zertifikate.

• Google Cloud-SSL-Zertifikat, das Sie selbst verwalten. Das SSL-Zertifikat verwendet ein vorinstalliertes Zertifikat, das Sie in Ihr Google Cloud-Projekt hochladen.

• Kubernetes Secrets. Das Secret enthält ein Zertifikat und einen Schlüssel, die Sie selbst erstellen. Sie fügen den Namen des Secrets dem Feld tls der Ingress-Manifestdatei hinzu.

Sie können im selben Ingress mehrere Methoden verwenden. Dies ermöglicht Migrationen ohne Ausfallzeiten zwischen den Methoden.

Allgemeiner Überblick

Hier ein Überblick über die Schritte in diesem Dokument:

1. Deployment erstellen.

2. Erstellen Sie einen Dienst.

3. Erstellen Sie zwei Zertifikatsdateien und zwei Schlüsseldateien oder zwei ManagedCertificate-Objekte. Sie müssen diese Zertifikate im selben Projekt und im selben Namespace konfigurieren wie der Load-Balancer.

4. Ein Ingress mit Secrets oder vorinstallierten Zertifikaten erstellen. Wenn Sie das Ingress-Objekt erstellen, erstellt und konfiguriert GKE einen Anwendungs-Load-Balancer.

5. Testen Sie den Anwendungs-Load-Balancer.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

• Sie müssen zwei Domainnamen besitzen. Die Domainnamen dürfen maximal 63 Zeichen haben.

Beschränkungen

• Von Google verwaltete Zertifikate werden nur mit GKE-Ingress über den externen Application Load Balancer unterstützt. Von Google verwaltete Zertifikate unterstützen keine Ingress-Controller von Drittanbietern.

• Für interne Anwendungs-Load-Balancer müssen Sie HTTP im Ingress-Manifest deaktivieren. Dies ist für den externen Load-Balancer nicht erforderlich.
• Sie dürfen die Konfiguration des Anwendungs-Load-Balancers nicht manuell ändern oder aktualisieren. Das heißt, Sie dürfen keine Komponenten des Load-Balancers wie Zielproxys, URL-Zuordnungen und Backend-Dienste bearbeiten. Alle vorgenommenen Änderungen werden von GKE überschrieben.

Deployment erstellen

1. Speichern Sie das folgende Manifest als my-mc-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-mc-deployment
   spec:
     selector:
       matchLabels:
         app: products
         department: sales
     replicas: 3
     template:
       metadata:
         labels:
           app: products
           department: sales
       spec:
         containers:
         - name: hello
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
           env:
           - name: "PORT"
             value: "50001"
         - name: hello-again
           image: "us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0"
           env:
           - name: "PORT"
             value: "50002"
   

   Dieses Manifest beschreibt ein Deployment mit drei Pods. Jeder Pod hat zwei Container. Der eine Container führt hello-app:1.0 aus und überwacht den TCP-Port 50001. Der andere Container führt hello-app:2.0 aus und überwacht den TCP-Port 50002.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f my-mc-deployment.yaml
   

Service erstellen

1. Speichern Sie das folgende Manifest als my-mc-service.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: my-mc-service
   spec:
     type: NodePort
     selector:
       app: products
       department: sales
     ports:
     - name: my-first-port
       protocol: TCP
       port: 60001
       targetPort: 50001
     - name: my-second-port
       protocol: TCP
       port: 60002
       targetPort: 50002
   

   Dieses Manifest beschreibt einen Service mit folgenden Feldern:

   • selector: gibt an, dass jeder Pod mit dem Label app: products und dem Label department: sales ein Mitglied dieses Dienstes ist.
   • ports: Wenn ein Client eine Anfrage an den Service auf my-first-port sendet, leitet GKE die Anfrage an einen der Mitglieds-Pods an Port 50001 weiter. Wenn ein Client eine Anfrage an den Service auf my-second-port sendet, leitet GKE die Anfrage an einen der Mitglieds-Pods an Port 50002 weiter.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f my-mc-service.yaml
   

Zertifikate und Schlüssel erstellen

Für die Übungen auf dieser Seite benötigen Sie zwei Zertifikate mit jeweils einem Schlüssel. Jedes Zertifikat benötigt einen "Common Name" (CN), der einem Ihrer Domainnamen entspricht.

Sie können diese Zertifikate manuell erstellen oder von Google verwaltete Zertifikate verwenden.

Wenn Sie bereits zwei Zertifikatsdateien mit den entsprechenden Werten für Common Name haben, können Sie mit dem nächsten Abschnitt fortfahren.

Von Nutzern verwaltete Zertifikate

1. Erstellen Sie Ihren ersten Schlüssel:

   openssl genrsa -out test-ingress-1.key 2048
   

2. Erstelle Sie die erste Zertifikatsignierungsanfrage:

   openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
       -subj "/CN=FIRST_DOMAIN"
   

   Ersetzen Sie FIRST_DOMAIN durch einen Ihrer Domainnamen, z. B. example.com.

3. Erstellen Sie Ihr erstes Zertifikat:

   openssl x509 -req -days 365 -in test-ingress-1.csr -signkey test-ingress-1.key \
       -out test-ingress-1.crt
   

4. Erstellen Sie Ihren zweiten Schlüssel:

   openssl genrsa -out test-ingress-2.key 2048
   

5. Erstellen Sie Ihre zweite Zertifikatsignierungsanfrage:

   openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
       -subj "/CN=SECOND_DOMAIN"
   

   Ersetzen Sie SECOND_DOMAIN durch einen anderen Ihrer Domainnamen, z. B. examplepetstore.com.

6. Ihr zweites Zertifikat erstellen:

   openssl x509 -req -days 365 -in test-ingress-2.csr -signkey test-ingress-2.key \
       -out test-ingress-2.crt
   

Weitere Informationen zu Zertifikaten und Schlüsseln finden Sie unter SSL-Zertifikate.

Sie haben jetzt zwei Zertifikatsdateien und zwei Schlüsseldateien.

Für die restlichen Aufgaben werden die folgenden Platzhalter verwendet, um auf Ihre Domains, Zertifikate und Schlüssel zu verweisen:

• FIRST_CERT_FILE: der Pfad zu Ihrer ersten Zertifikatsdatei.
• FIRST_KEY_FILE: der Pfad zur Schlüsseldatei, die zu Ihrem ersten Zertifikat gehört.
• FIRST_DOMAIN: einer Ihrer Domainnamen.
• FIRST_SECRET_NAME: der Name des Secrets, das Ihr erstes Zertifikat und den Schlüssel enthält.
• SECOND_CERT_FILE: der Pfad zu Ihrer zweiten Zertifikatsdatei.
• SECOND_KEY_FILE: der Pfad zur Schlüsseldatei, die zu Ihrem zweiten Zertifikat gehört.
• SECOND_DOMAIN: ein zweiter Domainname, der Ihnen gehört.
• SECOND_SECRET_NAME: der Name des Secrets, das Ihr zweites Zertifikat und den Schlüssel enthält.

Hinweis: Die Begriffe FIRST und SECOND legen keine Reihenfolge fest. Sie helfen Ihnen nur, Ihre zwei Domains, Ihre zwei Zertifikatsdateien und die jeweiligen Schlüsseldateien zu verfolgen.

Von Google verwaltete Zertifikate

Um von Google verwaltete Zertifikate zu erstellen, müssen Sie ManagedCertificate-Objekte zum Namespace Ihres Ingress hinzufügen. Sie können die folgende Vorlage verwenden, um Zertifikate für Ihre Domains zu definieren:

  apiVersion: networking.gke.io/v1
  kind: ManagedCertificate
  metadata:
    name: FIRST_CERT_NAME
  spec:
    domains:
      - FIRST_DOMAIN
  ---
  apiVersion: networking.gke.io/v1
  kind: ManagedCertificate
  metadata:
    name: SECOND_CERT_NAME
  spec:
    domains:
      - SECOND_DOMAIN

Ersetzen Sie Folgendes:

• FIRST_CERT_NAME: der Name des ersten ManagedCertificate-Objekts.
• FIRST_DOMAIN: Ihre erste Domain, die Ihnen gehört.
• SECOND_CERT_NAME: der Name des zweiten ManagedCertificate-Objekts.
• SECOND_DOMAIN: Ihre zweite Domain, die Ihnen gehört.

Die Namen der ManagedCertificate-Objekte unterscheiden sich von den Namen der von ihnen erstellten tatsächlichen Zertifikate. Sie benötigen nur die Namen der ManagedCertificate-Objekte, um Sie in Ihrem Ingress zu verwenden.

Zertifikate für ein Ingress angeben

Als Nächstes erstellen Sie ein Ingress-Objekt. In Ihrem Ingress-Manifest können Sie eine von zwei Methoden für die Bereitstellung von Zertifikaten für den Load-Balancer verwenden:

• Secrets
• Vorinstallierte Zertifikate

• Von Google verwaltete Zertifikate

Secrets

1. Erstellen Sie ein Secret mit Ihrem ersten Zertifikat und Ihrem ersten Schlüssel:

   kubectl create secret tls FIRST_SECRET_NAME \
       --cert=FIRST_CERT_FILE \
       --key=FIRST_KEY_FILE
   

2. Erstellen Sie ein Secret mit Ihrem zweiten Zertifikat und Ihrem zweiten Schlüssel:

   kubectl create secret tls SECOND_SECRET_NAME \
       --cert=SECOND_CERT_FILE \
       --key=SECOND_KEY_FILE
   

Ingress-Objekt erstellen

1. Speichern Sie das folgende Manifest als my-mc-ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-mc-ingress
   spec:
     tls:
     - secretName: FIRST_SECRET_NAME
     - secretName: SECOND_SECRET_NAME
     rules:
     - host: FIRST_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60001
     - host: SECOND_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60002
   

   Ersetzen Sie FIRST_DOMAIN und SECOND_DOMAIN durch Ihre eigenen Domainnamen, z. B. example.com und examplepetstore.com.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f my-mc-ingress.yaml
   

3. Beschreiben Sie Ihr Ingress:

   kubectl describe ingress my-mc-ingress
   

   Die Ausgabe sieht in etwa so aus:

   Name: my-mc-ingress
   Address: 203.0.113.1
   ...
   TLS:
     FIRST_SECRET_NAME terminates
     SECOND_SECRET_NAME terminates
   Rules:
     Host              Path  Backends
     ----              ----  --------
     FIRST_DOMAIN
                         my-mc-service:my-first-port (<none>)
     SECOND_DOMAIN
                         my-mc-service:my-second-port (<none>)
   Annotations:
   ...
   Events:
     Type    Reason  Age   From                     Message
     ----    ------  ----  ----                     -------
     Normal  ADD     3m    loadbalancer-controller  default/my-mc-ingress
     Normal  CREATE  2m    loadbalancer-controller  ip: 203.0.113.1
   

   Die Ausgabe zeigt, dass dem Ingress zwei Secrets zugeordnet sind. Die Ausgabe zeigt auch die externe IP-Adresse des Load-Balancers: Wenn die externe IP-Adresse nicht festgelegt ist, warten Sie einige Minuten und führen Sie den Befehl noch einmal aus.

Vorinstallierte Zertifikate

1. Erstellen Sie ein Zertifikat:

   gcloud compute ssl-certificates create FIRST_CERT_NAME \
       --certificate=FIRST_CERT_FILE \
       --private-key=FIRST_KEY_FILE
   

   Ersetzen Sie Folgendes:

   • FIRST_CERT_NAME: der Name Ihres ersten Zertifikats.
   • FIRST_CERT_FILE: Ihre erste Zertifikatsdatei.
   • FIRST_KEY_FILE: Ihre erste Schlüsseldatei.

2. Erstellen Sie ein zweites Zertifikat:

   gcloud compute ssl-certificates create SECOND_CERT_NAME \
       --certificate=SECOND_CERT_FILE \
       --private-key=SECOND_KEY_FILE
   

   Ersetzen Sie Folgendes:

   • SECOND_CERT_NAME: der Name Ihres zweiten Zertifikats.
   • SECOND_CERT_FILE: Ihre zweite Zertifikatsdatei.
   • SECOND_KEY_FILE: Ihre zweite Schlüsseldatei.

3. Rufen Sie Ihre Zertifikatsressourcen auf:

   gcloud compute ssl-certificates list
   

   Die Ausgabe sieht in etwa so aus:

   NAME                   CREATION_TIMESTAMP
   FIRST_CERT_NAME      2018-11-03T12:08:47.751-07:00
   SECOND_CERT_NAME     2018-11-03T12:09:25.359-07:00
   

Ingress-Objekt erstellen

1. Speichern Sie das folgende Manifest als my-psc-ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-psc-ingress
     annotations:
       ingress.gcp.kubernetes.io/pre-shared-cert: "FIRST_CERT_NAME,SECOND_CERT_NAME"
   spec:
     rules:
     - host: FIRST_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60001
     - host: SECOND_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60002
   

   Ersetzen Sie FIRST_DOMAIN und SECOND_DOMAIN durch Ihre Domainnamen.

   Dieses Manifest beschreibt ein Ingress, das in einer Annotation vorinstallierte Zertifikatsressourcen aufführt.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f my-psc-ingress.yaml
   

3. Beschreiben Sie Ihr Ingress:

   kubectl describe ingress my-psc-ingress
   

   Die Ausgabe sieht in etwa so aus:

   Name:             my-psc-ingress
   Address:          203.0.113.2
   ...
   Rules:
     Host              Path  Backends
     ----              ----  --------
     FIRST_DOMAIN
                         my-mc-service:my-first-port (<none>)
     SECOND_DOMAIN
                         my-mc-service:my-second-port (<none>)
   Annotations:
     ...
     ingress.gcp.kubernetes.io/pre-shared-cert:    FIRST_CERT_NAME,SECOND_CERT_NAME
     ...
     ingress.kubernetes.io/ssl-cert:               FIRST_CERT_NAME,SECOND_CERT_NAME
   Events:
     Type    Reason  Age   From                     Message
     ----    ------  ----  ----                     -------
     Normal  ADD     2m    loadbalancer-controller  default/my-psc-ingress
     Normal  CREATE  1m    loadbalancer-controller  ip: 203.0.113.2
   

   Die Ausgabe zeigt, dass das Ingress vorinstallierten Zertifikaten mit dem Namen FIRST_CERT_NAME und SECOND_CERT_NAME zugeordnet ist. Die Ausgabe zeigt auch die externe IP-Adresse des Load-Balancers. Wenn die externe IP-Adresse nicht festgelegt ist, warten Sie einige Minuten und führen Sie den Befehl noch einmal aus.

Von Google verwaltete Zertifikate

Ingress-Objekt erstellen

1. Speichern Sie das folgende Manifest als my-gmc-ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-gmc-ingress
     annotations:
       networking.gke.io/managed-certificates: "FIRST_CERT_NAME,SECOND_CERT_NAME"
   spec:
     rules:
     - host: FIRST_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60001
     - host: SECOND_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60002
   

   Ersetzen Sie FIRST_DOMAIN und SECOND_DOMAIN durch Ihre Domainnamen.

   Dieses Manifest beschreibt ein Ingress, das in einer Annotation vorinstallierte Zertifikatsressourcen aufführt.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f my-gmc-ingress.yaml
   

3. Beschreiben Sie Ihr Ingress:

   kubectl describe ingress my-gmc-ingress
   

   Die Ausgabe sieht in etwa so aus:

   Name:             my-gmc-ingress
   Address:          203.0.113.2
   ...
   Rules:
     Host              Path  Backends
     ----              ----  --------
     FIRST_DOMAIN
                         my-mc-service:my-first-port (<none>)
     SECOND_DOMAIN
                         my-mc-service:my-second-port (<none>)
   Annotations:
     ...
     ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-a6e41ce4-2b39-4334-84ce-867ff543c424,mcrt-bbff4116-f014-4800-a43a-4095bffeb4f4
     ...
     ingress.kubernetes.io/ssl-cert:               mcrt-a6e41ce4-2b39-4334-84ce-867ff543c424,mcrt-bbff4116-f014-4800-a43a-4095bffeb4f4
     networking.gke.io/managed-certificates:       FIRST_CERT_NAME,SECOND_CERT_NAME
   Events:
     Type    Reason  Age   From                     Message
     ----    ------  ----  ----                     -------
     Normal  ADD     2m    loadbalancer-controller  default/my-gmc-ingress
     Normal  CREATE  1m    loadbalancer-controller  ip: 203.0.113.2
   

   Die Ausgabe zeigt, dass das Ingress den verwalteten Zertifikaten FIRST_CERT_NAME und SECOND_CERT_NAME zugeordnet ist. GKE füllt die Annotationen ingress.gcp.kubernetes.io/pre-shared-cert und ingress.kubernetes.io/ssl-cert automatisch mit den von Google verwalteten Zertifikaten aus, die Sie mit den ManagedCertificate-Objekten erstellt haben. Die Ausgabe zeigt auch die externe IP-Adresse des Load-Balancers: Wenn die externe IP-Adresse nicht festgelegt ist, warten Sie einige Minuten und führen Sie den Befehl noch einmal aus.

Load-Balancer testen

Warten Sie ungefähr fünf Minuten, bis GKE die Konfiguration des Load-Balancers abgeschlossen hat.

Bei von Google verwalteten Zertifikaten kann die Konfiguration erheblich länger dauern, da das System die Zertifikate bereitstellen und die DNS-Konfiguration für bestimmte Domains prüfen muss.

Zum Testen des Load Balancers benötigen Sie zwei Domainnamen. Außerdem müssen beide Domainnamen zur externen IP-Adresse des externen Application Load Balancers auflösen.

1. Senden Sie eine Anfrage an den Load-Balancer mit Ihrem ersten Domainnamen:

   curl -v https://FIRST_DOMAIN
   

   Möglicherweise müssen Sie die Option curl -k für eine unsichere SSL-Übertragung verwenden, sodass curl selbst signierte Zertifikate akzeptiert.

   Die Ausgabe sieht in etwa so aus:

   ...
   *   Trying 203.0.113.1...
   ...
   * Connected to FIRST_DOMAIN (203.0.113.1) port 443 (#0)
   ...
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   ...
   * Server certificate:
   *  subject: CN=FIRST_DOMAIN
   ...
   > Host: FIRST_DOMAIN.com
   ...
   Hello, world!
   Version: 1.0.0
   ...
   

   Diese Ausgabe zeigt, dass Ihr erstes Zertifikat im TLS-Handshake verwendet wurde.

2. Senden Sie eine Anfrage an den Load-Balancer mit Ihrem zweiten Domainnamen:

   curl -v https://SECOND_DOMAIN
   

   Die Ausgabe sieht in etwa so aus:

   ...
   *   Trying 203.0.113.1...
   ...
   * Connected to SECOND_DOMAIN (203.0.113.1) port 443 (#0)
   ...
   * Server certificate:
   *  subject: CN=SECOND_DOMAIN
   ...
   > Host: SECOND_DOMAIN
   ...
   Hello, world!
   Version: 2.0.0
   

   Diese Ausgabe zeigt, dass Ihr zweites Zertifikat im TLS-Handshake verwendet wurde.

Host-Feld eines Ingress-Objekts

Eine IngressSpec enthält das Feld tls mit einem Array von IngressTLS-Objekten. Jedes IngressTLS-Objekt verfügt über das Feld hosts und SecretName. In GKE wird das Feld hosts nicht verwendet. GKE liest den Common Name (CN) aus dem Zertifikat im Secret. Wenn der allgemeine Name in einer Clientanfrage mit dem Domainnamen übereinstimmt, präsentiert der Load-Balancer dem Client das entsprechende Zertifikat.

Welches Zertifikat wird präsentiert?

Der Load-Balancer wählt ein Zertifikat entsprechend den folgenden Regeln aus:

• Wenn sowohl Secrets als auch vorinstallierte Zertifikate im Ingress-Objekt aufgelistet sind, haben die vorinstallierten Zertifikate Vorrang vor Secrets. Dies bedeutet, dass Secrets weiterhin enthalten sind, vorinstallierte Zertifikate aber zuerst angezeigt werden.

• Wenn kein Zertifikat einen mit dem Domainnamen in der Clientanfrage übereinstimmenden gemeinsamen Namen (Common Name, CN) hat, zeigt der Load-Balancer das Hauptzertifikat an.

• Für die im Block tls aufgeführten Secrets befindet sich das Hauptzertifikat im ersten Secret in der Liste.

• Bei vorinstallierten Zertifikaten, die in der Annotation aufgeführt werden, ist das erste Zertifikat in der Liste das Hauptzertifikat.

Best Practices für die Zertifikatsrotation

Wenn Sie den Inhalt Ihres Secrets oder eines vorinstallierten Zertifikats rotieren möchten, beachten Sie dazu die folgenden Best Practices:

• Erstellen Sie ein neues Secret oder ein vorinstalliertes Zertifikat mit einem anderen Namen, das die neuen Zertifikatsdaten enthält. Hängen Sie diese Ressource (zusammen mit der vorhandenen Ressource) anhand der zuvor bereitgestellten Anleitung an das Ingress-Objekt an. Wenn die Änderungen Ihren Anforderungen entsprechen, können Sie das alte Zertifikat aus dem Ingress-Objekt entfernen.
• Wenn die Unterbrechung des Traffics kein Problem ist, können Sie die alte Ressource aus dem Ingress-Objekt entfernen, eine neue Ressource mit dem gleichen Namen, aber mit anderem Inhalt bereitstellen und sie dann wieder an das Ingress-Objekt anhängen.

Wie Sie vermeiden können, die Zertifikatsrotation selbst zu verwalten, erfahren Sie unter Von Google verwaltete SSL-Zertifikate verwenden.

Fehlerbehebung

Die Angabe ungültiger oder nicht vorhandener Secrets führt zu einem Kubernetes-Ereignisfehler. Sie können Kubernetes-Ereignisse für ein Ingress so überprüfen:

kubectl describe ingress

Die Ausgabe sieht in etwa so aus:

Name:             my-ingress
Namespace:        default
Address:          203.0.113.3
Default backend:  hello-server:8080 (10.8.0.3:8080)
TLS:
  my-faulty-Secret terminates
Rules:
  Host  Path  Backends
  ----  ----  --------
  *     *     my-service:443 (10.8.0.3:443)
Events:
   Error during sync: cannot get certs for Ingress default/my-ingress:
 Secret "my-faulty-ingress" has no 'tls.crt'

Nächste Schritte

• GKE-Netzwerk –Übersicht

• Domainnamen mit statischen IP-Adressen konfigurieren

• Wenn eine Anwendung in mehreren GKE-Clustern in verschiedenen Regionen ausgeführt wird, konfigurieren Sie eine Multi-Cluster-Ingress-Ressource, um den Traffic zu einem Cluster in der dem Nutzer nächstgelegenen Region zu leiten.