Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades für Ihren Azure Kubernetes Service-Cluster

Dieser Artikel zeigt, wie Sie die geplante Wartung verwenden, um Cluster- und Knotenimageupgrades in Azure Kubernetes Service (AKS) zu planen und zu steuern.

Regelmäßige Wartung wird auf Ihrem AKS-Cluster automatisch durchgeführt. Es gibt zwei Arten von Wartungsvorgängen:

• Die von AKS initiierte Wartung umfasst die wöchentlichen Releases, die AKS ausführt, um Ihren Cluster mit den neuesten Features und Fixes auf dem neuesten Stand zu halten.
• Die benutzerseitig initiierte Wartung umfasst automatische Clusterupgrades und automatische Sicherheitsupdates des Knotenbetriebssystems.

Wenn Sie die Funktion der geplanten Wartung in AKS verwenden, können Sie beide Arten der Wartung in einem Rhythmus Ihrer Wahl ausführen, um die Auswirkungen auf die Arbeitsauslastung zu minimieren. Sie können die geplante Wartung verwenden, um den Zeitpunkt der automatischen Upgrades zu planen. Das Aktivieren oder Deaktivieren der geplanten Wartung aktiviert oder deaktiviert jedoch keine automatischen Upgrades.

Voraussetzungen

• Es wird vorausgesetzt, dass Sie über ein AKS-Cluster verfügen. Wenn Sie keinen AKS-Cluster haben, lesen Sie Erstellen eines AKS-Clusters.
• Wenn Sie die Azure-Befehlszeilenschnittstelle verwenden, führen Sie ein Upgrade auf die neueste Version mithilfe des az upgrade-Befehls durch.

Überlegungen

Wenn Sie die geplante Wartung verwenden, gelten die folgenden Überlegungen:

• AKS behält sich vor, geplante Wartungsfenster für ungeplante, reaktive Wartungsvorgänge zu unterbrechen, die dringend oder kritisch sind. Diese Wartungsvorgänge können sogar während der in Ihrer Konfiguration definierten notAllowedTime- oder notAllowedDates-Zeiträume ausgeführt werden.
• Wartungsarbeiten werden nur nach bestem Wissen und Gewissen durchgeführt und es wird nicht garantiert, dass sie innerhalb eines bestimmten Zeitraums stattfinden.

Planen von Konfigurationstypen für geplante Wartung

Für die geplante Wartung stehen drei Planungskonfigurationstypen zur Verfügung:

• default ist eine grundlegende Konfiguration für die Steuerung von AKS-Versionen. Aufgrund der sicheren Bereitstellungspraktiken von Azure kann es ab der ersten Auslieferung bis zu zwei Wochen dauern, bis die Versionen in allen Regionen verfügbar sind.

  Wählen Sie default aus, um diese Updates so zu planen, dass sie für Sie am wenigsten störend sind. Sie können den Status eines laufenden AKS-Releases nach Region im wöchentlichen Releasetracker überwachen.

• aksManagedAutoUpgradeSchedule steuert, wann Upgrades ausgeführt werden, die von Ihrem angegebenen Kanal für automatische Upgrades geplant wurden. Sie können mit dieser Konfiguration den Rhythmus und die Wiederholungen feiner steuern als mit der default-Konfiguration. Weitere Informationen zum automatischen Clusterupgrade finden Sie unter Automatisches Upgraden eines Azure Kubernetes Service-Clusters.

• aksManagedNodeOSUpgradeSchedule steuert, wann Sicherheitspatches des Knotenbetriebssystems durchgeführt werden, die vom automatisches Upgradekanal Ihres Knotenbetriebssystems geplant werden. Sie können mit dieser Konfiguration den Rhythmus und die Wiederholungen feiner steuern als mit der default-Konfiguration. Weitere Informationen zu automatischen Upgradekanälen des Knotenbetriebssystems finden Sie unter Automatisches Patchen und Aktualisieren von AKS-Clusterknotenimages.

Es wird empfohlen, aksManagedAutoUpgradeSchedule für alle Clusterupgrades und aksManagedNodeOSUpgradeSchedule für alle Sicherheitspatches des Betriebssystems zu verwenden.

Option default ist ausschließlich für wöchentliche AKS-Releases vorgesehen. Sie können die default-Konfiguration auf die aksManagedAutoUpgradeSchedule- oder aksManagedNodeOSUpgradeSchedule-Konfigurationen umstellen, indem Sie den Befehl az aks maintenanceconfiguration update verwenden.

Erstellen eines Wartungsfensters

Geplante Wartungsfenster werden in koordinierter Weltzeit (Coordinated Universal Time, UTC) angegeben.

Ein default Wartungsfenster verfügt über die folgenden Legacyeigenschaften (nicht mehr empfohlen):

Ein aksManagedAutoUpgradeSchedule oder aksManagedNodeOSUpgradeSchedule Wartungsfenster und default Konfiguration ab 2023-05-01 API-Version hat die folgenden Eigenschaften:

Zeitplantypen

Vier verfügbare Zeitplantypen sind verfügbar: Daily, Weekly, AbsoluteMonthly und RelativeMonthly.

Weekly-, AbsoluteMonthly- und RelativeMonthly-Zeitplantypen gelten nur für aksManagedClusterAutoUpgradeSchedule- und aksManagedNodeOSUpgradeSchedule-Konfigurationen. Daily-Zeitpläne gelten nur für aksManagedNodeOSUpgradeSchedule-Konfigurationen.

Alle Felder, die für jeden Zeitplantyp angezeigt werden, sind erforderlich.

Ein möglicher Daily-Zeitplan könnte so aussehen: „alle drei Tage“:

"schedule": {
    "daily": {
        "intervalDays": 3
    }
}

Ein möglicher Weekly-Zeitplan könnte so aussehen: „alle zwei Wochen am Freitag“:

"schedule": {
    "weekly": {
        "intervalWeeks": 2,
        "dayOfWeek": "Friday"
    }
}

Ein möglicher AbsoluteMonthly-Zeitplan könnte so aussehen: „alle drei Monate am ersten Tag des Monats“:

"schedule": {
    "absoluteMonthly": {
        "intervalMonths": 3,
        "dayOfMonth": 1
    }
}

Ein möglicher RelativeMonthly-Zeitplan könnte so aussehen: „alle zwei Monate am letzten Montag“:

"schedule": {
    "relativeMonthly": {
        "intervalMonths": 2,
        "dayOfWeek": "Monday",
        "weekIndex": "Last"
    }
}

Gültige Werte für weekIndex sind First, Second, Third, Fourth und Last.

Hinzufügen einer Konfiguration für das Wartungsfenster

# Add a new default configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 1

# Add a new aksManagedAutoUpgradeSchedule configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule --schedule-type Weekly --day-of-week Friday --interval-weeks 3 --duration 8 --utc-offset +05:30 --start-time 00:00

Aktualisieren eines vorhandenen Wartungsfensters

az aks maintenanceconfiguration update --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 2

Auflisten aller Wartungsfenster in einem vorhandenen Cluster

Listen Sie die aktuellen Wartungskonfigurationsfenster in Ihrem AKS-Cluster mithilfe des az aks maintenanceconfiguration list-Parameters auf:

az aks maintenanceconfiguration list --resource-group myResourceGroup --cluster-name myAKSCluster

Anzeigen eines bestimmten Wartungsfensters in einem vorhandenen Cluster

Zeigen Sie ein bestimmtes Wartungsfenster in Ihrem AKS-Cluster mithilfe des Befehls az aks maintenanceconfiguration show mit dem --name-Parameter an:

az aks maintenanceconfiguration show --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule

Die folgende Beispielausgabe zeigt das Wartungsfenster für aksManagedAutoUpgradeSchedule:

{
  "id": "/subscriptions/<subscription>/resourceGroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster/maintenanceConfigurations/aksManagedAutoUpgradeSchedule",
  "maintenanceWindow": {
    "durationHours": 4,
    "notAllowedDates": [
      {
        "end": "2024-01-05",
        "start": "2023-12-23"
      }
    ],
    "schedule": {
      "absoluteMonthly": {
        "dayOfMonth": 1,
        "intervalMonths": 3
      },
      "daily": null,
      "relativeMonthly": null,
      "weekly": null
    },
    "startDate": "2023-01-20",
    "startTime": "09:00",
    "utcOffset": "-08:00"
  },
  "name": "aksManagedAutoUpgradeSchedule",
  "notAllowedTime": null,
  "resourceGroup": "myResourceGroup",
  "systemData": null,
  "timeInWeek": null,
  "type": null
}

Löschen eines Wartungsfensters in einem vorhandenen Cluster

az aks maintenanceconfiguration delete --resource-group myResourceGroup --cluster-name myAKSCluster --name autoUpgradeSchedule

az aks maintenanceconfiguration delete --resource-group myResourceGroup --cluster-name myAKSCluster --name autoUpgradeSchedule

Häufig gestellte Fragen

• Wie kann ich die bestehenden Wartungskonfigurationen in meinem Cluster überprüfen?

  Verwenden Sie den Befehl az aks maintenanceconfiguration show.

• Kann eine reaktive, ungeplante Wartung auch in den notAllowedTime- oder notAllowedDates-Zeiträumen erfolgen?

  Ja. AKS behält sich vor, diese Fenster für ungeplante, reaktive Wartungsvorgänge zu unterbrechen, falls diese dringend oder kritisch sind.

• Wie kann ich feststellen, ob ein Wartungsereignis aufgetreten ist?

  Überprüfen Sie für Releases die Region Ihres Clusters, und suchen Sie nach Informationen in wöchentliche Releases, um festzustellen, ob dies Ihrem Wartungszeitplan entspricht. Um den Status Ihrer automatischen Upgrades anzuzeigen, überprüfen Sie die Aktivitätsprotokolle in Ihrem Cluster. Sie können auch nach bestimmten Ereignissen im Zusammenhang mit Upgrades suchen, wie unter Upgraden eines AKS-Clusters beschrieben.

  AKS gibt auch Azure Event Grid-Ereignisse im Zusammenhang mit Upgrades aus. Weitere Informationen finden Sie unter AKS als Event Grid-Quelle.

• Kann ich mehr als eine Wartungskonfiguration gleichzeitig verwenden?

  Ja, Sie können alle drei Konfigurationen gleichzeitig ausführen: default, aksManagedAutoUpgradeSchedule und aksManagedNodeOSUpgradeSchedule. Wenn sich die Fenster überschneiden, entscheidet AKS über die Ausführungsreihenfolge.

• Ich habe ein Wartungsfenster konfiguriert, aber das Upgrade wurde nicht durchgeführt. Warum?

  Das automatische AKS-Upgrade benötigt eine bestimmte Zeitspanne, in der Regel nicht mehr als 15 Minuten, um das Wartungsfenster zu berücksichtigen. Wir empfehlen mindestens 15 Minuten zwischen der Erstellung oder Aktualisierung einer Wartungskonfiguration und der geplanten Startzeit.

  Stellen Sie außerdem sicher, dass Ihr Cluster gestartet ist, wenn das geplante Wartungsfenster beginnt. Wenn der Cluster gestoppt ist, wird seine Steuerungsebene freigegeben, und es können keine Vorgänge ausgeführt werden.

• Warum wurde für einen meiner Agentpools ein Upgrade außerhalb des Wartungsfensters durchgeführt?

  Wenn für einen Agentpool kein Upgrade ausgeführt wurde (z. B. weil Pod-Unterbrechungsbudgets dies verhindert haben), kann später außerhalb des Wartungsfensters ein Upgrade durchgeführt werden. Dieses Szenario wird als „Upgrade nachholen“ bezeichnet. Dies verhindert, dass für Agentenpools ein Upgrade mit einer anderen Version als derjenigen der AKS-Steuerungsebene durchgeführt werden kann.

  Ein weiterer Grund, warum ein Agentpool unerwartet aktualisiert werden konnte, besteht darin, dass keine definierte Wartungskonfiguration vorhanden ist oder ob er gelöscht wurde. In diesem Fall wird ein Cluster mit automatischem Upgrade , aber ohne Wartungskonfiguration zu zufälligen Zeiten (Fallbackzeitplan) aktualisiert, was ein unerwünschter Zeitrahmen sein kann.

• Gibt es bewährte Methoden für die Wartungskonfigurationen?

  Wir empfehlen, den Zeitplan für Sicherheitsupdates des Knotenbetriebssystems auf einen wöchentlichen Rhythmus festzulegen, wenn Sie den NodeImage-Kanal verwenden, da jedes Jahr ein neues Knotenimage ausgeliefert wird. Sie können sich auch den SecurityPatch-Kanal abonnieren, um tägliche Sicherheitsupdates zu erhalten.

  Legen Sie den Zeitplan für automatische Upgrades auf einen monatlichen Rhythmus fest, um mit der Kubernetes N-2-Supportrichtlinie aktuell zu bleiben.

  Eine ausführliche Erläuterung zu bewährten Methoden für Upgrades und anderen Überlegungen finden Sie unter AKS Patch- und Upgradeanleitungen.

• Kann ich alle meine Cluster in einem einzigen Abonnement konfigurieren, sodass die gleiche Wartungskonfiguration verwendet wird?

  Es wird nicht empfohlen, dieselbe Wartungskonfiguration für mehrere Cluster in einem einzigen Abonnement zu verwenden, da dies zu ARM-Drosselungsfehlern führen kann, die dazu führen, dass Clusterupgrades fehlschlagen. Stattdessen wird empfohlen, die Wartungsfenster für jedes Cluster zu verwerfen, um diese Fehler zu vermeiden.

Nächste Schritte

• Die ersten Schritte beim Upgraden Ihres AKS-Clusters sind unter Upgradeoptionen für AKS-Cluster beschrieben.