Auf dieser Seite wird erläutert, wie Sie und Google Kubernetes Engine (GKE) Änderungen während des Lebenszyklus eines Clusters verwalten, um die Leistung und Verfügbarkeit zu maximieren und gleichzeitig Arbeitslastunterbrechungen zu minimieren.
Diese Seite richtet sich an Plattformadministratoren, die ihre Clusterumgebung planen und optimieren möchten, um Unterbrechungen für ihre Arbeitslasten zu minimieren. Sie können diese Seite entweder vor oder nach dem Erlernen der grundlegenden Clusterverwaltungsaufgaben lesen, die unter Cluster verwalten und Übersicht über die Clusterverwaltung beschrieben werden.
Eine verwaltete Plattform und gemeinsame Verantwortung
GKE ist eine von Google verwaltete Implementierung der Open-Source-Plattform zur Containerorchestrierung Kubernetes. Wie unter Funktionsweise von GKE beschrieben, besteht ein GKE-Cluster aus einer Steuerungsebene, die Verwaltungsknoten mit Systemkomponenten enthält, und Worker-Knoten, auf denen Sie Arbeitslasten bereitstellen.
Die Erstellung einer optimalen Clusterumgebung für die Ausführung Ihrer Arbeitslasten mit maximaler Leistung, Verfügbarkeit und minimalen Unterbrechungen ist eine gemeinsame Verantwortung:
- Die GKE ist dafür verantwortlich, eine zuverlässige, verfügbare, sichere und leistungsstarke Clusterumgebung aufrechtzuerhalten. Dazu verwaltet die GKE die Steuerungsebene, die Systemkomponenten und im Autopilot-Modus die Worker-Knoten.
- Als Plattformadministrator sind Sie dafür verantwortlich, Ihren Cluster zu konfigurieren und Ihre Arbeitslasten zu verwalten, einschließlich der Vorbereitung auf Unterbrechungen. Im Standardmodus erstellen und verwalten Sie auch die Worker-Knoten, die in Knotenpools gruppiert sind.
Weitere Informationen finden Sie unter Gemeinsame Verantwortung für GKE.
Wie GKE Änderungen während des Lebenszyklus eines Clusters verwaltet
Als Kubernetes-Implementierung ist ein GKE-Cluster ein Netzwerk aus Prozessen und Systemen, die zusammenarbeiten, um die optimale Umgebung für die Ausführung Ihrer Arbeitslasten aufrechtzuerhalten. Zur Verwaltung des Clusters führt GKE Wartungsaufgaben aus, nimmt Änderungen vor, initiiert Vorgänge, aktualisiert Komponenten und führt Upgrades der Version der Steuerungsebene und der Knoten durch.
Der Großteil des täglichen Betriebs Ihrer Anwendung erfolgt im Hintergrund, sodass Ihre Arbeitslasten ohne Unterbrechung ausgeführt werden. Einige kritische Änderungen müssen jedoch so vorgenommen werden, dass Ihre Arbeitslasten vorübergehend unterbrochen werden, wie im nächsten Abschnitt beschrieben.
Einige Clusteränderungen können zu Unterbrechungen von Arbeitslasten führen
GKE ist bestrebt, Ihre Arbeitslasten nahtlos auszuführen. Bei einigen wichtigen Arten von Änderungen kann es jedoch zu vorübergehenden Unterbrechungen Ihrer Arbeitslasten kommen. Dies betrifft vor allem Änderungen, bei denen die Knoten, auf denen Ihre Arbeitslasten ausgeführt werden, neu gestartet werden. Mit GKE- und Kubernetes-Funktionen können Sie festlegen, wann und wie Unterbrechungen auftreten sollen, damit Ihre Arbeitslasten die Änderungen ordnungsgemäß verarbeiten können.
In den folgenden Abschnitten wird erläutert, welche Arten von Änderungen die GKE an Clustern vornimmt, welche Art von Unterbrechung sie verursachen und wie Sie sich darauf vorbereiten können.
Upgrades und Updates mit der Verwaltung des GKE-Clusterlebenszyklus
In GKE haben Cluster-Upgrades und Cluster-Updates ähnliche Bedeutungen.
In GKE bezieht sich der Begriff Clusterupgrades oder einfach Upgrades auf die Aktualisierung der Kubernetes-Version der Steuerungsebene (Upgrades der Steuerungsebene) oder der Knoten (Knotenupgrades) oder beides. Bei Standardclustern können Knotenupgrades auch als Knotenpool-Upgrades bezeichnet werden, da GKE einen einzelnen Vorgang zum Upgrade eines Knotenpools verwendet.
Der Begriff Clusterupdates oder einfach Updates ist ein allgemeinerer Begriff, der sich auf alle Arten von Änderungen an der Steuerungsebene oder an Knoten bezieht, einschließlich der Aktualisierung ihrer Versionen. Die GKE verwaltet Ihre Clusterumgebung aktiv, indem sie Upgrades, andere Arten von Updates und erforderliche Wartungsvorgänge durchführt. Diese Aktionen sorgen dafür, dass Ihr Cluster leistungsstark, sicher und auf dem neuesten Stand mit den neuesten Funktionen und Fehlerkorrekturen bleibt. In GKE werden Tools wie Strategien für Knotenupgrades und Wartungsrichtlinien verwendet, um Unterbrechungen während dieser Prozesse zu minimieren.
Unterbrechungen bei Knotenupdates einplanen
Bestimmte Arten von Clusteränderungen, hauptsächlich Änderungen an Knoten, können zu Unterbrechungen führen.
GKE verwendet Knoten-Upgradestrategien, um Knoten – sowohl Autopilot-Knoten als auch Standard-Clusterknotenpools – so zu aktualisieren, dass sie für die Anforderungen Ihrer Arbeitslast optimiert sind. Diese Strategien gelten für Versionsupgrades und auch für einige andere Arten von Knotenänderungen. Mit diesen Strategien kann GKE Unterbrechungen bei Knotenupdates minimieren, die für die Funktionsfähigkeit und Leistung von Clustern wichtig sind.
Mit Wartungsfenstern und -ausschlüssen können Sie festlegen, wann bestimmte Clusterwartungen durchgeführt werden und wann nicht. Für Standard-Cluster können Sie eine Knoten-Upgradestrategie auswählen, die am besten zu Ihrem Arbeitslastprofil und Ihren Ressourcenbeschränkungen passt.
Sowohl bei manuellen als auch bei automatisch initiierten Änderungen an Knoten nimmt GKE Änderungen mit den folgenden allgemeinen Merkmalen vor:
Änderungen berücksichtigen in der Regel Wartungsrichtlinien: Wenn GKE Änderungen an den Knoten vornimmt, werden diese Änderungen im Allgemeinen von GKE-Wartungsrichtlinien berücksichtigt. Zu den Ausnahmen gehört die Hostwartung für bestimmte Knotentypen, z. B. Knoten mit GPUs und TPUs.
Beachten Sie Folgendes, wenn Sie manuelle Änderungen initiieren, die die Neuerstellung aller Knoten in einem Knotenpool erfordern:
- Bei einigen Änderungen berücksichtigt GKE die Wartungsrichtlinien und wendet die von Ihnen eingereichte Änderung erst an, wenn eine Wartung möglich ist. Wenn GKE auf die Verfügbarkeit von Wartungsarbeiten wartet und die Änderung dringend ist, können Sie die Änderungen manuell anwenden, um die neue Konfiguration sofort zu übernehmen.
- Bei anderen manuellen Änderungen, einschließlich manueller Upgrades, berücksichtigt GKE keine Wartungsrichtlinien. Achten Sie bei diesen manuellen Änderungen darauf, dass Ihre Arbeitslasten auf sofortige Unterbrechungen vorbereitet sind.
Änderungen verwenden im Allgemeinen Knotenupgrade-Strategien: Wenn die GKE die meisten automatischen oder manuell initiierten Änderungen auf Knoten anwendet, einschließlich Knotenupdates, die keine Versionsupgrades sind, wählt die GKE eine Knotenupgrade-Strategie aus: Surge-Upgrades, Blau/Grün-Upgrades oder automatisch skalierte Blau/Grün-Upgrades (Vorabversion). Autopilot verwendet immer Surge-Upgrades. Bei Änderungen an Standard-Clusterknotenpools werden in der Regel Surge-Upgrades verwendet, es sei denn, Sie haben Blau/Grün-Upgrades oder automatisch skalierte Blau/Grün-Upgrades konfiguriert und nehmen bestimmte Arten von Änderungen vor. Weitere Informationen dazu, welche Strategie für einen Knotenpool konfiguriert ist, finden Sie unter Upgrade-Einstellungen eines Knotenpools prüfen.
Änderungen erfordern ausreichende Ressourcen: Wenn GKE eine Änderung mithilfe einer Knotenupgrade-Strategie anwendet, erfordert diese Änderung je nach Strategie und Konfiguration eine bestimmte Menge an Ressourcen. Das Projekt Ihres Clusters muss über ein ausreichendes Ressourcenkontingent, eine ausreichende Ressourcenverfügbarkeit und eine ausreichende Reservierungskapazität (für Knotenpools mit spezifischer Reservierungsaffinität) verfügen. Weitere Informationen finden Sie unter Ressourcen für Knotenupgrades gewährleisten.
Eine detaillierte Liste der spezifischen Änderungen und ihrer Merkmale finden Sie auf dieser Seite unter Arten von Änderungen an einem GKE-Cluster.
Arbeitslastverfügbarkeit durch Vorbereitung auf störende Änderungen maximieren
Um die Verfügbarkeit Ihrer Arbeitslasten in einem GKE-Cluster zu maximieren, empfehlen wir die in den folgenden Abschnitten beschriebenen Maßnahmen:
Clusterverfügbarkeit auswählen
Wenn die Verfügbarkeit der Steuerungsebene Priorität hat, wählen Sie einen Autopilot-Cluster oder einen regionalen Standardcluster anstelle eines zonalen Standardclusters aus. Weitere Informationen finden Sie unter Cluster-Konfigurationsoptionen.
Upgrades mit GKE-Tools steuern
Mit den folgenden Tools können Sie steuern, wann und wie GKE Ihren Cluster aktualisiert. So können Sie die Best Practices implementieren:
- Release-Versionen: Wählen Sie eine Release-Version aus, um Clusterversionen mit dem von Ihnen gewünschten Verhältnis zwischen Featureverfügbarkeit und Stabilität zu erhalten.
- Wartungsfenster: Geben Sie ein wiederkehrendes Zeitfenster an, in dem bestimmte Arten von GKE-Clusterwartungen wie Upgrades durchgeführt werden können.
- Wartungsausschlüsse: Verhindern, dass Clusterwartungen für einen bestimmten Zeitraum durchgeführt werden.
- Budgets für Clusterunterbrechungen: Passen Sie das Mindestzeitintervall zwischen bestimmten Arten von Clusterupgrades an, einschließlich Patch- oder Nebenversionsupgrades.
- Strategien für Knotenupgrades: Wenn Sie einen Standardknotenpool verwenden, wählen Sie aus, wie Ihre Knoten aktualisiert werden sollen (Surge-, Blau/Grün- oder automatisch skalierte Blau/Grün-Upgrades (Vorabversion)), um Unterbrechungen Ihrer Arbeitslasten zu minimieren. Außerdem können Sie festlegen, wie viele Knotenpools GKE automatisch gleichzeitig in einem Cluster aktualisiert.
- Roll-out-Sequenzierung: Qualifizieren Sie Upgrades in einer Vorproduktionsumgebung, bevor GKE Ihre Produktionscluster aktualisiert.
- Manuelle Upgrades: Führen Sie ein manuelles Upgrade Ihres Clusters durch und führen Sie Aktionen wie das Abbrechen, Fortsetzen, Rollback und Abschließen automatischer oder manueller Upgrades aus.
Cluster verwalten und überwachen
Führen Sie die folgenden Aufgaben kontinuierlich aus, um potenzielle Unterbrechungen Ihrer Cluster zu verwalten:
- Cluster mit der Beobachtbarkeitssuite von GKE überwachen
- Ankündigungen finden Sie in den GKE-Versionshinweisen.
- Clusterbenachrichtigungen ansehen, z. B. wenn Upgrades gestartet oder abgeschlossen werden, wenn neue Versionen verfügbar sind, Sicherheitsbulletins und Daten zum Ende des Supports.
- Informationen zu Clusterupgrades abrufen, um den Status von Upgrades für Ihre Cluster zu verstehen.
- Im GKE-Releasezeitplan finden Sie eine Schätzung, wann Nebenversionen für Upgrades verfügbar sind und wann sie das Ende des Supports erreichen.
- Nutzen Sie die verbindlichen Anleitungen, die potenzielle Optimierungsmöglichkeiten aufzeigen und erklären, wie Sie Ihre Clusternutzung optimieren können, einschließlich Anleitungen für veraltete Features und APIs.
Arbeitslasten vorbereiten
So können Sie Unterbrechungen minimieren, indem Sie Ihre Arbeitslasten so widerstandsfähig wie möglich machen:
- Führen Sie Replikate Ihrer Arbeitslasten aus, um Redundanz zu gewährleisten und einen Single Point of Failure zu vermeiden.
- Geben Sie ein Budget für Pod-Störungen für Ihre Anwendung an, indem Sie ein Budget für Pod-Störungen verwenden.
- Legen Sie einen Kulanzzeitraum für die Beendigung fest, der für Ihre Arbeitslast lang genug ist, um ordnungsgemäß beendet zu werden.
- Wenn Ihre Arbeitslast GPUs oder TPUs verwendet, folgen Sie der Anleitung zum Verwalten von GKE-Knotenunterbrechungen für GPUs und TPUs.
- Für zustandsorientierte Anwendungen, die häufig Zeit benötigen, um E/A ordnungsgemäß zu beenden und die Speicherverbindung zu trennen, folgen Sie der Anleitung unter Zustandsorientierte Arbeitslasten auf Unterbrechungen vorbereiten.
Allgemeine Informationen zu diesen Themen finden Sie im Abschnitt Unterbrechungen verwalten des Blogposts Best Practices für GKE: Tag 2: Vorgänge für die Geschäftskontinuität.
Arten von Änderungen an einem GKE-Cluster
In den folgenden Tabellen sind die häufigsten Arten von größeren Änderungen an einem Cluster aufgeführt, einschließlich der Merkmale dieser Änderungen wie Häufigkeit und Grad der Unterbrechung.
Arten von Upgrades
In der folgenden Tabelle finden Sie Informationen dazu, wie Upgrades eine Clusterumgebung beeinträchtigen können.
| Ändern | Automatisch oder manuell initiiert | Berücksichtigt Wartungsrichtlinien | Häufigkeit | Art der Störung | Ausmaß der Störung |
|---|---|---|---|---|---|
| Upgrade der Steuerungsebene | Automatisch oder manuell |
Automatische Upgrades berücksichtigen die Wartungsrichtlinien bis zum Ende des Supports, mit Ausnahme von extrem seltenen Notfallkorrekturen, falls erforderlich. Manuelle Upgrades werden nicht durch Wartungsrichtlinien blockiert. |
Patch-Upgrades, je nach Release-Version bis zu einmal pro Woche. Kleinere Upgrades etwa alle vier Monate. Bei Clustern im Extended Channel werden Nebenversionsupgrades nur durchgeführt, wenn die Nebenversion das Ende des Supports erreicht. |
Steuerungsebene |
Bei Autopilot- und regionalen Standardclustern bleibt die Steuerungsebene verfügbar. Bei zonalen Standardclustern können Sie mehrere Minuten lang nicht mit der Steuerungsebene kommunizieren. Das bedeutet, dass Sie den Cluster, die Knoten und die Arbeitslasten während dieser Zeit nicht konfigurieren können. |
| Knotenupgrade | Automatisch oder manuell |
Automatische Upgrades berücksichtigen die Wartungsrichtlinien bis zum Ende des Supports, mit Ausnahme von extrem seltenen Notfallkorrekturen, falls erforderlich. Manuelle Upgrades werden nicht durch Wartungsrichtlinien blockiert. |
In der Regel dieselben wie die Upgrades der Steuerungsebene. Wenn Ihr Cluster nicht für eine Release-Version registriert ist und Sie automatische Knotenupgrades deaktivieren, müssen Sie die Knotenpools Ihres Clusters manuell aktualisieren. |
Alle Knoten für Autopilot-Cluster oder einen oder mehrere Standardcluster-Knotenpools. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet Surge-Upgrades für Autopilot oder die konfigurierte Knoten-Upgradestrategie (Surge, Blau/Grün oder automatisch skaliertes Blau/Grün (Vorabversion)) für Standardcluster. |
Manuelle Änderungen, bei denen die Knoten mithilfe einer Knotenupgradestrategie und unter Berücksichtigung von Wartungsrichtlinien neu erstellt werden
In der folgenden Tabelle wird beschrieben, wie diese manuellen Änderungen eine Clusterumgebung beeinträchtigen können. Diese Liste enthält unter anderem manuelle Änderungen, die GKE-Wartungsrichtlinien berücksichtigen.
| Ändern | Automatisch oder manuell initiiert | Berücksichtigt Wartungsrichtlinien | Häufigkeit | Art der Störung | Ausmaß der Störung |
|---|---|---|---|---|---|
| Schreibgeschützten Port für Kubelet deaktivieren | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs. | Alle Knoten in einem Autopilot-Cluster Alle Knoten in einem Standard-Clusterknotenpool. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet sofort Surge-Upgrades, um die Knoten neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Clusteranmeldedaten rotieren | Automatisch, wenn die Cluster-Anmeldedaten innerhalb von 30 Tagen ablaufen. Kann auch manuell initiiert werden. | Berücksichtigt Wartungsrichtlinien. GKE kann jedoch Wartungsrichtlinien innerhalb von 30 Tagen nach Ablauf der Anmeldedaten außer Kraft setzen. Innerhalb von 30 Tagen ignoriert GKE die Wartungsverfügbarkeit für den ersten Schritt, d. h. das Starten der Rotation. Wenn Sie nach dem ersten Schritt bestimmte Vorgänge manuell auslösen, werden die Wartungsrichtlinien für diese Vorgänge nicht berücksichtigt. | Einmal pro manueller Änderung dieses Typs oder abhängig von der Lebensdauer der Cluster-Anmeldedaten für die automatische Initiierung. Sie können Vorgänge für bestimmte Schritte im Rotationsprozess manuell aufrufen. | Bei einigen Schritten die Steuerungsebene. Für andere Schritte alle Knoten für Autopilot-Cluster, alle Knoten in jedem Standard-Knotenpool. |
Wenn Sie die Rotation initiieren und die Rotation abschließen, ist der Grad der Unterbrechung folgender:
Wenn die Knoten neu erstellt werden, ist der Grad der Unterbrechung so:
|
| IP-Adresse der Steuerungsebene rotieren | Manuell initiiert | Wartungsrichtlinien werden berücksichtigt. Wenn Sie jedoch nach dem ersten Schritt manuell bestimmte Vorgänge auslösen, werden die Wartungsrichtlinien für diese Vorgänge nicht berücksichtigt. | Einmal pro manueller Änderung dieses Typs. Sie können Vorgänge für bestimmte Schritte im Rotationsprozess manuell aufrufen. | Bei einigen Schritten die Steuerungsebene. Für andere Schritte alle Knoten für Autopilot-Cluster, alle Knoten in jedem Standard-Knotenpool. |
Wenn Sie die Rotation initiieren und die Rotation abschließen, ist der Grad der Unterbrechung folgender:
Wenn die Knoten neu erstellt werden, ist der Grad der Unterbrechung so:
|
| Shielded-Knoten konfigurieren | Manuell initiiert |
Beim Neuerstellen der Steuerungsebene werden Wartungsrichtlinien nicht berücksichtigt. Die Änderungen werden sofort vorgenommen. Beim Neuerstellen der Knoten werden die Wartungsrichtlinien berücksichtigt. |
Einmal pro Änderung dieses Typs |
Die Steuerungsebene wird aktualisiert. Nachdem die Steuerungsebene aktualisiert wurde, müssen alle Knoten in jedem Standard-Knotenpool neu erstellt werden. |
Wenn die Steuerungsebene neu erstellt wird, ist das Ausmaß der Unterbrechung so:
Wenn die Knoten neu erstellt werden, ist das Ausmaß der Unterbrechung so:
|
| Netzwerkrichtlinien konfigurieren | Manuell initiiert | Berücksichtigt Wartungsrichtlinien | Einmal pro Änderung dieses Typs | Alle Knoten für Autopilot-Cluster, alle Knoten in jedem Standard-Knotenpool des Clusters. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. GKE verwendet Surge-Upgrades, um die Knoten neu zu erstellen. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Knoteninterne Sichtbarkeit konfigurieren | Manuell initiiert | Berücksichtigt Wartungsrichtlinien | Einmal pro Änderung dieses Typs | Alle Knoten für Autopilot-Cluster, alle Knoten in jedem Standard-Knotenpool des Clusters. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. GKE verwendet Surge-Upgrades, um die Knoten neu zu erstellen. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| NodeLocal DNSCache konfigurieren | Manuell initiiert | Berücksichtigt Wartungsrichtlinien | Einmal pro Änderung dieses Typs | Alle Knoten im Knotenpool des Standard-Clusters, der aktualisiert wird, müssen aktualisiert werden. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. GKE verwendet Surge-Upgrades, um die Knoten neu zu erstellen. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Image-Streaming aktivieren | Manuell initiiert |
Bei der Aktualisierung auf Clusterebene werden Wartungsrichtlinien berücksichtigt. Beim Aktualisieren einzelner Knotenpools werden Wartungsrichtlinien nicht berücksichtigt. |
Einmal pro Änderung dieses Typs |
Wenn die Option auf Knotenpoolebene aktiviert ist, gilt sie für alle Knoten im Standard-Clusterknotenpool. Wenn die Einstellung auf Clusterebene aktiviert oder deaktiviert wird, gilt sie für Knoten aller Standardcluster-Knotenpools, für die Sie die Einstellung nicht einzeln aktiviert oder deaktiviert haben. |
GKE verwendet Surge-Upgrades, um die Knoten eines Knotenpools neu zu erstellen. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
Automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt
In der folgenden Tabelle wird beschrieben, wie sich die automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt, auf eine Clusterumgebung auswirken kann.
| Ändern | Automatisch oder manuell initiiert | Berücksichtigt Wartungsrichtlinien | Häufigkeit | Art der Störung | Ausmaß der Störung |
|---|---|---|---|---|---|
| Steuerungsebene reparieren oder Größe anpassen | Automatisch | Berücksichtigt keine Wartungsrichtlinien |
Die Häufigkeit der Reparatur der Steuerungsebene ist zufällig, hat aber keine Auswirkungen auf Autopilot- und regionale Standardcluster. Die Größenanpassung der Steuerungsebene erfolgt selten, aber die Häufigkeit nimmt mit Cluster-Skalierungsereignissen zu. Außerdem hat sie keine Auswirkungen auf Autopilot- und regionale Standardcluster. |
Steuerungsebene |
Bei Autopilot- und regionalen Standardclustern bleibt die Steuerungsebene verfügbar. Bei zonalen Standardclustern können Sie mehrere Minuten lang nicht mit der Steuerungsebene kommunizieren. Das bedeutet, dass Sie den Cluster, die Knoten und die Arbeitslasten während dieser Zeit nicht konfigurieren können. |
| Hostwartungsereignis | Automatisch | Berücksichtigt keine Wartungsrichtlinien | Informationen zur ungefähren Häufigkeit finden Sie unter Wartungsereignisse. | Ein Knoten |
Bei den meisten Knotentypen ist die Auswirkung minimal. Bei einigen Knoten, einschließlich Knoten mit GPUs oder TPUs, kann es zu größeren Unterbrechungen kommen. Weitere Informationen finden Sie unter Sonstige Wartung von Google Cloud . |
| Automatische Knotenreparatur | Automatisch | Berücksichtigt keine Wartungsrichtlinien | Die Häufigkeit der automatischen Knotenreparatur ist zufällig. |
Ein Knoten | Der Knoten wird neu gestartet, sodass alle auf dem Knoten ausgeführten Pods unterbrochen werden. |
| Spot-VMs und VMs auf Abruf zurückfordern | Automatisch | Berücksichtigt keine Wartungsrichtlinien |
Bei VMs auf Abruf mindestens einmal alle 24 Stunden. Bei Spot-VMs, wenn Compute Engine die Ressourcen an anderer Stelle benötigt. |
Ein Knoten | Weitere Informationen finden Sie unter Beendigung und ordnungsgemäßes Herunterfahren von Spot-VMs und Beendigung und ordnungsgemäßes Herunterfahren von VMs auf Abruf. |
| Wartung der Spanner-basierten Clusterstatusdatenbank | Automatisch | Berücksichtigt keine Wartungsrichtlinien | Ereignisse sind zufällig und haben keine Auswirkungen auf Cluster oder Arbeitslasten. | Keine. Die Spanner-basierte Datenbank wird getrennt von der Cluster-Steuerungsebene und den Knoten in der Infrastruktur von Google ausgeführt. | Keine. Die Spanner-basierte Datenbank wird für alle Clustertypen repliziert und bleibt während der Wartung verfügbar. |
Manuelle Änderungen, bei denen die Knoten mithilfe einer Knotenupgradestrategie neu erstellt werden, ohne Wartungsrichtlinien zu berücksichtigen
In der folgenden Tabelle wird beschrieben, wie diese manuellen Änderungen eine Clusterumgebung beeinträchtigen können. Diese Liste enthält Änderungen aus Wenn GKE Surge-Upgrades verwendet und Wenn GKE Blau/Grün-Upgrades verwendet, die nicht im anderen Abschnitt enthalten sind, da sie die Wartungsrichtlinien nicht berücksichtigen.
| Ändern | Automatisch oder manuell initiiert | Berücksichtigt Wartungsrichtlinien | Häufigkeit | Art der Störung | Ausmaß der Störung |
|---|---|---|---|---|---|
| Änderungen bei der Erfassung von Logs der Steuerungsebene | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Die Steuerungsebene wird aktualisiert. | Wenn die Steuerungsebene neu erstellt wird, ist das Ausmaß der Unterbrechung so:
|
| Knotenpool-Label aktualisieren | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool | Wenn Sie die Knotenlabels in einem vorhandenen Knotenpool aktualisieren, verwendet GKE sofort Surge-Upgrades, um den Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Knoten vertikal skalieren, indem Sie die Maschinenattribute des Knotens ändern | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool | Die GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Änderungen der Image-Typen | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet die konfigurierte Knoten-Upgradestrategie (Surge, Blau/Grün oder automatisch skaliertes Blau/Grün (Vorabversion)) für Standardcluster. |
| Speicherpools in einem Standardcluster-Knotenpool hinzufügen oder ersetzen | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet die konfigurierte Knoten-Upgradestrategie (Surge, Blau/Grün oder automatisch skaliertes Blau/Grün (Vorabversion)) für Standardcluster. |
| Image-Streaming aktivieren | Manuell initiiert |
Bei der Aktualisierung auf Clusterebene werden Wartungsrichtlinien berücksichtigt. Beim Aktualisieren einzelner Knotenpools werden Wartungsrichtlinien nicht berücksichtigt. |
Einmal pro Änderung dieses Typs |
Wenn die Option auf Knotenpoolebene aktiviert ist, gilt sie für alle Knoten im Standard-Clusterknotenpool. Wenn die Einstellung auf Clusterebene aktiviert oder deaktiviert wird, gilt sie für Knoten aller Standardcluster-Knotenpools, für die Sie die Einstellung nicht einzeln aktiviert oder deaktiviert haben. |
GKE verwendet Surge-Upgrades, um die Knoten eines Knotenpools neu zu erstellen. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Konfigurationsaktualisierungen der Netzwerkleistung | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| gVNIC aktivieren | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Änderungen an der Knotensystemkonfiguration (mit der Standard-Upgradestrategie) | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
| Vertrauliche Knoten | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle Knoten in einem Standard-Clusterknotenpool |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Pods müssen ersetzt werden. Die GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. Die GKE verwendet Surge-Upgrades, unabhängig davon, ob eine andere Strategie für Knotenupgrades wie Blau/Grün-Upgrades konfiguriert ist. |
Änderungen, die keine Neuerstellung der Knoten erfordern
In der folgenden Tabelle sehen Sie, bei welchen Änderungen an der Knotenkonfiguration die Knoten nicht neu erstellt werden müssen. Diese Änderungen sind nicht störend. Es kann jedoch zu Störungen kommen, wenn sich die aktualisierte Knotenkonfiguration auf Ihre Arbeitslast auswirkt.
| Ändern | Automatisch oder manuell initiiert | Berücksichtigt Wartungsrichtlinien | Häufigkeit | Art der Störung | Ausmaß der Störung |
|---|---|---|---|---|---|
|
Aktualisieren Sie die folgenden Einstellungen:
|
Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieses Typs | Alle relevanten Knoten werden aktualisiert. | Pods müssen nicht ersetzt werden, da die Knotenkonfiguration aktualisiert wird, ohne die Knoten neu zu erstellen. |
Nächste Schritte
- GKE-Übersicht
- GKE-Clusterarchitektur
- Gemeinsame Verantwortung für GKE
- Versionsverwaltung und Unterstützung für GKE
- GKE Service Level Agreement
- GKE-Clusterupgrades