Wartungsfenster und Ausschlüsse

Auf dieser Seite werden Wartungsfenster und Wartungsausschlüsse beschrieben. Dies sind Richtlinien, mit denen gesteuert wird, wann eine Clusterwartung, z. B. automatische Upgrades, möglich ist und wann nicht in Ihren Google Kubernetes Engine-Clustern (GKE) auftreten. So könnte beispielsweise ein Einzelhandelsunternehmen die Wartung auf Abende an Werktagen beschränken und automatische Wartungsmaßnahmen während wichtiger Verkaufsaktionen unterbinden.

Informationen zu GKE-Wartungsrichtlinien

Mit GKE-Wartungsrichtlinien, die Wartungsfenster und -ausschlüsse enthalten, können Sie steuern, wann bestimmte automatische Wartungsmaßnahmen an Ihren Clustern durchgeführt werden, einschließlich Clusterupgrades und anderer Änderungen an der Knotenkonfiguration oder der Netzwerktopologie des Clusters. “ ´

Ein Wartungsfenster ist ein sich wiederholender Zeitraum, in dem eine automatische GKE-Wartung zulässig ist.

Ein Wartungsausschluss ist ein sich nicht wiederholender Zeitraum, in dem keine automatische Wartung stattfinden darf.

GKE nimmt automatische Änderungen vor, die die Wartungsrichtlinien Ihres Clusters berücksichtigen, wenn ein offenes Wartungsfenster und kein aktiver Wartungsausschluss vorhanden ist. Für jeden Cluster können Sie ein wiederkehrendes Wartungsfenster und mehrere Wartungsausschlüsse konfigurieren.

Andere Arten der Wartung sind nicht von GKE-Wartungsrichtlinien abhängig, einschließlich Reparaturvorgänge der Steuerungsebene und Wartung von Diensten, von denen GKE abhängig ist, z. B. Compute Engine. Weitere Informationen finden Sie unter Automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt.

Welche Änderungen wirken sich auf die Wartungsrichtlinien von GKE aus?

Bevor Sie GKE-Wartungsrichtlinien – Wartungsfenster und -ausschlüsse – konfigurieren lesen Sie in den folgenden Abschnitten, wie GKE und die zugehörigen Dienste diese befolgen und nicht berücksichtigen.

Automatische Wartung unter Einhaltung der GKE-Wartungsrichtlinien

Mit GKE-Wartungsrichtlinien können Sie den Zeitpunkt der folgenden Ereignistypen steuern, die zu einer vorübergehenden Unterbrechung Ihres Clusters führen:

Andere Arten der automatischen Wartung hängen nicht von Wartungsrichtlinien ab. Weitere Informationen finden Sie unter Automatische Wartung, die Wartungsrichtlinien nicht berücksichtigt.

Automatische Wartung, die die GKE-Wartungsrichtlinien nicht berücksichtigt

GKE-Wartungsfenster und -ausschlüsse blockieren nicht alle Arten der automatischen Wartung. Bevor Sie die Wartungsrichtlinien Ihres GKE-Clusters konfigurieren, sollten Sie sich darüber informieren, welche Arten von Änderungen keine Wartungsfenster und -ausschlüsse berücksichtigen.

Weitere Wartungsmaßnahmen von Google Cloud

GKE-Wartungsfenster und -ausschlüsse verhindern nicht die automatische Wartung von zugrunde liegenden Google Cloud-Diensten, hauptsächlich Compute Engine, oder Diensten, die Anwendungen im Cluster installieren, wie Cloud Deploy.

GKE-Knoten sind beispielsweise Compute Engine-VMs, die GKE für Ihren Cluster verwaltet. Bei Compute Engine-VMs treten manchmal Hostereignisse auf, die Wartungsereignisse oder Hostfehler umfassen können. Das Verhalten von VMs während dieser Ereignisse wird durch die Hostwartungsrichtlinie der VM bestimmt, die für die meisten VMs standardmäßig eine Live-Migration bedeutet. Dies bedeutet in der Regel nur geringe bis gar keine Ausfallzeiten für die Knoten und für die meisten Arbeitslasten sind die Standardrichtlinien ausreichend. Bei einigen VM-Maschinenfamilien haben Sie folgende Möglichkeiten: Hostwartungen überwachen und planen und Ein Hostwartungsereignis auslösen und mit Ihren GKE-Wartungsrichtlinien terminieren.

Einige VMs, einschließlich VMs mit GPUs und TPUs, können keine Live-Migration ausführen. Wenn Sie diese Beschleuniger verwenden, erfahren Sie, wie Sie Unterbrechungen aufgrund von Knotenwartungen für GPUs oder TPUs bewältigen können. “

Wir empfehlen Ihnen, sich Informationen über dieHostereignisse ,Hostwartungsrichtlinien anzusehen. Bestätigen Sie, dass Ihre Arbeitslasten auf Störungen vorbereitet sind, insbesondere wenn sie auf Knoten ausgeführt werden, die keine Live-Migration durchführen können.

Automatisierte Reparaturen und Größenanpassungen

GKE führt automatisierte Reparaturen für Steuerungsebenen aus. Dazu gehören Prozesse wie das Skalieren der Steuerungsebene auf eine geeignete Größe oder ein Neustart der Steuerungsebene, um Probleme zu beheben. Bei den meisten Reparaturen werden Wartungsfenster und -ausschlüsse ignoriert, da fehlgeschlagene Reparaturen zur Folge haben können, dass Cluster nicht funktionieren.

Reparaturen der Steuerungsebene können nicht deaktiviert werden. Die meisten Clustertypen, einschließlich Autopilot-Cluster und regionaler Standardcluster, haben jedoch mehrere Replikate der Steuerungsebenen. Dies ermöglicht eine hohe Verfügbarkeit des Kubernetes API-Servers auch während Wartungsereignissen. Zonale Standardcluster, die nur eine einzige Steuerungsebene haben, können bei Konfigurationsänderungen der Steuerungsebene und Clusterwartung nicht geändert werden. Dies beinhaltet die Bereitstellung von Arbeitslasten.

Knoten haben auch eine Funktion zur automatischen Reparatur, die Sie für Standardcluster deaktivieren können.

Patchen kritischer Sicherheitslücken

Wartungsfenster und Wartungsausschlüsse können zur Folge haben, dass Sicherheitspatches mit Verspätung aufgespielt werden. GKE behält sich jedoch das Recht vor, bei kritischen Sicherheitslücken Wartungsrichtlinien außer Kraft zu setzen.

Manuelle Änderungen, die GKE-Wartungsrichtlinien berücksichtigen

Bei einigen Änderungen an den Knoten oder der Netzwerkkonfiguration müssen die Knoten neu erstellt werden, damit die neue Konfiguration angewendet wird. Dazu gehören einige der folgenden Änderungen:

Diese Änderungen berücksichtigen die GKE-Wartungsrichtlinien. Das bedeutet, dass GKE auf ein offenes Wartungsfenster wartet und darauf wartet, dass kein aktiver Wartungsausschluss vorhanden ist, der die Knotenwartung verhindert. Wenn Sie die Änderungen manuell auf die Knoten anwenden möchten, verwenden Sie das Google Cloud CLI, um den Befehl gcloud container clusters upgrade aufzurufen und das Flag --cluster-version mit derselben GKE-Version zu übergeben, die der Knotenpool bereits ausführt.

Wartungsfenster

Mit Wartungsfenstern können Sie steuern, wann automatische Upgrades von Steuerungsebenen und Knoten stattfinden dürfen, um potenzielle vorübergehende Unterbrechungen Ihrer Arbeitslasten zu minimieren. Wartungsfenster sind unter anderem für die folgenden Szenarios hilfreich:

  • Außerhalb der Hauptbetriebszeiten: Sie möchten die Wahrscheinlichkeit von Ausfallzeiten minimieren und automatische Upgrades außerhalb der Hauptbetriebszeiten planen, wenn der Traffic reduziert ist.
  • Auf Abruf: Sie möchten, dass Upgrades während der Geschäftszeiten stattfinden, damit die Prozesse überwacht und unerwartete Probleme sofort behoben werden können.
  • Multi-Cluster-Upgrades: Sie möchten Upgrades in mehreren Clustern in verschiedenen Regionen nacheinander und in bestimmten Intervallen durchführen.

Neben automatischen Upgrades muss Google gelegentlich weitere Wartungsaufgaben ausführen und berücksichtigt dabei nach Möglichkeit das Wartungsfenster eines Clusters.

Wenn Aufgaben länger dauern als das Wartungsfenster geöffnet ist, versucht GKE, die Aufgaben zu unterbrechen und während des nächsten Wartungsfensters wieder zu aktivieren.

GKE behält sich das Recht vor, ungeplante Notfallupgrades außerhalb von Wartungsfenstern durchzuführen. Außerdem können obligatorische Upgrades von eingestellter oder veralteter Software automatisch außerhalb von Wartungsfenstern erfolgen.

Informationen zum Einrichten eines Wartungsfensters für einen neuen oder vorhandenen Cluster finden Sie unter Wartungsfenster konfigurieren.

Zeitzonen für Wartungsfenster

Wenn Wartungsfenster konfiguriert und eingesehen werden, werden die Zeiten je nach verwendetem Tool unterschiedlich angezeigt:

Bei der Konfiguration von Wartungsfenstern

Uhrzeiten werden immer in UTC gespeichert. Beim Konfigurieren des Wartungsfensters verwenden Sie jedoch entweder UTC oder Ihre lokale Zeitzone.

Wenn Sie Wartungsfenster mit dem allgemeineren Flag --maintenance-window konfigurieren, können Sie keine Zeitzone festlegen. UTC wird verwendet, wenn die gcloud CLI oder die API verwendet werden. In der Google Cloud Console werden Zeiten entsprechend der lokalen Zeitzone angezeigt.

Bei Verwendung detaillierterer Flags wie --maintenance-window-start können Sie die Zeitzone als Teil des Wertes angeben. Wenn Sie die Zeitzone weglassen, wird Ihre lokale Zeitzone verwendet.

Bei der Ansicht von Wartungsfenstern

Wenn Sie Informationen zu Ihrem Cluster ansehen, werden Zeitstempel für Wartungsfenster möglicherweise in UTC oder in Ihrer lokalen Zeitzone angezeigt. Dies ist davon abhängig, auf welche Weise Sie die Informationen anzeigen lassen:

  • Wenn Sie Informationen zu Ihrem Cluster in der Google Cloud Console abrufen, werden die Zeiten immer entsprechend Ihrer lokalen Zeitzone angegeben.
  • Wenn Sie Informationen zum Cluster mit der gcloud CLI abrufen, werden die Zeiten immer in UTC angegeben.

In beiden Fällen ist die RRULE immer in UTC. Das heißt, wenn Sie beispielsweise Tage der Woche angeben, sind diese Tage in UTC angegeben.

Wartungsausschlüsse

Mit Wartungsausschlüssen können Sie verhindern, dass zu bestimmten Zeiten automatische Wartungsmaßnahmen ausgeführt werden. Viele Einzelhandelsunternehmen haben z. B. Richtlinien, nach denen Änderungen an der Infrastruktur in der Weihnachtszeit untersagt sind. Ein weiteres Beispiel: Wenn ein Unternehmen eine API verwendet, die eingestellt werden soll, kann er Wartungsausschlüsse verwenden, um kleinere Upgrades zu pausieren, um Zeit für die Migration der Anwendungen zu haben.

Bei bekannten Ereignissen mit erheblichen Auswirkungen empfehlen wir, alle internen Änderungseinschränkungen mit einem Wartungsausschluss abzugleichen, der eine Woche vor dem Ereignis beginnt und für die Dauer des Ereignisses andauert.

Ausschlüsse können nicht als wiederkehrend festgelegt werden. Stattdessen muss jede Instanz eines regelmäßigen Ausschlusses separat erstellt werden.

Wenn sich Ausschlüsse und Wartungsfenster überschneiden, haben Ausschlüsse Vorrang.

Informationen zum Einrichten von Wartungsausschlüssen für einen neuen oder vorhandenen Cluster finden Sie unter Wartungsausschluss konfigurieren.

Umfang des Wartungsausschlusses

Sie können nicht nur angeben, wann automatische Wartungsmaßnahmen für Ihren Cluster verhindert werden, sondern auch den Bereich automatischer Updates einschränken. Wartungsausschlussbereiche sind für die folgenden Arten von Szenarien nützlich:

  • Keine Upgrades – Wartung vermeiden: Sie möchten vorübergehend Änderungen an Ihrem Cluster während eines bestimmten Zeitraums vermeiden. Dies ist der Standardbereich.
  • Keine Nebenversionsupgrades – Aktuelle Kubernetes-Nebenversion beibehalten: Sie möchten die Nebenversion eines Clusters vorübergehend beibehalten, um API-Änderungen zu vermeiden oder die nächste Nebenversion zu validieren.
  • Keine Nebenversions- oder Knotenupgrades – Unterbrechung des Knotens verhindern: Sie möchten vorübergehend die Bereinigung und Neuplanung Ihrer Arbeitslasten aufgrund von Knotenupgrades vermeiden.

In der folgenden Tabelle wird aufgeführt, wie die einzelnen Bereiche Nebenversions- oder Patchupgrades für die Steuerungsebenen oder Knoten von Clustern einschränken.

Wenn GKE einen Cluster aktualisiert, werden die VMs für die Steuerungsebene und den Knoten neu gestartet. Bei Steuerungsebenen, Autopilot- und regionalen Standardclustern wird die Verfügbarkeit des Kubernetes API-Servers aufrechterhalten. In zonalen Clustern mit einem einzelnen Knoten der Steuerungsebene ist die Steuerungsebene nach einem VM-Neustart vorübergehend nicht verfügbar. Bei Knoten starten VM-Neustarts eine Pod-Neuplanung, die vorhandene Arbeitslasten vorübergehend beeinträchtigen können. Sie können eine Toleranz für Arbeitslastunterbrechungen mit einem Budget für Pod-Störungen (PDB) festlegen.

Umfang Steuerungsebene Knoten
Nebenversionsupgrade Patchversionsupgrade Nebenversionsupgrade Patchversionsupgrade
Keine Upgrades (Standard) Nein Nein Nein Nein
Keine Nebenversionsupgrades Nein Ja Nein Ja
Keine Nebenversions- oder Knotenupgrades Nein Ja Nein Nein

Definitionen zu Nebenversion und Patchversion finden Sie unter Versionsverwaltungsschema.

Mehrere Ausschlüsse

Sie können mehrere Ausschlüsse für einen Cluster festlegen. Diese Ausschlüsse können unterschiedliche Bereiche und überlappende Zeiträume haben. Der Anwendungsfall "Festtage zum Jahresende" ist ein Beispiel für überlappende Ausschlüsse, bei dem sowohl der Bereich "Keine Upgrades" als auch der Bereich "Keine Nebenversionsupgrades" verwendet werden.

Wenn sich Ausschlüsse überschneiden, wenn ein aktiver Ausschluss (d. h. die aktuelle Zeit innerhalb des Ausschlusszeitraums) ein Upgrade blockiert, wird das Upgrade verschoben.

Unter Verwendung des Anwendungsfalls "Festtage zum Jahresende" hat ein Cluster die folgenden Ausschlüsse spezifiziert:

  • Keine Nebenversionsupgrades: 30. September bis 15. Januar
  • Keine Upgrades: 19. November bis 4. Dezember
  • Keine Upgrades: 15. Dezember bis 5. Januar

Aufgrund dieser überlappenden Ausschlüsse werden die folgenden Upgrades auf dem Cluster blockiert:

  • Patchupgrade auf den Knotenpool am 25. November (abgelehnt durch Ausschluss "Keine Upgrades")
  • Nebenversionsupgrade auf die Steuerungsebene am 20. Dezember (abgelehnt durch Ausschlüsse "Keine Nebenversionsupgrades" und "Kein Upgrade")
  • Patchupgrade auf die Steuerungsebene am 25. Dezember (abgelehnt durch Ausschluss "Keine Upgrades")
  • Nebenversionsupgrade auf den Knotenpool am 1. Januar (abgelehnt durch Ausschlüsse "Keine Nebenversionsupgrades" und "Kein Upgrade")

Die folgende Wartung wäre im Cluster zulässig:

  • Patchupgrade auf die Steuerungsebene am 10. November (zugelassen durch Ausschluss "Keine Nebenversionsupgrades")
  • VM-Unterbrechung aufgrund der GKE-Wartung am 10. Dezember (zugelassen durch Ausschluss "Keine Nebenversionsupgrades")

Ausschlussablauffrist

Wenn ein Ausschluss abläuft (d. h. die aktuelle Zeit ist über die für den Ausschluss angegebene Endzeit hinausgegangen), verhindert dieser Ausschluss keine GKE-Aktualisierungen mehr. Andere gültige, nicht abgelaufene Ausschlüsse verhindern weiterhin die Aktualisierung von GKE.

Wenn keine Ausschlüsse mehr vorhanden sind, die Clusterupgrades verhindern, wird Ihr Cluster schrittweise auf die aktuelle Standardversion in der Release-Version des Clusters (oder den statischen Standardwert für Cluster ohne Release-Version) aktualisiert.

Wenn Ihr Cluster nach Ablauf der Ausnahmeregelung mehrere Nebenversionen hinter der aktuellen Standardversion zurückbleibt, plant GKE ein Nebenupgrade pro Monat (Aktualisierung sowohl der Cluster-Kontrollebene als auch der Knoten), bis Ihr Cluster die Standardversion für die Release-Version erreicht hat. Wenn Sie Ihren Cluster früher auf die Standardversion zurücksetzen möchten, können Sie manuelle Upgrades ausführen.

Einschränkungen bei der Konfiguration von Wartungsausschlüssen

Für Wartungsausschlüsse gelten die folgenden Einschränkungen:

  • Sie können den Umfang automatischer Upgrades in einem Wartungsausschluss nur für Cluster einschränken, die für eine Release-Version registriert sind. Bei Clustern, die nicht in einer Release-Version registriert sind, können Sie nur einen Wartungsausschluss mit dem Standardbereich „Keine Upgrades“ erstellen.
  • Sie können maximal drei Wartungsausschlüsse hinzufügen, die alle Upgrades ausschließen, also einen Bereich "Keine Upgrades". Diese Ausschlüsse müssen so konfiguriert sein, dass sie in einem rollierenden Zeitfenster von 32 Tagen mindestens 48 Stunden Wartungszeit zur Verfügung stehen.
  • Für jeden Cluster sind maximal 20 Wartungsausschlüsse möglich.
  • Wenn Sie in Ihrem Ausschluss keinen Bereich angeben, wird der Bereich standardmäßig auf „Keine Upgrades” eingestellt.
  • Sie können Wartungsausschlüsse auf verschiedene Zeiträume festlegen, je nach Bereich. Weitere Informationen finden Sie in der Zeile Dauer des Wartungsausschlusses im Abschnitt Wartungsausschluss konfigurieren.
  • Sie können einen Wartungsausschluss nicht so konfigurieren, dass er das Ende des Supports der Nebenversion, die der Registrierung des Clusters in der Release-Version entspricht, ein- oder überschreitet. Betrachten Sie die folgenden Beispiele:
    • In einem Cluster wird eine Nebenversion im Stable Channel ausgeführt. Im GKE-Releasezeitplan ist das Ende des Standardsupports für den 5. Juni 2025 angegeben. Sie müssen das Ende des Wartungsausschlusses auf den 2025-06-05T00:00:00Z oder früher festlegen.
    • Ein Cluster führt eine Nebenversion im Extended Channel aus, in der der GKE-Releasezeitplan das Ende des erweiterten Supports für den 5. April 2026 angibt. Sie müssen das Ende des Wartungsausschlusses auf den 2026-04-0500:00:00Z oder früher festlegen. Wenn Sie die Release-Version des Clusters in eine andere Version ändern möchten, müssen Sie das Enddatum des Wartungsausschlusses ändern, falls es das Ende des Standardsupports überschreitet. Weitere Informationen finden Sie unter Cluster über den Extended Channel ändern.

Beispiele für die Verwendung

Im Folgenden finden Sie einige Beispiele für Anwendungsfälle, bei denen der Umfang der möglichen Aktualisierungen eingeschränkt werden kann.

Beispiel: Einzelhändler bereitet sich auf die Festtage zum Jahresende vor

In diesem Beispiel möchte das Einzelhandelsunternehmen keine Unterbrechungen während der umsatzstärksten Zeit, d. h. an den vier Tagen zwischen dem Black Friday und dem Cyber Monday sowie im Dezember bis zum Beginn des neuen Jahres. Zur Vorbereitung auf die Shopping-Saison richtet der Clusteradministrator die folgenden Ausschlüsse ein:

  • Keine Nebenversionsupgrades: Patchupdates auf der Steuerungsebene und den Knoten sind nur zwischen dem 30. September und 15. Januar erlaubt.
  • Keine Upgrades: Alle Upgrades zwischen dem 19. November und dem 4. Dezember werden ausgesetzt.
  • Keine Upgrades: Alle Upgrades zwischen dem 15. Dezember und dem 5. Januar werden ausgesetzt.

Wenn nach Ablauf des Wartungsausschlusses keine anderen Ausschlussfenster gelten, wird der Cluster auf eine neue GKE-Nebenversion aktualisiert, wenn diese zwischen dem 30. September und dem 6. Januar verfügbar war.

Beispiel: Ein Unternehmen, das eine Beta API in Kubernetes verwendet, die entfernt wird

In diesem Beispiel verwendet ein Unternehmen die CustomResourceDefinition apiextensions.k8s.io/v1beta1 API, die in Version 1.22 entfernt wird. Während das Unternehmen Versionen vor 1.22 ausführt, richtet der Clusteradministrator den folgenden Ausschluss ein:

  • Keine Nebenversionsupgrades: Nebenversionsupgrades werden drei Monate lang ausgesetzt, während Sie Kundenanwendungen von apiextensions.k8s.io/v1beta1 zu apiextensions.k8s.io/v1 migrieren.

Beispiel: Die Legacy-Datenbank des Unternehmens ist nicht anfällig für Upgrades von Knotenpools

In diesem Beispiel führt ein Unternehmen eine Datenbank aus, die während der Aktualisierung eines Knotenpools nicht gut auf Pod-Bereinigungen und -Neuplanungen reagiert. Der Clusteradministrator richtet den folgenden Ausschluss ein:

  • Keine Nebenversions- oder Knotenupgrades: Knotenupgrades für drei Monate einfrieren. Wenn das Unternehmen bereit ist, Ausfallzeiten für die Datenbank zu akzeptieren, löst es ein manuelles Knotenupgrade aus.

Nächste Schritte