Auf dieser Seite wird erläutert, wie Sie und Google Kubernetes Engine (GKE) Änderungen während des Lebenszyklus eines Clusters verwalten, um 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 Lesen der Informationen zum Ausführen der grundlegenden Clusterverwaltungsaufgaben in Cluster verwalten und Übersicht über die Clusterverwaltung lesen.
Verwaltete Plattform und geteilte 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 Verwaltungs-Knoten mit Systemkomponenten umfasst, und Worker-Knoten, auf denen Sie Arbeitslasten bereitstellen.
Die Verantwortung für die Erstellung einer optimalen Clusterumgebung für die Ausführung Ihrer Arbeitslasten mit maximaler Leistung, Verfügbarkeit und minimalen Unterbrechungen ist aufgeteilt:
- GKE ist dafür verantwortlich, eine zuverlässige, verfügbare, sichere und leistungsstarke Clusterumgebung bereitzustellen. Dazu verwaltet GKE die Steuerungsebene, 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 GKE-Modell der geteilten Verantwortung.
So verwaltet GKE Änderungen während des Lebenszyklus eines Clusters
Als Implementierung von Kubernetes ist ein GKE-Cluster ein Netzwerk von Prozessen und Systemen, die zusammenarbeiten, um die optimale Umgebung für die Ausführung Ihrer Arbeitslasten zu schaffen. 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 können, wie im nächsten Abschnitt beschrieben.
Einige Clusteränderungen können sich negativ auf Arbeitslasten auswirken
GKE ist darauf ausgelegt, Ihre Arbeitslasten nahtlos auszuführen. Einige wichtige Arten von Änderungen können jedoch vorübergehende Unterbrechungen Ihrer Arbeitslasten erfordern, insbesondere Änderungen, bei denen die Knoten, auf denen Ihre Arbeitslasten ausgeführt werden, neu gestartet werden. Mit GKE- und Kubernetes-Funktionen können Sie angeben, wann und wie Störungen auftreten sollen, damit Ihre Arbeitslasten die Änderungen problemlos verarbeiten können.
In den folgenden Abschnitten wird erläutert, welche Arten von Änderungen 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 Clusterupgrades und Clusterupdates ähnliche Bedeutungen.
In GKE bezieht sich der Begriff Clusterupgrades oder einfach Upgrades auf das Aktualisieren der Kubernetes-Version der Steuerungsebene (Steuerungsebenen-Upgrades) oder der Knoten (Knotenupgrades) oder beider. Bei Standardclustern werden Knoten-Upgrades auch als Knotenpool-Upgrades bezeichnet, da GKE einen einzelnen Vorgang verwendet, um einen Knotenpool zu aktualisieren.
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. GKE verwaltet Ihre Clusterumgebung aktiv, indem Upgrades, andere Arten von Updates und erforderliche Wartungsvorgänge durchgeführt werden. Durch diese Maßnahmen bleibt Ihr Cluster leistungsstark, sicher und auf dem neuesten Stand mit den neuesten Funktionen und Fehlerkorrekturen. GKE verwendet Tools wie Knoten-Upgradestrategien und Wartungsrichtlinien, um Unterbrechungen während dieser Prozesse zu minimieren.
Unterbrechungen bei Knoten-Updates planen
Bestimmte Arten von Clusteränderungen, hauptsächlich Änderungen an Knoten, können zu Unterbrechungen führen.
GKE verwendet Knoten-Upgradestrategien, um Knoten zu aktualisieren – sowohl Autopilot-Knoten als auch Knotenpools von Standardclustern – und zwar so, 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 den Strategien kann GKE Unterbrechungen bei Knotenupdates minimieren. Knotenupdates sind wichtig, damit Cluster funktionsfähig und leistungsstark bleiben.
Mit Wartungsfenstern und -ausschlüssen können Sie festlegen, wann bestimmte Clusterwartungen stattfinden und wann nicht. Bei Standardclustern können Sie außerdem eine Knoten-Upgrade-Strategie 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 in der Regel durch GKE-Wartungsrichtlinien berücksichtigt.
Beachten Sie Folgendes, wenn Sie manuelle Änderungen vornehmen, die erfordern, dass alle Knoten in einem Knotenpool neu erstellt werden:
- Bei einigen Änderungen berücksichtigt GKE Wartungsrichtlinien und wendet die von Ihnen eingereichte Änderung erst an, wenn eine Wartung verfügbar ist. Wenn GKE auf die Verfügbarkeit für die Wartung 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, werden Wartungsrichtlinien von GKE nicht berücksichtigt. Achten Sie bei diesen manuellen Änderungen darauf, dass Ihre Arbeitslasten auf sofortige Unterbrechungen vorbereitet sind.
- Änderungen verwenden in der Regel Strategien für Knotenupgrades: Wenn GKE die meisten automatischen oder manuell initiierten Änderungen an Knoten anwendet, einschließlich Knotenupdates, die keine Versionsupgrades sind, wählt GKE eine Strategie für Knotenupgrades aus: Surge-Upgrades oder Blau/Grün-Upgrades. Autopilot verwendet immer Surge-Upgrades. Bei Änderungen an Knotenpools von Standardclustern werden in der Regel Surge-Upgrades verwendet, es sei denn, Sie haben Blau/Grün-Upgrades konfiguriert und nehmen bestimmte Arten von Änderungen vor.
- Für Änderungen sind ausreichend Ressourcen erforderlich: Wenn GKE eine Änderung mit einer Knotenupgrade-Strategie anwendet, sind dafür je nach Strategie und Konfiguration bestimmte Ressourcen erforderlich. Das Projekt Ihres Clusters muss über genügend Ressourcenkontingente, Ressourcenverfügbarkeit und 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 maximieren, indem Sie sich auf störende Änderungen vorbereiten
Damit die Verfügbarkeit Ihrer Arbeitslasten, die in einem GKE-Cluster ausgeführt werden, maximiert wird, empfehlen wir Ihnen, die in den folgenden Abschnitten beschriebenen Maßnahmen zu ergreifen:
Clusterverfügbarkeit auswählen
Wenn die Verfügbarkeit der Steuerungsebene Priorität hat, sollten Sie einen Autopilot-Cluster oder einen regionalen Standardcluster anstelle eines zonalen Standardclusters auswählen. 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, sodass Sie die Best Practices implementieren können:
- 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-Clusterwartung>, z. B. Upgrades, stattfinden können.
- Wartungsausschlüsse: Verhindern Sie, dass die Clusterwartung für einen bestimmten Zeitraum ausgeführt wird.
- Strategien für Knotenupgrades: Wenn Sie Standardcluster verwenden, können Sie auswählen, wie Ihre Knoten aktualisiert werden – mit Surge-Upgrades oder Blau/Grün-Upgrades –, um Unterbrechungen Ihrer Arbeitslasten zu minimieren.
- Roll-out-Sequenzierung: Sie können Upgrades in einer Vorproduktionsumgebung qualifizieren, bevor GKE Ihre Produktionscluster aktualisiert.
- Manuelle Upgrades: Sie können Ihren Cluster manuell aktualisieren und Aktionen wie das Abbrechen, Fortsetzen, Rückgängigmachen und Abschließen von automatischen oder manuellen Upgrades ausführen, die gerade laufen.
Cluster verwalten und überwachen
Um potenzielle Unterbrechungen Ihrer Cluster zu vermeiden, führen Sie die folgenden Aufgaben kontinuierlich aus:
- Überwachen Sie Ihren Cluster mit der GKE-Suite für Beobachtbarkeit.
- Abonnieren Sie die GKE-Versionshinweise, um Ankündigungen zu erhalten.
- Clusterbenachrichtigungen ansehen, z. B. wenn Upgrades gestartet oder abgeschlossen werden, wenn neue Versionen verfügbar sind, Sicherheitsbulletins und End-of-Support-Termine.
- Einblick in Cluster-Upgrades erhalten, um den Status von Upgrades für Ihre Cluster zu sehen.
- Im GKE-Releasezeitplan finden Sie eine Schätzung des besten Falls, wann Nebenversionen für Upgrades verfügbar sind und das Ende des Supports erreichen.
- Nutzen Sie die empfehlenden Anleitungen, in denen potenzielle Optimierungsmöglichkeiten aufgezeigt und die Optimierung der Clusternutzung erläutert wird, einschließlich Anleitungen für das Einstellen von Funktionen und APIs.
Arbeitslasten vorbereiten
So können Sie Störungen verwalten, indem Sie Ihre Arbeitslasten so störungsresistent wie möglich machen:
- Führen Sie Replikate Ihrer Arbeitslasten aus, um Redundanz zu gewährleisten und einen Single Point of Failure zu vermeiden.
- Sie können ein Unterbrechungsbudget für Ihre Anwendung mit einem Budget für Pod-Störungen festlegen.
- Legen Sie einen Kulanzzeitraum für die Beendigung mit der richtigen Länge für Ihre Arbeitslast fest, damit sie ordnungsgemäß heruntergefahren werden kann.
- Wenn Ihre Arbeitslast GPUs oder TPUs verwendet, folgen Sie der Anleitung zum Verwalten von GKE-Knotenunterbrechungen für GPUs und TPUs.
- Bei zustandsorientierten 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 Störungen vorbereiten.
Eine allgemeine Erläuterung dieser Themen finden Sie im Abschnitt Unterbrechungen verwalten des Blogposts GKE-Best Practices: Tag 2-Vorgänge für 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 sehen Sie, wie sich Upgrades auf eine Clusterumgebung auswirken können.
Ändern | Automatisch oder manuell initiiert | Wartungsrichtlinien werden eingehalten | Häufigkeit | Art der Störung | Grad der Unterbrechung |
---|---|---|---|---|---|
Upgrade der Steuerungsebene | Automatisch oder manuell |
Automatische Upgrades berücksichtigen 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 Nebenversions-Upgrades nur durchgeführt, wenn die Nebenversion sich dem Ende des Supports nähert. |
Steuerungsebene |
Bei Autopilot- und regionalen Standardclustern bleibt die Steuerungsebene verfügbar. Bei zonalen Standardclustern kann es mehrere Minuten dauern, bis Sie wieder mit der Steuerungsebene kommunizieren können. In dieser Zeit können Sie den Cluster, die Knoten und die Arbeitslasten nicht konfigurieren. |
Knotenupgrade | Automatisch oder manuell |
Automatische Upgrades berücksichtigen Wartungsrichtlinien bis zum Ende des Supports, mit Ausnahme von extrem seltenen Notfallkorrekturen, falls erforderlich. Manuelle Upgrades werden nicht durch Wartungsrichtlinien blockiert. |
In der Regel entspricht dies den Upgrades der Steuerungsebene. Wenn Ihr Cluster nicht für eine Release-Version registriert ist und Sie automatische Knotenupgrades deaktivieren, sind Sie für das manuelle Upgrade der Knotenpools Ihres Clusters verantwortlich. |
Alle Knoten für Autopilot-Cluster oder ein oder mehrere Knotenpools für Standardcluster. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet Surge-Upgrades für Autopilot-Cluster oder die konfigurierte Strategie für Knotenupgrades (Surge oder Blau/Grün) für Standard-Cluster. |
Manuelle Änderungen, bei denen die Knoten mit einer Knotenupgrade-Strategie und unter Berücksichtigung der Wartungsrichtlinien neu erstellt werden
In der folgenden Tabelle sehen Sie, wie sich diese manuellen Änderungen auf eine Clusterumgebung auswirken können. Diese Liste enthält unter anderem manuelle Änderungen, die GKE-Wartungsrichtlinien berücksichtigen.
Ändern | Automatisch oder manuell initiiert | Wartungsrichtlinien werden eingehalten | Häufigkeit | Art der Störung | Grad der Unterbrechung |
---|---|---|---|---|---|
Schreibgeschützten Port für Kubelet deaktivieren | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art. | Alle Knoten in einem Autopilot-Cluster Alle Knoten in einem Knotenpool eines Standard-Clusters. |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden. Die Pods müssen ersetzt werden. GKE verwendet sofort Surge-Upgrades, um die Knoten neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
Clusteranmeldedaten rotieren | Die Rotation erfolgt automatisch, wenn Clusteranmeldedaten innerhalb von 30 Tagen ablaufen. Sie kann aber auch manuell initiiert werden. | Wartungsrichtlinien werden berücksichtigt. 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, nämlich die Rotation starten. Wenn Sie nach dem ersten Schritt bestimmte Vorgänge manuell auslösen, werden Wartungsrichtlinien für diesen Vorgang nicht berücksichtigt. | Einmal pro manueller Änderung dieses Typs oder abhängig von der Lebensdauer von Clusteranmeldedaten für die automatische Initiierung. Sie können Vorgänge für bestimmte Schritte im Rotationsprozess manuell aufrufen. | Für einige Schritte die Steuerungsebene. Für andere Schritte: alle Knoten für Autopilot-Cluster, alle Knoten in jedem Knotenpool von Standardclustern. |
Wenn Sie die Rotation starten und abschließen, ist die Störung so:
Wenn die Knoten neu erstellt werden, ist die Unterbrechung wie folgt:
|
IP-Adresse der Steuerungsebene rotieren | Manuell initiiert | Wartungsrichtlinien werden berücksichtigt. Wenn Sie jedoch nach dem ersten Schritt bestimmte Vorgänge manuell auslösen, werden Wartungsrichtlinien für diesen Vorgang nicht berücksichtigt. | Einmal pro manueller Änderung dieses Typs. Sie können Vorgänge für bestimmte Schritte im Rotationsprozess manuell aufrufen. | Für einige Schritte die Steuerungsebene. Für andere Schritte: alle Knoten für Autopilot-Cluster, alle Knoten in jedem Knotenpool von Standardclustern. |
Wenn Sie die Rotation starten und abschließen, ist die Störung so:
Wenn die Knoten neu erstellt werden, ist die Unterbrechung wie folgt:
|
Shielded-Knoten konfigurieren | Manuell initiiert |
Beim Neuerstellen der Steuerungsebene werden Wartungsrichtlinien nicht berücksichtigt und die Änderungen werden sofort vorgenommen. Beim Neuerstellen der Knoten werden die Wartungsrichtlinien berücksichtigt. |
Einmal pro Änderung dieser Art |
Die Steuerungsebene wird aktualisiert. Nachdem die Steuerungsebene aktualisiert wurde, müssen alle Knoten in jedem Knotenpool des Standard-Clusters neu erstellt werden. |
Wenn die Steuerungsebene neu erstellt wird, ist das Maß der Unterbrechung wie folgt:
Wenn die Knoten neu erstellt werden, ist die Unterbrechung wie folgt:
|
Netzwerkrichtlinien konfigurieren | Manuell initiiert | Wartungsrichtlinien werden eingehalten | Einmal pro Änderung dieser Art | Alle Knoten für Autopilot-Cluster, alle Knoten in jedem Knotenpool von Standardclustern. |
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. |
Knoteninterne Sichtbarkeit konfigurieren | Manuell initiiert | Wartungsrichtlinien werden eingehalten | Einmal pro Änderung dieser Art | Alle Knoten für Autopilot-Cluster, alle Knoten in jedem Knotenpool von Standardclustern. |
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. |
NodeLocal DNSCache konfigurieren | Manuell initiiert | Wartungsrichtlinien werden eingehalten | Einmal pro Änderung dieser Art | Alle Knoten im Knotenpool des Standard-Clusters, die aktualisiert werden, 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. |
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 dieser Art |
Wenn die Option auf Knotenpoolebene aktiviert ist, gilt sie für alle Knoten im Knotenpool des Standard-Clusters. Wenn die Einstellung auf Clusterebene aktiviert oder deaktiviert wird, gilt sie für Knoten in allen Knotenpools von Standardclustern, für die Sie die Einstellung nicht individuell aktiviert oder deaktiviert haben. |
GKE verwendet Surge-Upgrades, um die Knoten eines Knotenpools neu zu erstellen. |
Automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt
In der folgenden Tabelle sehen Sie, wie sich automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt, auf eine Clusterumgebung auswirken kann.
Ändern | Automatisch oder manuell initiiert | Wartungsrichtlinien werden eingehalten | Häufigkeit | Art der Störung | Grad der Unterbrechung |
---|---|---|---|---|---|
Reparatur oder Größenänderung der Steuerungsebene | Automatisch | Wartungsrichtlinien werden nicht berücksichtigt |
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 nur selten, wird aber bei Cluster-Skalierungsereignissen häufiger. Sie hat auch keine Auswirkungen auf Autopilot- und regionale Standardcluster. |
Steuerungsebene |
Bei Autopilot- und regionalen Standardclustern bleibt die Steuerungsebene verfügbar. Bei zonalen Standardclustern kann es mehrere Minuten dauern, bis Sie wieder mit der Steuerungsebene kommunizieren können. In dieser Zeit können Sie den Cluster, die Knoten und die Arbeitslasten nicht konfigurieren. |
Hostwartungsereignis | Automatisch | Wartungsrichtlinien werden nicht berücksichtigt | Die ungefähre Häufigkeit finden Sie unter Wartungsereignisse. | Ein Knoten |
Bei den meisten Knotentypen ist der Effekt minimal. Bei einigen Knoten, einschließlich Knoten mit GPUs oder TPUs, kann es zu größeren Unterbrechungen kommen. Weitere Informationen finden Sie unter Andere Trusted Cloud by S3NS Wartungsarbeiten. |
Automatische Knotenreparatur | Automatisch | Wartungsrichtlinien werden nicht berücksichtigt | 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 | Wartungsrichtlinien werden nicht berücksichtigt |
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 | Wartungsrichtlinien werden nicht berücksichtigt | Ereignisse sind zufällig und haben keine Auswirkungen auf Cluster oder Arbeitslasten. | Keine. Die Spanner-basierte Datenbank wird in der Infrastruktur von Google separat von der Steuerungsebene und den Knoten des Clusters ausgeführt. | Keine. Die Spanner-basierte Datenbank wird für alle Arten von Clustern repliziert und bleibt während der Wartung verfügbar. |
Manuelle Änderungen, bei denen die Knoten mit einer Knoten-Upgrade-Strategie neu erstellt werden, ohne die Wartungsrichtlinien zu berücksichtigen
In der folgenden Tabelle sehen Sie, wie sich diese manuellen Änderungen auf eine Clusterumgebung auswirken 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 | Wartungsrichtlinien werden eingehalten | Häufigkeit | Art der Störung | Grad der Unterbrechung |
---|---|---|---|---|---|
Aktualisierung des Knotenpool-Labels | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters | GKE verwendet sofort Surge-Upgrades, um den Knotenpool neu zu erstellen, wenn Sie die Knotenlabels in einem vorhandenen Knotenpool aktualisieren. Dies geschieht unabhängig von aktiven Wartungsrichtlinien. |
Knoten vertikal skalieren, indem Sie die Maschinenattribute des Knotens ändern | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters | GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
Änderungen der Image-Typen | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet die konfigurierte Strategie für Knotenupgrades (Surge oder Blau/Grün) für Standard-Cluster. |
Speicherpools in einem Knotenpool eines Standardclusters hinzufügen oder ersetzen | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet die konfigurierte Strategie für Knotenupgrades (Surge oder Blau/Grün) für Standard-Cluster. |
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 dieser Art |
Wenn die Option auf Knotenpoolebene aktiviert ist, gilt sie für alle Knoten im Knotenpool des Standard-Clusters. Wenn die Einstellung auf Clusterebene aktiviert oder deaktiviert wird, gilt sie für Knoten in allen Knotenpools von Standardclustern, für die Sie die Einstellung nicht individuell aktiviert oder deaktiviert haben. |
GKE verwendet Surge-Upgrades, um die Knoten eines Knotenpools neu zu erstellen. |
Konfigurationsaktualisierungen der Netzwerkleistung | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
gVNIC aktivieren | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
Änderungen an der Knotensystemkonfiguration | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
Vertrauliche Knoten | Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | Alle Knoten in einem Knotenpool eines Standard-Clusters |
Knoten müssen heruntergefahren werden, um neu erstellt zu werden, Pods müssen ersetzt werden. GKE verwendet sofort Surge-Upgrades, um die Knoten in einem vorhandenen Knotenpool neu zu erstellen, unabhängig von aktiven Wartungsrichtlinien. |
Ä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 | Wartungsrichtlinien werden eingehalten | Häufigkeit | Art der Störung | Grad der Unterbrechung |
---|---|---|---|---|---|
Aktualisieren Sie die folgenden Einstellungen:
|
Manuell initiiert | Wartungsrichtlinien werden nicht berücksichtigt, Änderungen werden sofort vorgenommen. | Einmal pro Änderung dieser Art | 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-Cluster-Upgrades