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. Kubernetes-Einstellungsrichtlinie: Ein eingestelltes Feature oder eine eingestellte API, 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 erkennt, dass ein verworfenes Feature oder eine verworfene API verwendet wird, pausiert GKE die automatischen Upgrades, um zu verhindern, dass der Cluster in einen fehlerhaften Zustand aktualisiert 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. Damit ein Cluster nicht aktualisiert wird, müssen Sie Wartungsausschlüsse verwenden.
Wann setzt GKE automatische Upgrades fort?
Wenn GKE 30 Tage lang keine Nutzung der verworfenen Funktion oder Aufrufe an verworfene APIs festgestellt hat, wird der Cluster automatisch aktualisiert, wenn die nächste Nebenversion das Ziel für automatische Upgrades Ihres Clusters in der Release-Version des Clusters ist und Ihr Cluster keine anderen Faktoren hat, die Upgrades verhindern, z. B. einen aktiven Wartungsausschluss. Wenn Sie wissen möchten, wann eine Nebenversion in der Release-Version Ihres Clusters zu einem Ziel für automatische Upgrades wird, können Sie dem Veröffentlichungszeitplan ein geschätztes Datum und den Versionshinweisen die spezifische Ankündigung entnehmen. Informationen zum Abrufen automatischer Upgradeziele für einen bestimmten Cluster finden Sie unter Informationen zu Upgrades eines Clusters abrufen.
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, an denen Nebenversionen nicht mehr unterstützt werden, finden Sie im Releasezeitplan. Da das Enddatum der Unterstützung für eine Nebenversion von der Registrierung der Release-Version abhängt, achten Sie darauf, dass Sie das korrekte Datum verwenden, das der Release-Version 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 ist, wird der Cluster automatisch auf die nächste Nebenversion aktualisiert und die Clusterumgebung kann beeinträchtigt sein, da das entfernte Feature noch verwendet wird. Weitere Informationen finden Sie unter Automatische Upgrades am Ende des Supports.
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 Ihres Clusters durchführen, wenn Sie sich vergewissert haben, dass das Upgrade keine Unterbrechung Ihrer Clusterumgebung verursacht. Dazu erstellen Sie zuerst einen Testcluster und prüfen, ob das Upgrade zu Unterbrechungen führt. 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 Einstellungen. Zuvor enthaltene Informationen zu Funktionen oder APIs, die mit Versionen verworfen wurden, deren Unterstützung bereits deutlich verstrichen ist, werden nicht berücksichtigt.
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? |
|---|---|---|---|---|
| Container Registry | 15. Mai 2023 | 18. März 2025 | Von Container Registry auf Artifact Registry in GKE umstellen | Nein |
| GKE-Compliance-Dashboard (Vorschau) | 28. Januar 2025 | 30. Juni 2025 | Einstellung von Funktionen für die Statusverwaltung | Nein |
|
Scannen von Arbeitslasten auf Sicherheitslücken Dashboard für den GKE-Sicherheitsstatus |
GKE Standard Edition: 23. Juli 2024 | GKE Standard Edition: 31. Juli 2025 | Entfernung des Scannens auf Sicherheitslücken aus der GKE Standard Edition | Ja |
|
Bedenken hinsichtlich der Lieferkette – Binärautorisierung (Vorabversion) Dashboard für den GKE-Sicherheitsstatus |
28. Januar 2025 | 31. März 2025 | Einstellung von Funktionen für die Statusverwaltung | Nein |
|
Kubernetes-Sicherheitsstatus – Erweiterte Stufe (Vorschau) Dashboard für den GKE-Sicherheitsstatus |
28. Januar 2025 | 31. März 2025 | Einstellung von Funktionen für die Statusverwaltung | Ja |
| Funktionen von containerd 1.7 | GKE-Version 1.32 | GKE-Version 1.33 | Knoten zu containerd 2 migrieren | Ja |
| Linux-cgroupv1-Modus | GKE-Version 1.31 | Noch offen | Knoten zu Linux cgroupv2 migrieren | Nein |
| Entfernung des Scannens auf Sicherheitslücken aus der GKE Standard Edition | 23. Juli 2024 | 31. Juli 2024 | Entfernung des Scannens auf Sicherheitslücken aus der GKE Standard Edition | Nein |
| Mit 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 wurden 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 |
| Saxml für die Bereitstellung mit mehreren Hosts auf TPUs und GKE | – | 24. April 2025 | Versionshinweise | Nein |