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 Nutzung einer verworfenen Funktion oder API erkennt, werden automatische Upgrades pausiert, um zu verhindern, dass der Cluster in einen fehlerhaften Zustand versetzt wird. Upgrades auf die nächste Kubernetes-Nebenversion werden angehalten, aber GKE stellt Patchupgrades 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. Wenn Sie verhindern möchten, dass ein Cluster 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 das Ziel für das automatische Upgrade Ihres Clusters im Release-Kanal des Clusters ist und keine anderen Faktoren wie ein aktiver Wartungsausschluss ein Upgrade verhindern. Im Veröffentlichungszeitplan finden Sie ein geschätztes Datum, wann die Nebenversion zum Ziel für automatische Upgrades im Release-Kanal Ihres Clusters wird. Die Release-Hinweise enthalten die spezifische Ankündigung. Informationen zum Abrufen von Zielen für automatische Upgrades für einen bestimmten Cluster finden Sie unter Informationen zu Upgrades eines Clusters abrufen (Vorabversion).
Wenn GKE weiterhin die Nutzung des verworfenen Features auf dem Cluster erkennt, behält GKE den Cluster auf seiner aktuellen Nebenversion bis zum Enddatum des Supports bei.
Die Termine für das Ende des Supports von Nebenversionen finden Sie im Release-Zeitplan. Da das Ende des Supports für eine Nebenversion von der Registrierung für den Release-Channel abhängt, müssen Sie sich auf das richtige Datum beziehen, das dem Release-Channel Ihres Clusters entspricht:
- Release-Channels, die nicht „Extended“ sind: Wenn Ihr Cluster für die Release-Versionen „Rapid“, „Regular“ oder „Stable“ registriert ist oder nicht für eine Release-Version registriert ist, ist dieses Datum das Ende des Standardsupports für die Nebenversion.
- Extended Channel: Wenn Ihr Cluster für den Extended Channel registriert ist, führt GKE erst nach Ablauf des erweiterten Supports ein automatisches Upgrade Ihres Clusters von der Nebenversion durch.
Sobald dieses Datum 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 unter Automatische Upgrades am Ende der Supportzeit.
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 Ende des Supports 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 ausführen, wenn Sie bestätigt haben, dass das Upgrade keine Unterbrechung der Clusterumgebung verursacht. Sie können dies testen, indem Sie zuerst einen Testcluster erstellen und prüfen, ob das Upgrade zu Unterbrechungen führt. Andernfalls 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 Einstellungsvorgängen. Bisher enthaltene Informationen zu Funktionen oder APIs, die mit Versionen eingestellt wurden, deren Enddatum für den Support bereits deutlich überschritten ist, wurden entfernt.
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? |
|---|---|---|---|---|
| Linux-cgroupv1-Modus | GKE-Version 1.31 | Noch offen | Knoten zu Linux cgroupv2 migrieren | Nein |
| Scannen auf Sicherheitslücken aus der GKE Standard Edition entfernen | 23. Juli 2024 | 31. Juli 2024 | Scannen auf Sicherheitslücken aus der GKE Standard Edition entfernen | Nein |
| 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 aus 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 |