Einstellung von GKE


Auf dieser Seite wird erklärt, wie sich Funktions- und API-Verwerfungen, die durch Kubernetes und andere Abhängigkeiten verursacht werden, auf die Google Kubernetes Engine (GKE) auswirken. Diese Seite enthält auch Tabellen mit Informationen zu bestimmten Upstream-Verwerfungen. Informationen zum Umgang mit bevorstehenden Verwerfungen finden Sie unter Statistiken und Empfehlungen zur Einstellung ansehen.

Was sind Kubernetes-Einstellungen?

GKE-Cluster basieren auf dem Open-Source-Clusterverwaltungssystem Kubernetes, Die Funktionen von Kubernetes werden im Laufe der Zeit weiterentwickelt. Während neue Funktionen im Laufe der Zeit eingeführt werden, kann es sein, dass ein Feature entfernt werden muss. Ein Feature kann auch von der Beta-Phase in die GA-Phase übergehen. Die Richtlinie zur Einstellung von Kubernetes sorgt dafür, dass Nutzer einen vorhersehbaren Prozess haben, damit sie von einer verworfenen Funktion oder API migrieren können, bevor sie entfernt wird.

Wenn ein Feature oder eine API nach dem Einstellungszeitraum entfernt wurde, können Sie sie nicht mehr mit der entsprechenden GKE-Nebenversion verwenden. Wenn ein Cluster von einer verworfenen Funktion oder API abhängig war, ist die Funktionalität möglicherweise eingeschränkt.

Verwerfungen, die durch andere vorgelagerte Abhängigkeiten verursacht werden

Neben Kubernetes-Features und -APIs bietet GKE auch Features, die von anderen Anbietern unterstützt werden, z. B. von Microsoft unterstützte Windows-Knoten-Images und von Canonical unterstützte Ubuntu-Knoten-Images. Wenn diese vorgelagerten Anbieter die Unterstützung für ein Feature verwerfen oder beenden, muss GKE möglicherweise das entsprechende Feature entfernen. Die Tabellen auf dieser Seite enthalten auch Informationen zu bevorstehenden Einstellungen und Entfernungen, die durch vorgelagerte Abhängigkeiten außerhalb von Kubernetes verursacht werden.

Funktionsweise von Einstellungen von Kubernetes mit GKE

Das Ausführen von Anwendungen in GKE erfordert eine gemeinsame Verantwortung zwischen Ihnen und GKE.

Als Nutzer müssen Sie die Gefährdung durch verworfene Features und APIs bewerten und minimieren, die in künftigen Kubernetes-Nebenversionen entfernt werden. In den nächsten Abschnitten erfahren Sie, wie GKE diesen Prozess vereinfacht, indem Sie die Verwendung verworfener Kubernetes-Features und APIs erkennen, Informationen zu dieser Nutzung freigeben und Empfehlungen zur Migration zu Features und APIs geben, die mit geplanten Nebenversionen kompatibel sind.

Wenn GKE erkennt, dass ein Cluster eine Funktion verwendet, die in einer künftigen Nebenversion von Kubernetes entfernt wird, werden die automatischen Clusterupgrades auf die nächste Nebenversion pausiert und GKE gibt einen verworfenen Leitfaden sowie Empfehlungen weiter.

Was passiert, wenn GKE automatische Upgrades pausiert?

Wenn GKE die Verwendung eines verworfenen Features oder einer API erkennt, pausiert GKE automatische Upgrades, um zu verhindern, dass der Cluster in einen fehlerhaften Zustand versetzt wird. Upgrades auf die nächste Kubernetes-Nebenversion werden angehalten, aber GKE stellt Cluster-Upgrades auf dem Cluster der aktuellen Nebenversion bereit. Wenn sich ein Cluster beispielsweise in Version 1.21.11-gke.1100 befindet und verworfene APIs aufruft, die aus Version 1.22 entfernt wurden, pausiert GKE das automatische Upgrade auf Version 1.22. GKE pausiert das automatische Upgrade jedoch nicht auf eine neue Patchversion, 1.21.11-gke.1900.

Da GKE nicht garantieren kann, dass jede Nutzung erkannt wird, kann GKE nicht garantieren, dass Upgrades immer angehalten werden, wenn eine eingestellte Funktion oder API verwendet wird. Damit ein Cluster nicht aktualisiert wird, müssen Sie Wartungsausschlüsse verwenden.

Wann setzt GKE automatische Upgrades fort?

Sobald GKE die Verwendung des verworfenen Features oder die Aufrufe von verworfenen APIs 30 Tage lang nicht erkannt hat, wird der Cluster automatisch aktualisiert, wenn die nächste Nebenversion die Standardversion in der Release-Version des Clusters ist. Im Veröffentlichungszeitplan können Sie sehen, wann die Nebenversion standardmäßig zur Release-Version Ihres Clusters wird.

Wenn GKE weiterhin die Nutzung des verworfenen Features auf dem Cluster erkennt, behält GKE den Cluster auf seiner aktuellen Nebenversion bis zum Datum des Lebenszyklus der Version bei. Sobald dieses Datum, das im Releasezeitplan verfügbar ist, erreicht wird, wird der Cluster automatisch auf die nächste Nebenversion aktualisiert und die Clusterumgebung kann durch das entfernte Feature eingeschränkt sein, das entfernte Feature noch verwendet wird. Weitere Informationen finden Sie in den FAQ zum Versionssupport.

Was sind Informationen und Empfehlungen zu veralteten Versionen?

Wenn GKE erkennt, dass ein Cluster ein Feature verwendet, das in einer künftigen Nebenversion von Kubernetes entfernt wird, gibt GKE eine verworfene Einstellung und eine Empfehlung zurück, die Sie darüber informiert, dass Ihr Cluster ein verworfenes Feature verwendet. Diese Statistik enthält Informationen zur letzten erkannten Nutzung und je nach Art der Verwerfung weitere Details. Weitere Informationen zur Anzeige dieser Informationen finden Sie unter Statistiken und Empfehlungen zur Einstellung ansehen.

Geeignete Kubernetes-Einstellungen bewerten und minimieren

GKE bietet Migrationsleitfäden, die Ihnen zeigen, wie Sie von verworfenen Features und APIs zu jenen migrieren, die mit der neuen Nebenversion kompatibel sind. Eine Liste der Einstellungshinweise und die zugehörigen Migrationsleitfäden finden Sie unter Informationen zu verworfenen Kubernetes-Ressourcen.

Während GKE Informationen zu erkannten Clustern bereitstellt, werden diese zwar verworfen, aber es wird nicht garantiert, dass alle bevorstehenden Unterbrechungen erkannt werden. Wenn beispielsweise ein verworfenes Feature in den letzten 30 Tagen nicht verwendet wurde, erkennt GKE keine Nutzung und es werden keine Statistiken und Empfehlungen generiert.

Sie müssen die Gefährdung Ihrer Clusterumgebung bevorgehenden Verwerfungen unabhängig bewerten, bevor Sie Ihren Cluster auf die nächste Nebenversion aktualisieren. Sie können den Upgradeprozess durch Auswahl einerRelease-Version mithilfe vonWartungsfenster und Ausschlüsse oder Manuelles Upgrade Ihrer Cluster kontrollieren, wenn Sie festgestellt haben, dass die Version nicht mit Verwerfungen für die nächste Nebenversion verbunden ist.

Probleme mit Kubernetes-Einstellungen beheben

Sie können Maßnahmen ergreifen, indem Sie die nächsten Verwerfungen prüfen. Lesen Sie Statistiken und Empfehlungen zur Einstellung ansehen, um zu beurteilen, ob Ihr Cluster verfügbar gemacht wird, und verwenden Sie Migrationsleitfäden, um das Probleme zu beheben, bevor die letzte verfügbare Nebenversion, die das Feature unterstützt, das End of Life erreicht.

Nachdem Sie Änderungen vorgenommen haben, um die Verwendung verworfener APIs oder Funktionen in Ihrem Cluster zu beenden, wartet GKE, bis die Verwendung verworfener APIs oder Funktionen 30 Tage lang nicht mehr festgestellt wurde. Anschließend wird die Blockierung von automatischen Upgrades aufgehoben. Automatische Upgrades werden gemäß dem Veröffentlichungszeitplan fortgesetzt.

Sie können auch ein manuelles Upgrade des Clusters durchführen, wenn Sie bestätigt haben, dass das Upgrade keine Unterbrechung Ihrer Clusterumgebung verursacht. Erstellen Sie dazu zuerst einen Testcluster und prüfen Sie, ob das Upgrade Störungen verursacht. Ist dies nicht der Fall, können Sie den Cluster manuell aktualisieren.

Wenn Sie eine Empfehlung verwerfen, wird sie lediglich für alle Nutzer ausgeblendet. Automatische Upgrades bleiben pausiert, bis Sie die verworfenen Features migrieren und GKE 30 aufeinanderfolgende Tage lang keine Verwendung der verworfenen Features erkennt.

Informationen zu verworfenen Kubernetes-Ressourcen

Die folgenden Abschnitte enthalten Informationen zu laufenden Einstellungsvorgängen, einschließlich Leitfäden zur Migration zu Features oder APIs, die mit verfügbaren Kubernetes-Nebenversionen kompatibel sind. In diesen Tabellen können Sie prüfen, ob GKE die Nutzung mit Statistiken und Empfehlungen erkennt und meldet.

Diese Tabellen enthalten nur Informationen zu laufenden Verwerfungen und lassen die zuvor aufgeführten Informationen zu Features oder APIs weg, die mit Versionen verworfen wurden, die ihr Ende ihres Lebenszyklus erheblich überschritten haben.

Verworfene Kubernetes-Features

In der folgenden Tabelle werden die aktuell verworfenen GKE-Features sowie die Version beschrieben, in der diese Features nicht mehr unterstützt werden:

Name Verworfen Entfernt Weitere Informationen Wird die Nutzung von GKE erkannt und gemeldet?
Mit dem SHA-1-Algorithmus signierte TLS-Zertifikate GKE-Version 1.24 GKE-Version 1.29 Entfernen der Unterstützung für das SHA-1-TLS-Zertifikat Ja
Integriertes Authentifizierungs-Plug-in für Kubernetes-Clients GKE-Version 1.22 GKE-Version 1.25 Verworfenes Authentifizierungs-Plug-in für Kubernetes-Clients Nein
PodSecurityPolicy GKE-Version 1.21 GKE-Version 1.25 Einstellung von PodSecurityPolicy Ja
Docker-basierte Knoten-Images GKE-Version 1.20 GKE-Version 1.24 Einstellung von Docker-Knoten-Images Ja
X.509 Feld „Allgemeiner Name“ in Webhook-Zertifikaten GKE-Version 1.19 GKE-Version 1.23 Einstellung von Allgemeiner-Name-Feldern in Webhook-Zertifikaten Ja

Einstellung von Kubernetes API

Die folgende Tabelle bietet einen Überblick über Kubernetes APIs, die verworfen wurden und nicht mehr bereitgestellt werden, sortiert nach Kubernetes-Version:

Kubernetes-Version Weitere Informationen Wird die Nutzung von GKE erkannt und gemeldet?
1,29 Verworfene Kubernetes 1.29 APIs Ja
1,27 Verworfene Kubernetes 1.27 APIs Ja
1.26 Verworfene Kubernetes 1.16 APIs Ja
1,25 Verworfene Kubernetes 1.25 APIs Ja
1.22 Verworfene Kubernetes 1.22 APIs,
Kubernetes Ingress Beta APIs in GKE 1.23 entfernt
Ja

Andere eingestellte Features

In der folgenden Tabelle finden Sie Informationen zu Verwerfungen und Entfernungen, die von anderen vorgelagerten Anbietern verursacht werden, die nicht Teil des Open-Source-Projekts von Kubernetes sind.

Name Verworfen Entfernt Weitere Informationen Wird die Nutzung von GKE erkannt und gemeldet?
Windows Server – Semi-Annual Channel (SAC)-Knoten-Images 9. August 2022 Ende der Wartung von Windows Server SAC Nein

Nächste Schritte