Traffic für GKE Ingress sichern

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie den Traffic für GKE-Ingress (Google Kubernetes Engine) schützen und optimieren. Sie können SSL-Zertifikate zwischen dem Client und dem Load-Balancer konfigurieren und den Traffic zwischen dem Load-Balancer und Ihrer Backend-Anwendung sichern. Bevor Sie fortfahren, sollten Sie sich damit vertraut machen, wie GKE Ingress mit HTTPS schützt.

Diese Seite richtet sich an Netzwerkspezialisten, die das Netzwerk für ihre Organisation entwerfen und erstellen sowie Netzwerkgeräte installieren, konfigurieren und unterstützen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Traffic zwischen Client und Load Balancer sichern und optimieren

Wenn Sie HTTPS-Anfragen von Ihren Clients annehmen möchten, muss der Load-Balancer ein Zertifikat haben, um seine Identität gegenüber Ihren Clients nachzuweisen. Der Load-Balancer benötigt außerdem einen privaten Schlüssel, um den HTTPS-Handshake abzuschließen. Weitere Informationen zum Bereitstellen von SSL-Zertifikaten für einen HTTP(S)-Load-Balancer finden Sie unter TLS zwischen dem Client und dem Load-Balancer konfigurieren.

Von Google verwaltete Zertifikate verwenden

So konfigurieren Sie ein oder mehrere von Google verwaltete SSL-Zertifikate und verknüpfen sie mit einem Ingress:

• Erstellen Sie ein oder mehrere ManagedCertificate-Objekte im selben Namespace wie der Ingress. Sie können bis zu 15 Zertifikate für den Load-Balancer angeben.
• Verknüpfen Sie die ManagedCertificate-Objekte mit einem Ingress. Dazu fügen Sie dem Ingress die Annotation networking.gke.io/managed-certificates hinzu. Diese Annotation ist eine durch Kommas getrennte Liste von ManagedCertificate-Objekten.

Hinweis: Die Verwendung von von Google verwalteter SSL-Zertifikate mit Ingress hat keine Auswirkungen auf Ihre Konfiguration von Regeln für eingehenden Traffic.

Beschränkungen

In diesem Abschnitt werden die Einschränkungen von von Google verwalteten Zertifikaten beschrieben. Wenn Sie selbstverwaltete Zertifikate benötigen oder bereits SSL-Zertifikate haben, die Sie für das Ingress konfigurieren möchten, finden Sie entsprechende Informationen unter HTTPS (TLS) zwischen Client und Load Balancer einrichten.

• Von Google verwaltete Zertifikate bieten nicht das gleiche Maß an Flexibilität wie die von Ihnen abgerufenen und verwalteten Zertifikate. Von Google verwaltete Zertifikate unterstützen bis zu 100 Domains ohne Platzhalter. Im Gegensatz zu selbstverwalteten Zertifikaten unterstützen von Google verwaltete Zertifikate keine Domains mit Platzhaltern.

• Die Anzahl und der Typ der von einem Ingress unterstützten Zertifikate richten sich nach den Limits der von Google verwalteten SSL-Zertifikate.

• Aktualisierungen für von Google verwaltete Zertifikate werden nicht unterstützt. Weitere Informationen finden Sie unter Von Google verwaltetes Zertifikat manuell aktualisieren.

• Wenn das Zertifikat direkt mit der Zertifizierungsstelle widerrufen wird, rotiert Google das Zertifikat nicht automatisch. Sie müssen das ManagedCertificate löschen und ein neues erstellen.

• GKE Ingress unterstützt keine vom Zertifikatmanager verwalteten Zertifikate. Wenn Sie vom Zertifikatsmanager verwaltete Zertifikate verwenden möchten, nutzen Sie die Gateway API.

Warnung :Der Zielproxy des Load-Balancers, der von der Ingress-Ressource erstellt wurde, kann auf bis zu 15 Compute Engine-SSL-Zertifikate verweisen. Die Ingress-Annotation ingress.gcp.kubernetes.io/pre-shared-cert enthält alle SSL-Zertifikate managed-certificates und self-managed, die mit dem Zielproxy des Load Balancers bereitgestellt werden.

Vorbereitung

• Sie müssen Inhaber des Domainnamens sein. Der Domainname darf maximal 63 Zeichen haben. Sie können einen beliebigen Domainnamenregistrator verwenden, um einen Domainnamen zu erhalten.

  Hinweis :Google Domains ist nicht mehr in Betrieb. Squarespace verwaltet jetzt Domains, die zuvor bei Google Domains gekauft wurden. Sie können Ihre Domain und ihre DNS-Einträge über Ihr Squarespace-Konto verwalten.

• Wenn Sie einen GKE Standard-Cluster verwenden, muss das Add-on HttpLoadBalancing aktiviert sein.

• Ihr Ingress-Manifest muss die Annotation kubernetes.io/ingress.class: "gce" enthalten. Das Feld ingressClassName wird nicht unterstützt.

• Sie müssen Ressourcen vom Typ Ingress und ManagedCertificate im selben Projekt und im selben Namespace anwenden.

• Erstellen Sie eine reservierte (statische) externe IP-Adresse. Wenn Sie eine statische IP-Adresse reservieren, bleibt diese auch nach dem Löschen des Ingress-Objekts erhalten. Wenn Sie keine IP-Adresse reservieren, kann sich die verwendete Adresse ändern, sodass Sie die DNS-Einträge Ihrer Domain neu konfigurieren müssen. Verwenden Sie die Google Cloud CLI oder die Google Cloud Console, um eine reservierte IP-Adresse zu erstellen.

  gcloud

  Führen Sie den folgenden Befehl aus, um eine reservierte IP-Adresse zu erstellen:

  gcloud compute addresses create ADDRESS_NAME --global
  

  Ersetzen Sie ADDRESS_NAME durch den Namen der reservierten IP-Adresse, die Sie erstellen.

  Führen Sie den folgenden Befehl aus, um die erstellte statische IP-Adresse zu finden:

  gcloud compute addresses describe ADDRESS_NAME --global
  

  Die entsprechende Ausgabe sieht etwa so aus:

  address: 203.0.113.32
  ...
  

  Console

  Führen Sie die folgenden Schritte aus, um eine reservierte IP-Adresse zu erstellen:

  1. Rufen Sie in der Google Cloud Console die Seite Externe IP-Adressen auf.

     Zu externen IP-Adressen

  2. Geben Sie einen Namen für die IP-Adresse an (z. B. example-ip-address).

  3. Geben Sie an, ob Sie eine IPv4- oder IPv6-Adresse möchten.

  4. Wählen Sie für Typ die Option Global aus.

  5. Klicken Sie auf Reservieren. Die IP-Adresse wird in der Spalte Externe Adresse aufgeführt.

  Config Connector

  Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

  apiVersion: compute.cnrm.cloud.google.com/v1beta1
  kind: ComputeAddress
  metadata:
    name: example-ip-address
  spec:
    location: global

  Laden Sie dieses Manifest als compute-address.yaml auf Ihren Computer herunter und führen Sie folgenden Befehl aus:

  kubectl apply -f compute-address.yaml
  

Von Google verwaltetes Zertifikat einrichten

1. Erstellen Sie ein ManagedCertificate-Objekt. Diese Ressource gibt die Domains für das SSL-Zertifikat an. Domains mit Platzhaltern werden nicht unterstützt.

   Das folgende Manifest beschreibt ein ManagedCertificate-Objekt. Speichern Sie das Manifest als managed-cert.yaml.

   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.

2. Wenden Sie das Manifest auf Ihren Cluster an:

   kubectl apply -f managed-cert.yaml
   

3. Folgen Sie der Anleitung zum Erstellen eines Deployments und eines Service, um Ihre Anwendung im Internet bereitzustellen.

4. Damit dieses ManagedCertificate-Objekt Active wird, hängen Sie es mit der Annotation networking.gke.io/managed-certificates an Ihr Ingress an, wie im folgenden Beispiel. Das ManagedCertificate muss nicht bereits Active sein, damit Sie ihn an ein Ingress anhängen können.

    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
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   
   Note: It might take several hours for Google Cloud to provision the load
   balancer and the managed certificates, and for the load balancer to begin
   using the new certificates. For more information, see
   [Deploy a Google-managed certificate with load balancer authorization](/certificate-manager/docs/deploy-google-managed-lb-auth#wait_until_the_certificate_has_been_activated).
   

5. Warten Sie, bis die Bereitstellung der von Google verwalteten Zertifikate abgeschlossen ist. Dies kann bis zu 60 Minuten dauern. Sie können den Status der Zertifikate mit dem folgenden Befehl prüfen:

   kubectl describe managedcertificate managed-cert
   

   Die Ausgabe sieht etwa so aus:

   Name:         managed-cert
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  networking.gke.io/v1
   Kind:         ManagedCertificate
   (...)
   Spec:
    Domains:
      FQDN_1
      FQDN_2
   Status:
    CertificateStatus: Active
   (...)
   

   Der Wert des Felds Status.CertificateStatus gibt an, dass das Zertifikat bereitgestellt wird. Wenn Status.CertificateStatus nicht Active ist, wurde das Zertifikat noch nicht bereitgestellt.

6. Prüfen Sie, ob die SSL-Verbindung funktioniert. Rufen Sie hierfür Ihre Domains mit dem Präfix https:// auf. Ihr Browser gibt an, dass die Verbindung sicher ist und Sie die Zertifikatdetails aufrufen können.

Von selbstverwalteten Zertifikaten zu von Google verwalteten Zertifikaten migrieren

Wenn Sie einen Ingress von selbstverwalteten Zertifikaten zu von Google verwalteten SSL-Zertifikaten migrieren, löschen Sie die selbstverwalteten SSL-Zertifikate erst, wenn die von Google verwalteten SSL-Zertifikate aktiv sind. Die Aktivierung der von Google verwalteten SSL-Zertifikate erfolgt automatisch nach der Bereitstellung. Sobald die von Google verwalteten SSL-Zertifikate aktiv sind, können Sie Ihre selbstverwalteten SSL-Zertifikate löschen.

Führen Sie die folgenden Schritte aus, um von selbstverwalteten Zertifikaten zu von Google verwalteten Zertifikaten zu migrieren.

1. Fügen Sie dem Ingress gemäß der Beschreibung im vorherigen Abschnitt ein neues von Google verwaltetes Zertifikat hinzu.

2. Warten Sie, bis der Status der von Google verwalteten Zertifikatsressource Active lautet. Prüfen Sie den Status des Zertifikats mit dem folgenden Befehl:

   kubectl describe managedcertificate managed-cert
   

3. Wenn der Status Active lautet, aktualisieren Sie den Ingress, um die Verweise auf das selbstverwaltete Zertifikat zu entfernen.

Von Google verwaltetes Zertifikat entfernen

Wenn Sie ein von Google verwaltetes Zertifikat aus dem Cluster entfernen möchten, löschen Sie das ManagedCertificate-Objekt und entfernen Sie die darauf verweisende Ingress-Annotation.

1. Löschen Sie das ManagedCertificate-Objekt:

   kubectl delete -f managed-cert.yaml
   

   Die entsprechende Ausgabe sieht etwa so aus:

   managedcertificate.networking.gke.io "managed-cert" deleted
   

2. Entfernen Sie die Annotation aus dem Ingress:

   kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-
   

   Achten Sie auf das Minuszeichen - am Ende des Befehls.

3. Geben Sie die statische IP-Adresse frei, die Sie für den Load-Balancer reserviert hatten.

   Sie können die Google Cloud CLI, die Google Cloud Console oder Config Connector verwenden, um eine reservierte IP-Adresse freizugeben.

   gcloud

   Verwenden Sie den folgenden Befehl, um die reservierte IP-Adresse freizugeben:

   gcloud compute addresses delete ADDRESS_NAME --global
   

   Ersetzen Sie ADDRESS_NAME durch den Namen der IP-Adresse.

   Console

   Führen Sie die folgenden Schritte aus, um die reservierte IP-Adresse freizugeben:

   1. Rufen Sie in der Google Cloud Console die Seite Externe IP-Adressen auf.

      Zu externen IP-Adressen

   2. Aktivieren Sie das Kästchen neben der IP-Adresse, die Sie freigeben möchten.

   3. Klicken Sie auf IP-Adresse freigeben.

   Config Connector

   Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

   apiVersion: compute.cnrm.cloud.google.com/v1beta1
   kind: ComputeAddress
   metadata:
     name: example-ip-address
   spec:
     location: global

   Laden Sie dieses Manifest als compute-address.yaml auf Ihren Computer herunter und führen Sie folgenden Befehl aus:

   kubectl delete -f compute-address.yaml
   

Zertifikate und Schlüssel erstellen

Wenn Sie vorinstallierte Zertifikate oder Kubernetes-Secrets verwenden möchten, benötigen Sie zuerst ein oder mehrere Zertifikate mit den entsprechenden privaten Schlüsseln. Jedes Zertifikat benötigt einen „Common Name“ (CN), der einem Ihrer Domainnamen entspricht. Wenn Sie bereits zwei Zertifikatsdateien mit den entsprechenden Werten für Common Name haben, können Sie mit dem nächsten Abschnitt fortfahren.

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 einem 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 Wörter FIRST und SECOND weisen nicht auf eine Reihenfolge hin. Sie helfen Ihnen nur, Ihre zwei Domains, Ihre zwei Zertifikatsdateien und die jeweiligen Schlüsseldateien zu verfolgen.

Vorinstallierte Zertifikate verwenden

Sie können selbstverwaltete SSL-Zertifikate verwenden, die Sie in Ihr Google Cloud -Projekt hochladen. Diese werden als vorinstallierte Zertifikate bezeichnet. Sie können ein oder mehrere vorinstallierte Zertifikate für ein Ingress angeben.

So verwenden Sie mehrere vorinstallierte Zertifikate:

1. Erstellen Sie für jedes Ihrer Zertifikats- und Schlüsselpaare eine öffentlich sichtbare SSL-Zertifikatsressource in Google Cloud.

    gcloud compute ssl-certificates create FIRST_CERT_NAME \
        --certificate=FIRST_CERT_FILE \
        --private-key=FIRST_KEY_FILE
    ```
   
   ```sh
    gcloud compute ssl-certificates create SECOND_CERT_NAME \
        --certificate=SECOND_CERT_FILE \
        --private-key=SECOND_KEY_FILE
    ```
   
   Replace the following:
   

   • FIRST_CERT_NAME, SECOND_CERT_NAME: die Namen Ihres ersten und zweiten Zertifikats.
   • FIRST_CERT_FILE, SECOND_CERT_FILE: Ihre erste und zweite Zertifikatsdatei.
   • FIRST_KEY_FILE und SECOND_KEY_FILE: Ihre erste und zweite Schlüsseldatei.

2. Fügen Sie in Ihr Ingress-Manifest die Annotation ingress.gcp.kubernetes.io/pre-shared-cert ein. Der Wert der Annotation ist eine durch Kommas getrennte Liste Ihrer Zertifikatsnamen. Fügen Sie außerdem im Abschnitt spec.rules die Felder host ein, um die Domains für Ihre Dienste anzugeben.

    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
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   

Kubernetes-Secrets verwenden

Wenn Sie einen HTTP(S)-Load-Balancer mit selbst erstellten Zertifikaten und Schlüsseln bereitstellen möchten, müssen Sie ein oder mehrere Kubernetes-Secret-Objekte erstellen. Jedes Secret enthält ein Zertifikat und einen Schlüssel. Fügen Sie die Secrets dem Feld tls des Ingress-Manifests hinzu. Der Load-Balancer ermittelt mit „Server Name Indication“ (SNI) anhand des Domainnamens im TLS-Handshake, welches Zertifikat dem Client präsentiert werden soll.

So verwenden Sie mehrere Zertifikate:

1. Erstellen Sie für jedes Zertifikat- und Schlüsselpaar ein Secret:

    kubectl create secret tls FIRST_SECRET_NAME \
        --cert=FIRST_CERT_FILE \
        --key=FIRST_KEY_FILE
    ```
   
   ```sh
    kubectl create secret tls SECOND_SECRET_NAME \
        --cert=SECOND_CERT_FILE \
        --key=SECOND_KEY_FILE
    ```
   

2. Listen Sie in Ihrem Ingress-Manifest im Abschnitt spec.tls die Secrets auf, die Sie erstellt haben. Fügen Sie außerdem im Abschnitt spec.rules die Felder host ein, um die Domains für Ihre Dienste anzugeben.

   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.

Änderungen an Secrets werden regelmäßig abgerufen. Wenn Sie also die Daten im Secret ändern, dauert es maximal 10 Minuten, bis diese Änderungen auf den Load-Balancer angewendet werden.

Informationen zum Schutz von HTTPS-verschlüsseltem Ingress für Ihre GKE-Cluster finden Sie unter Secure Ingress.

HTTP deaktivieren

Wenn der gesamte Traffic zwischen dem Client und dem Load-Balancer HTTPS verwenden soll, können Sie HTTP deaktivieren. Dazu nehmen Sie die Anmerkung kubernetes.io/ingress.allow-http in Ihr Ingress-Manifest auf. Legen Sie den Wert der Anmerkung auf "false" fest.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

Dieses Manifest enthält den SECRET_NAME, also den Namen des von Ihnen erstellten Secrets.

Hinweis: Wenn Sie die Annotation networking.gke.io/managed-certificates verwenden, können Sie die Annotation kubernetes.io/ingress.allow-http: false nicht verwenden. Sie können erst dann Ingress aktualisieren und die Annotation kubernetes.io/ingress.allow-http: false hinzufügen, wenn der externe Application Load Balancer vollständig programmiert ist.

Achtung: Das Deaktivieren von HTTP wird für Multi-Cluster-Ingress nicht unterstützt.

HTTP/2 zwischen Client und Load-Balancer

Clients können HTTP/2 verwenden, um Anfragen an den Load-Balancer zu senden. Es ist keine Konfiguration erforderlich.

Traffic zwischen Load-Balancer und Anwendung sichern und optimieren

Sie können das Protokoll für die Kommunikation zwischen dem Load-Balancer und Ihren Anwendungs-Pods konfigurieren, um eine Ende-zu-Ende-Sicherheit zu gewährleisten oder die Leistung des internen Traffics zu optimieren. Der Load-Balancer verwendet standardmäßig unverschlüsseltes HTTP/1.1 für Backend-Verbindungen. Sie können jedoch HTTPS oder HTTP/2 aktivieren, um die spezifischen Anforderungen Ihrer Anwendung zu erfüllen.

HTTPS zwischen Load-Balancer und Anwendung

Wenn Ihre in einem GKE-Pod ausgeführte Anwendung HTTPS-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass er bei der Weiterleitung von Anfragen an die Anwendung HTTPS verwendet. Weitere Informationen finden Sie unter HTTPS (TLS) zwischen dem Load-Balancer und Ihrer Anwendung.

Verwenden Sie zum Konfigurieren des Protokolls, das zwischen dem Load-Balancer und Ihrer Anwendung verwendet wird, die Anmerkung cloud.google.com/app-protocols in Ihrem Dienstmanifest. Dieses Dienstmanifest muss type: NodePort enthalten, sofern Sie nicht containernatives Load-Balancing verwenden. Wenn Sie containernatives Load-Balancing verwenden, nutzen Sie type: ClusterIP.

Das folgende Dienstmanifest legt zwei Ports fest. Die Anmerkung besagt, dass ein HTTP(S)-Load-Balancer, der auf Port 80 des Dienstes gerichtet ist, HTTP verwenden soll. Wenn der Load-Balancer hingegen auf Port 443 des Dienstes gerichtet ist, sollte er HTTPS verwenden.

Das Dienstmanifest muss in der Portannotation einen name-Wert enthalten. Den Dienstport können Sie nur bearbeiten, wenn Sie auf den zugewiesenen name verweisen und nicht auf seinen targetPort-Wert.

Achtung :Bearbeiten Sie den Portnamen des Dienstes nicht, wenn Sie dieses Feature aktivieren, um potenzielle Ausfallzeiten zu begrenzen. Wenn der Port Ihres Dienstes keinen Namen hat, verwenden Sie den leeren Portnamen als Schlüssel in der Annotation, ähnlich wie cloud.google.com/app-protocols: '{"": "HTTPS"}'. Die Bearbeitung des Portnamens oder der Annotation nach der Ersteinrichtung kann zu einem Ausfall Ihrer Anwendungen führen.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

HTTP/2 zwischen Load-Balancer und Anwendung verwenden

Wenn Ihre in einem GKE-Pod ausgeführte Anwendung HTTP/2-Anfragen empfangen kann, können Sie den Load-Balancer so konfigurieren, dass bei der Weiterleitung von Anfragen an die Anwendung HTTP/2 verwendet wird.

Wenn Sie HTTP/2 aktivieren möchten, müssen Sie die cloud.google.com/app-protocols-Annotation im Kubernetes-Dienstmanifest verwenden. Mit dieser Annotation wird das Protokoll angegeben, das der Load-Balancer für die Kommunikation mit Ihrer Anwendung verwendet. Damit der Load-Balancer eine korrekte HTTP/2-Anfrage an Ihr Backend senden kann, muss Ihr Backend mit SSL konfiguriert sein.

Das folgende Beispiel zeigt ein für HTTP/2 konfiguriertes Dienstmanifest:

apiVersion: v1
kind: Service
metadata:
  name: my-http2-service
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: my-port
    protocol: TCP
    port: 443
    targetPort: 8443

Wichtige Hinweise:

• Die Annotation cloud.google.com/app-protocols ist auf '{"my-port":"HTTP2"}' gesetzt. Dadurch wird der Load-Balancer angewiesen, HTTP/2 für Traffic zu verwenden, der an den Port mit dem Namen my-port gesendet wird.
• Der Port ist auf 443 festgelegt und leitet Traffic an Pods auf targetPort 8443 weiter.