Fehlerbehebung bei GKE Ingress

Probleme mit Ingress in Google Kubernetes Engine (GKE) können verhindern, dass externer oder interner Traffic Ihre Dienste erreicht.

In diesem Dokument finden Sie Lösungen für Fehler im Zusammenhang mit der Ingress-Klasse, statischen IP-Annotationen, Zertifikatschlüsselgrößen und Interaktionen mit Netzwerkebenen.

Diese Informationen richten sich an Plattformadministratoren und ‑operatoren sowie Anwendungsentwickler, die Anwendungen bereitstellen und verwalten, die über Ingress in GKE verfügbar gemacht werden. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Falsche Annotation für die Ingress-Klasse

Symptom

Wenn Sie ein Ingress erstellen, wird möglicherweise der folgende Fehler angezeigt:

Missing one or more resources. If resource creation takes longer than expected, you might have an invalid configuration.

Mögliche Ursachen

Möglicherweise haben Sie beim Erstellen des Ingress die Ingress-Klasse im Manifest falsch konfiguriert.

Lösung

Wenn Sie eine Ingress-Klasse angeben möchten, müssen Sie die Annotation kubernetes.io/ingress.class verwenden. Sie können einen GKE-Ingress nicht mit spec.ingressClassName angeben.

  • Verwenden Sie die Annotation kubernetes.io/ingress.class: gce-internal, um einen internen Application Load Balancer bereitzustellen.
  • Verwenden Sie die Annotation kubernetes.io/ingress.class: gce, um einen externen Application Load Balancer bereitzustellen.

Falsche Anmerkung für die statische IP-Adresse

Symptom

Wenn Sie ein externes Ingress-Objekt für die Verwendung einer statischen IP-Adresse konfigurieren, wird möglicherweise der folgende Fehler angezeigt:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer <Name of load balancer> does not exist: the given static IP name <Static IP> doesn't translate to an existing static IP.

Mögliche Ursachen

  • Sie haben keine statische externe IP-Adresse erstellt, bevor Sie die Ingress-Ressource bereitgestellt haben.
  • Sie verwenden nicht die richtige Annotation für Ihren Load Balancer-Typ.

Lösung

Wenn Sie einen externen Ingress konfigurieren:

Wenn Sie einen internen Ingress konfigurieren, gehen Sie so vor:

  • Reservieren Sie eine regionale statische interne IP-Adresse, bevor Sie den Ingress bereitstellen.
  • Verwenden Sie die Annotation kubernetes.io/ingress.regional-static-ip-name für Ihre Ingress-Ressource.

Die statische IP-Adresse wird bereits verwendet

Symptom

Möglicherweise wird der folgende Fehler angezeigt, wenn Sie eine statische IP-Adresse angeben, um Ihre interne oder externe Ingress-Ressource bereitzustellen:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <LB name> does not exist:
googleapi: Error 409: IP_IN_USE_BY_ANOTHER_RESOURCE - IP ''<IP address>'' is already being used by another resource.

Mögliche Ursachen

Die statische IP-Adresse wird bereits von einer anderen Ressource verwendet.

Fehler beim Deaktivieren von HTTP und Verwenden eines von Google verwalteten Zertifikats

Symptom

Wenn Sie ein von Google verwaltetes SSL-Zertifikat konfigurieren und HTTP-Traffic für Ihren Ingress deaktivieren, wird der folgende Fehler angezeigt:

Error syncing to GCP: error running load balancer syncing
routine: loadbalancer <Load Balancer name> does not exist:
googleapi: Error 404: The resource ''projects/<Project>/global/sslPolicies/<Policy name>' was not found, notFound

Mögliche Ursachen

Die folgenden Anmerkungen können Sie nicht zusammen verwenden, wenn Sie den Ingress konfigurieren:

  • networking.gke.io/managed-certificates (zum Verknüpfen des von Google verwalteten Zertifikats mit einem Ingress)
  • kubernetes.io/ingress.allow-http: false (zum Deaktivieren von HTTP-Traffic)

Lösung

Deaktivieren Sie den HTTP-Traffic erst, wenn der externe Application Load Balancer vollständig programmiert ist. Sie können das Ingress-Objekt aktualisieren und dem Manifest die Annotation kubernetes.io/ingress.allow-http: false hinzufügen.

Nur-Proxy-Subnetz für einen internen Ingress fehlt

Symptom

Wenn Sie ein Ingress für einen internen Application Load Balancer bereitstellen, wird möglicherweise der folgende Fehler angezeigt:

Error syncing to GCP: error running load balancer syncing routine:
loadbalancer <LB name> does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/<Project ID>/regions/<Region>/targetHttpsProxies/<Target proxy>'.
An active proxy-only subnetwork is required in the same region and VPC as
the forwarding rule.

Mögliche Ursachen

Sie haben kein Nur-Proxy-Subnetz erstellt, bevor Sie die Ingress-Ressource erstellt haben. Für interne Application Load Balancer ist ein Nur-Proxy-Subnetz erforderlich.

Lösung

Erstellen Sie ein Nur-Proxy-Subnetz, bevor Sie den internen Ingress bereitstellen.

Der Schlüssel des SSL-Zertifikats ist zu groß.

Symptom

Wenn die Schlüsselgröße des SSL-Zertifikats Ihres Load-Balancers zu groß ist, wird möglicherweise der folgende Fehler angezeigt:

Error syncing to GCP: error running load balancer syncing routine: loadbalancer gky76k70-load-test-trillian-api-ingress-fliismmb does not exist: Cert creation failures - k8s2-cr-gky76k70-znz6o1pfu3tfrguy-f9be3a4abbe573f7 Error:googleapi: Error 400: The SSL key is too large., sslCertificateKeyTooLarge

Mögliche Ursachen

Google Cloud hat ein Limit von 2.048 Bit für SSL-Zertifikatschlüssel.

Lösung

Reduzieren Sie die Größe des SSL-Zertifikatschlüssels auf maximal 2.048 Bit.

Fehler beim Erstellen eines Ingress in der Standardstufe

Symptom

Wenn Sie ein Ingress in einem Projekt bereitstellen, in dem die Standardnetzwerkstufe des Projekts auf Standard gesetzt ist, wird die folgende Fehlermeldung angezeigt:

Error syncing to GCP: error running load balancer syncing routine: load balancer <LB Name> does not exist: googleapi: Error 400: STANDARD network tier (the project''s default network tier) is not supported: STANDARD network tier is not supported for global forwarding rule., badRequest

Lösung

Konfigurieren Sie die Standard-Netzwerkstufe des Projekts auf „Premium“.

Erwarteter Fehler „Nicht gefunden“ für k8s-ingress-svc-acct-permission-check-probe

Der Ingress-Controller führt regelmäßig Prüfungen der Dienstkontoberechtigungen aus. Dazu wird eine Testressource aus Ihrem Google Cloud -Projekt abgerufen. Dies wird als GET-Anfrage des (nicht vorhandenen) globalen BackendService-Objekts mit dem Namen k8s-ingress-svc-acct-permission-check-probe angegeben. Da diese Ressource normalerweise nicht vorhanden ist, gibt die GET-Anfrage „Nicht gefunden“ zurück. Dies so vorgesehen. Der Controller prüft, ob der API-Aufruf aufgrund von Autorisierungsproblemen abgelehnt wurde. Wenn Sie einen BackendService mit demselben Namen erstellen, ist die GET-Anfrage erfolgreich, d. h. „Nicht gefunden“ wird nicht zurückgegeben.

Fehler bei der Verwendung von containernativem Load-Balancing

Verwenden Sie die folgenden Methoden, um Ihre Netzwerkkonfiguration zu prüfen. In den folgenden Abschnitten wird erläutert, wie Sie spezifische Probleme im Zusammenhang mit containernativem Load-Balancing lösen.

  • Informationen zum Auflisten von Netzwerk-Endpunktgruppen finden Sie in der Dokumentation zum Load-Balancing.

  • Den Namen und die Zonen der NEG, die einem bestimmten Dienst entspricht, finden Sie in der neg-status-Annotation des Diensts. Rufen Sie die Dienstspezifikation mit folgendem Befehl ab:

    kubectl get svc SVC_NAME -o yaml

    In der metadata:annotations:cloud.google.com/neg-status-Annotation sind der Name der NEG des Diensts und die Zonen der NEG aufgelistet.

  • Mit dem folgenden Befehl können Sie den Status des Back-End-Diensts, der einer bestimmten NEG entspricht, prüfen:

    gcloud compute backend-services --project PROJECT_NAME \
    get-health BACKEND_SERVICE_NAME --global

    Der Back-End-Dienst trägt denselben Namen wie seine NEG.

  • So drucken Sie die Ereignislogs eines Diensts:

    kubectl describe svc SERVICE_NAME

    Der Namensstring des Diensts enthält den Namen und den Namespace des zugehörigen GKE-Diensts.

Cluster mit Alias-IP-Adressen kann nicht erstellt werden

Symptome

Wenn Sie einen Cluster mit Alias-IP-Adressen erstellen, wird möglicherweise der folgende Fehler ausgegeben:

ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
Mögliche Ursachen

Dieser Fehler tritt auf, wenn der mit Alias-IP-Adressen zu erstellende Cluster auch ein Legacy-Netzwerk verwendet.

Lösung

Achten Sie darauf, dass Sie keinen Cluster mit Alias-IP-Adressen erstellen, für den gleichzeitig ein Legacy-Netzwerk aktiviert ist. Weitere Informationen zur Verwendung von Alias-IP-Adressen finden Sie unter VPC-nativen Cluster erstellen.

Traffic erreicht Endpunkte nicht

Symptome
502/503-Fehler oder abgelehnte Verbindungen
Mögliche Ursachen

Normalerweise sind neue Endpunkte erreichbar, nachdem sie dem Load-Balancer hinzugefügt wurden – sofern sie auf Systemdiagnosen reagieren. Wenn der Traffic die Endpunkte nicht erreicht, können 502-Fehler auftreten oder Verbindungen abgelehnt werden.

502-Fehler und abgelehnte Verbindungen können auch durch einen Container verursacht werden, der SIGTERM nicht verarbeitet. Wenn ein Container SIGTERM nicht explizit verarbeitet, wird er sofort beendet und verarbeitet keine Anfragen mehr. Der Load-Balancer sendet weiterhin eingehenden Traffic an den beendeten Container, was zu Fehlern führt.

Der native Container-Load-Balancer hat nur einen Back-End-Endpunkt. Während eines Rolling Updates wird der alte Endpunkt deprogrammiert, bevor der neue Endpunkt programmiert wird.

Back-End-Pods werden zum ersten Mal in einer neuen Zone bereitgestellt, nachdem ein containernativer Load-Balancer bereitgestellt wurde. Die Load-Balancer-Infrastruktur wird in einer Zone programmiert, wenn mindestens ein Endpunkt in der Zone vorhanden ist. Wenn ein neuer Endpunkt zu einer Zone hinzugefügt wird, wird die Infrastruktur des Load-Balancers programmiert und führt zu Dienstunterbrechungen.

Lösung

Konfigurieren Sie die Container so, dass sie SIGTERM verarbeiten und während des gesamten Kulanzzeitraums für die Beendigung, der standardmäßig 30 Sekunden beträgt, weiterhin auf Anfragen antworten. Konfigurieren Sie die Pods so, dass Systemdiagnosen fehlschlagen, wenn sie SIGTERM empfangen. Dies signalisiert dem Load-Balancer, dass er keinen Traffic mehr an den Pod senden soll, solange die Endpunkt-Deprogrammierung ausgeführt wird.

Wenn Ihre Anwendung nicht ordnungsgemäß heruntergefahren wird und nicht mehr auf Anfragen reagiert, wenn sie einen SIGTERM empfängt, kann der PreStop-Hook verwendet werden, um SIGTERM zu verarbeiten und den Traffic weiterhin weiterzuleiten, während die Endpunkt-Deprogrammierung ausgeführt wird.

lifecycle:
  preStop:
    exec:
      # if SIGTERM triggers a quick exit; keep serving traffic instead
      command: ["sleep","60"]

Weitere Informationen finden Sie in der Dokumentation zum Beenden von Pods.

Wenn das Back-End Ihres Load-Balancers nur eine Instanz hat, konfigurieren Sie die Rollout-Strategie so, dass nicht die einzige Instanz gelöscht wird, bevor die neue Instanz vollständig programmiert ist. Konfigurieren Sie bei Anwendungs-Pods, die von der Deployment-Arbeitslast verwaltet werden, die Rollout-Strategie so, dass der Parameter maxUnavailable dem Wert 0 entspricht.

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Um das Problem zu beheben, dass Traffic die Endpunkte nicht erreicht, prüfen Sie, ob die Firewallregeln eingehenden TCP-Traffic an die Endpunkte in den Bereichen 130.211.0.0/22 und 35.191.0.0/16 zulassen. Weitere Informationen finden Sie in der Dokumentation zu Cloud Load Balancing unter Systemdiagnosen erstellen.

Listen Sie die Backend-Dienste in Ihrem Projekt auf. Der Namensstring des relevanten Back-End-Dienstes enthält den Namen und den Namespace des zugehörigen GKE-Dienstes:

gcloud compute backend-services list

Rufen Sie den Back-End-Systemstatus aus dem Back-End-Dienst ab:

gcloud compute backend-services get-health BACKEND_SERVICE_NAME

Wenn alle Back-Ends fehlerhaft sind, ist Ihre Firewall, Ihre Ingress-Ressource oder Ihr Dienst möglicherweise falsch konfiguriert.

Wenn einige Back-Ends für kurze Zeit fehlerhaft sind, könnte dies auf Netzwerk-Programmierlatenz zurückzuführen sein.

Wenn einige Back-Ends nicht in der Liste der Back-End-Dienste aufgeführt werden, könnte dies auf Programmierlatenz zurückzuführen sein. Sie können dies mit folgendem Befehl überprüfen, wobei NEG_NAME der Name des Back-End-Diensts ist. NEGs und Back-End-Dienste haben denselben Namen:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Prüfen Sie, ob alle erwarteten Endpunkte in der NEG enthalten sind.

Wenn Sie eine kleine Anzahl von Back-Ends (z. B. 1 Pod) haben, die von einem nativen Container-Load-Balancer ausgewählt werden, sollten Sie die Anzahl der Replikate erhöhen und die Back-End-Pods auf alle Zonen verteilen, die der GKE-Cluster umfasst. Dadurch wird die zugrunde liegende Load-Balancer-Infrastruktur vollständig programmiert. Andernfalls sollten Sie die Back-End-Pods auf eine einzelne Zone beschränken.

Wenn Sie eine Netzwerkrichtlinie für den Endpunkt konfigurieren, achten Sie darauf, dass eingehender Traffic vom Nur-Proxy-Subnetz zugelassen wird.

Einführung wurde angehalten

Symptome
Das Rollout eines aktualisierten Deployments wird angehalten und die Anzahl der Replikate, die auf dem neuesten Stand sind, stimmt nicht mit der gewünschten Anzahl von Replikaten überein.
Mögliche Ursachen

Die Systemdiagnosen des Deployments können nicht ausgeführt werden. Möglicherweise ist das Container-Image fehlerhaft oder die Systemdiagnose falsch konfiguriert. Mit dem rollierenden Ersetzen der Pods wird gewartet, bis das Pod-Readiness-Gate des neu gestarteten Pods den Status "True" aufweist. Dies geschieht nur, wenn der Pod auf Load-Balancer-Systemdiagnosen reagiert. Wenn der Pod nicht reagiert oder die Systemdiagnose falsch konfiguriert ist, können die Bedingungen des Readiness-Gates nicht erfüllt werden und das Rollout kann nicht fortgesetzt werden.

Wenn Sie kubectl ab Version 1.13 verwenden, können Sie den Status der Readiness-Gates eines Pods mit dem folgenden Befehl prüfen:

kubectl get pod POD_NAME -o wide

Prüfen Sie die Spalte READINESS GATES.

Diese Spalte ist in kubectl bis zu Version 1.12 nicht vorhanden. Ein Pod, für den der Status READY angegeben wird, weist möglicherweise ein fehlgeschlagenes Readiness-Gate auf. Verwenden Sie den folgenden Befehl, um dies zu prüfen:

kubectl get pod POD_NAME -o yaml

Die Readiness-Gates und der Status der einzelnen Gates werden in der Ausgabe aufgeführt.

Lösung

Prüfen Sie, ob das in der Pod-Spezifikation Ihres Deployments genannte Container-Image richtig funktioniert und auf Systemdiagnosen reagieren kann. Prüfen Sie, ob die Systemdiagnosen korrekt konfiguriert sind.

Fehler im eingeschränkten Modus

Symptome

Ab GKE-Version 1.29.2-gke.1643000 erhalten Sie möglicherweise die folgenden Warnungen für Ihren Dienst im Logs Explorer, wenn NEGs aktualisiert werden:

Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
Mögliche Ursachen

Diese Warnungen weisen darauf hin, dass GKE während einer NEG-Aktualisierung basierend auf EndpointSlice-Objekten Endpunktkonfigurationsfehler erkannt hat, was einen detaillierteren Berechnungsprozess namens „degraded mode“ (eingeschränkter Modus) auslöst. GKE aktualisiert NEGs weiterhin nach dem Best-Effort-Prinzip, indem entweder die Fehlkonfiguration korrigiert oder die ungültigen Endpunkte aus den NEG-Aktualisierungen ausgeschlossen werden.

Häufige Fehler:

  • endpoint has missing pod/nodeName field
  • endpoint corresponds to an non-existing pod/node
  • endpoint information for attach/detach operation is incorrect
Lösung

Diese Ereignisse werden in der Regel durch vorübergehende Zustände verursacht und werden von selbst behoben. Ereignisse, die durch Fehlkonfigurationen in benutzerdefinierten EndpointSlice-Objekten verursacht werden, bleiben jedoch ungelöst. Sehen Sie sich die EndpointSlice-Objekte an, die dem Dienst entsprechen, um die Fehlkonfiguration zu verstehen:

kubectl get endpointslice -l kubernetes.io/service-name=<service-name>

Prüfen Sie jeden Endpunkt anhand des Fehlers im Ereignis.

Um das Problem zu beheben, müssen Sie die EndpointSlice-Objekte manuell ändern. Das Update löst die Aktualisierung der NEGs erneut aus. Wenn die Fehlkonfiguration nicht mehr vorhanden ist, sieht die Ausgabe in etwa so aus:

NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode

Fehler bei der Verwendung von von Google verwalteten SSL-Zertifikaten

Dieser Abschnitt enthält Informationen zum Beheben von Problemen mit von Google verwalteten Zertifikaten.

Ereignisse zu ManagedCertificate- und Ingress-Ressourcen prüfen

Wenn Sie die Anzahl der zulässigen Zertifikate überschreiten, wird ein Ereignis mit dem Grund TooManyCertificates zum ManagedCertificate hinzugefügt. Mit dem folgenden Befehl können Sie die Ereignisse für ein ManagedCertificate-Objekt prüfen:

kubectl describe managedcertificate CERTIFICATE_NAME

Ersetzen Sie CERTIFICATE_NAME durch den Namen Ihres ManagedCertificate.

Wenn Sie ein nicht vorhandenes ManagedCertificate an eine Ingress-Ressource anhängen, wird der Ingress-Ressource ein Ereignis mit dem Grund MissingCertificate hinzugefügt. Sie können die Ereignisse für eine Ingress-Ressource mit dem folgenden Befehl prüfen:

kubectl describe ingress INGRESS_NAME

Ersetzen Sie INGRESS_NAME durch Ihren Ingress-Namen.

Verwaltetes Zertifikat wird nicht bereitgestellt, wenn die Domain in IP-Adressen mehrerer Load-Balancer aufgelöst wird

Wenn Ihre Domain in IP-Adressen mehrerer Load-Balancer (mehrere Ingress-Objekte) aufgelöst wird, sollten Sie ein einzelnes ManagedCertificate-Objekt erstellen und an alle Ingress-Objekte anhängen. Wenn Sie stattdessen viele ManagedCertificate-Objekte erstellen und jedes dieser Objekte an ein separates Ingress-Objekt anhängen, kann die Zertifizierungsstelle möglicherweise nicht die Inhaberschaft Ihrer Domain bestätigen und einige Ihrer Zertifikate werden möglicherweise nicht bereitgestellt. Damit die Bestätigung erfolgreich ist, muss das Zertifikat unter allen IP-Adressen sichtbar sein, in die Ihre Domain aufgelöst wird.

Wenn Ihre Domain in eine IPv4- und eine IPv6-Adresse aufgelöst wird, die mit verschiedenen Ingress-Objekten konfiguriert ist, sollten Sie ein einziges ManagedCertificate-Objekt erstellen und an beide Ingress-Objekte anhängen.

Unterbrechung der Kommunikation zwischen von Google verwalteten Zertifikaten und Ingress

Verwaltete Zertifikate kommunizieren über die Annotation ingress.gcp.kubernetes.io/pre-shared-cert mit dem Ingress-Objekt. Diese Kommunikation kann in folgenden Fällen unterbrochen werden:

  • Sie führen einen automatisierten Prozess aus, der die Annotation ingress.gcp.kubernetes.io/pre-shared-cert löscht.
  • Speichern Sie einen Ingress-Snapshot und löschen Sie ihn dann aus dem Snapshot und stellen Sie ihn wieder her. In der Zwischenzeit wurde möglicherweise eine in der Annotation ingress.gcp.kubernetes.io/pre-shared-cert aufgeführte SslCertificate-Ressource gelöscht. Ingress funktioniert nicht, wenn ein zugehöriges Zertifikat fehlt.

Wenn die Kommunikation zwischen von Google verwalteten Zertifikaten und Ingress unterbrochen wird, löschen Sie den Inhalt der Annotation ingress.gcp.kubernetes.io/pre-shared-cert und warten Sie, bis sich das System abgeglichen hat. Achten Sie darauf, dass die Annotation nicht versehentlich geändert oder gelöscht wird, um eine Wiederholung zu verhindern.

Validierungsfehler beim Erstellen eines von Google verwalteten Zertifikats

ManagedCertificate-Definitionen werden vor dem Erstellen des ManagedCertificate-Objekts validiert. Wenn die Validierung fehlschlägt, wird das ManagedCertificate-Objekt nicht erstellt und eine Fehlermeldung wird ausgegeben. Die verschiedenen Fehlermeldungen und Ursachen werden im Folgenden erläutert:

spec.domains in body should have at most 100 items

Ihr ManagedCertificate-Manifest enthält mehr als 100 Domains im Feld spec.domains. Von Google verwaltete Zertifikate unterstützen nur bis zu 100 Domains.

spec.domains in body should match '^(([a-zA-Z0-9]+|[a-zA-Z0-9][-a-zA-Z0-9]*[a-zA-Z0-9])\.)+[a-zA-Z][-a-zA-Z0-9]*[a-zA-Z0-9]\.?$'

Sie haben im Feld spec.domains einen ungültigen Domainnamen oder einen Domainnamen mit einem Platzhalter angegeben. Das ManagedCertificate-Objekt unterstützt keine Domains mit Platzhaltern (z. B. *.example.com).

spec.domains in body should be at most 63 chars long

Der angegebene Domainname ist zu lang. Von Google verwaltete Zertifikate unterstützen nur Domainnamen mit maximal 63 Zeichen.

Von Google verwaltetes Zertifikat manuell aktualisieren

Um das Zertifikat manuell zu aktualisieren, führen Sie die im Folgenden aufgeführten Schritte aus. Damit ist gewährleistet, dass das Zertifikat für die alte Domain weiterhin funktioniert, bis das Zertifikat für die neue Domain bereitgestellt wird.

  1. Erstellen Sie ein ManagedCertificate für die neue Domain.
  2. Fügen Sie den Namen des ManagedCertificate der Annotation networking.gke.io/managed-certificates im Ingress mithilfe einer durch Kommas getrennten Liste hinzu. Entfernen Sie nicht den alten Zertifikatsnamen.
  3. Warten Sie, bis das ManagedCertificate aktiv wird.
  4. Trennen Sie das alte Zertifikat vom Ingress-Objekt und löschen Sie es.

Wenn Sie ein ManagedCertificate erstellen, Google Cloud erstellt ein von Google verwaltetes SSL-Zertifikat. Sie können dieses Zertifikat nicht aktualisieren. Wenn Sie das ManagedCertificate aktualisieren,löscht Google Cloud das von Google verwaltete SSL-Zertifikat und erstellt es neu.

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

Nächste Schritte