Knotenunterbrechungsrichtlinie in Azure Kubernetes Service (AKS) (Vorschau)

Während Sie Ihre AKS-Cluster verwalten und warten, erfordern bestimmte Konfigurationsänderungen, dass Knoten neu erstellt werden. Dieser Neuabbildungsvorgang löst ein Rolling Update aus, bei dem Knoten neu erstellt werden. Während eines Reimage-Vorgangs markiert AKS den Knoten als nicht für die Planung neuer Pods verfügbar, entfernt vorhandene Pods (indem sie unter Einhaltung der Pod Disruption Budgets von diesem Knoten entfernt und auf andere verfügbare Knoten neu geplant werden) und setzt den Knoten anschließend mit der aktualisierten Konfiguration neu auf. Bei diesem Vorgang handelt es sich um einen vollständigen Knotenneuerneuerungsvorgang, nicht um einen Neustart. Die zugrunde liegende VM wird mit einem neuen Betriebssystemimage umgestaltet. Während ordnungsgemäß konfigurierte persistente Volumes (mit Azure Disks, Azure Files oder anderem externen Speicher) nicht betroffen sind, gehen alle im lokalen temporären Speicher des Knotens gespeicherten Daten (z. B. EmptyDir-Volumes oder lokale Pfade) dauerhaft verloren. Diese Vorgänge sind erforderlich, um wichtige Updates anzuwenden, aber sie können die Ausführung von Workloads unterbrechen und die Anwendungsverfügbarkeit beeinträchtigen. Die Node-Unterbrechungsrichtlinie bietet Ihnen eine differenzierte Kontrolle darüber, wann diese störenden Vorgänge fortgesetzt werden dürfen, sodass Sie die Notwendigkeit von Updates mit betriebsbasierter Stabilität ausgleichen können.

Important

AKS-Preview-Funktionen stehen auf Selbstbedienungs- und Opt-in-Basis zur Verfügung. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Was ist die Richtlinie für Knotenunterbrechungen?

Die Knotenunterbrechungsrichtlinie ist eine Konfiguration auf Clusterebene, die steuert, wann Vorgänge ausgeführt werden können, die eine Neuimageerstellung und erneute Bereitstellung von Knoten erfordern. Es fungiert als Kontrolltor, sodass Sie:

  • Stimmen Sie unterbrechende Vorgänge auf Ihre Wartungsfenster ab.
  • Konfigurationsänderungen während kritischer Geschäftszeiten blockieren, während Node-Image-Upgrades und Sicherheitspatches weiterhin durchgeführt werden können.
  • Sorgen Sie bei hoher Auslastung für ein vorhersehbares Verhalten des Clusters.

Die Richtlinie gilt für vom Benutzer initiierte Konfigurationsänderungen, die eine Neuerstellung des Knotens erfordern, z. B. das Aktualisieren benutzerdefinierter Vertrauenszertifikate für Zertifizierungsstellen (CA), das Ändern von Einstellungen des Sicherheitsprofils oder das Ändern der Betriebssystemkonfiguration des Knotens.

Note

Wichtig ist, dass die Richtlinie keine Versionsupdates für Knotenimages (einschließlich SecurityPatch und NodeImage Upgradekanäle) oder Kubernetes-Versionsupgrades blockiert. Diese Vorgänge werden auch dann weiterhin gemäß ihren konfigurierten Zeitplänen ausgeführt, wenn die Richtlinie auf Block festgelegt ist. Ausführliche Informationen finden Sie unter Upgradevorgänge, die nicht durch die Richtlinie für Knotenunterbrechungen gesteuert werden. Darüber hinaus werden bestimmte Wiederherstellungsvorgänge nicht von dieser Richtlinie gesteuert, um den Clusterstatus und die Verfügbarkeit sicherzustellen. Ausführliche Informationen finden Sie unter Wiederherstellungsvorgänge, die nicht von der Node-Unterbrechungsrichtlinie gesteuert werden.

Funktionsweise der Knotenunterbrechungsrichtlinie

Sie konfigurieren die Knotenunterbrechungsrichtlinie auf Clusterebene über die nodeDisruptionProfile Eigenschaft. Wenn Sie versuchen, einen Vorgang auszuführen, der ein Neuimage eines Knotens erfordert, überprüft AKS die aktuelle Richtlinieneinstellung:

  • Richtlinienauswertung: AKS wertet aus, ob der Vorgang basierend auf der aktuellen Richtlinie zulässig ist.
  • Wartungsfensterüberprüfung (falls zutreffend): Bei Verwendung AllowDuringMaintenanceWindowüberprüft AKS, ob die aktuelle Uhrzeit im konfigurierten Wartungsfenster liegt.
  • Ausführung oder Blockierung des Vorgangs: Der Knoten-störende Vorgang wird fortgesetzt, wenn er zulässig ist oder mit einer Fehlermeldung abgelehnt wird, wenn dies blockiert ist.

Richtlinienoptionen

Die Knotenunterbrechungsrichtlinie unterstützt drei Richtlinienkonfigurationen:

Policy Description Anwendungsfall
Allow Ermöglicht, dass Vorgänge, die eine Neubereitstellung eines Knotens erfordern, jederzeit fortgesetzt werden können. Dies ist das Standardverhalten. Verwenden Sie diese Methode, wenn Sie das Anwenden von Updates schnell priorisieren möchten und Arbeitsauslastungsunterbrechungen tolerieren können.
AllowDuringMaintenanceWindow Blockiert Vorgänge, die eine Neuabbildung des Knotens erfordern, außer sie werden innerhalb des aksManagedNodeOSUpgradeSchedule Wartungsfensters ausgeführt. Verwenden Sie diese Funktion, wenn Sie Unterbrechungen auf bestimmte Wartungsfenster beschränken möchten, die ihrem Betriebsplan entsprechen.
Block Blockiert alle Vorgänge, für die ein Knotenumbild erforderlich ist. Verwenden Sie dies, wenn Sie Unterbrechungen von Knoten verhindern müssen, z. B. während geschäftskritischer Zeiträume oder stark frequentierter Ereignisse.

Note

Bei Verwendung AllowDuringMaintenanceWindowmüssen Sie ein aksManagedNodeOSUpgradeSchedule Wartungsfenster konfigurieren. Weitere Informationen zum Einrichten von Wartungsfenstern finden Sie unter Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades für Ihren Azure Kubernetes Service Cluster. Wenn Sie das Wartungsfenster nicht konfigurieren, sind die Knoten-disruptiven Vorgänge zulässig.

Considerations

Beachten Sie bei der Verwendung der Node-Unterbrechungsrichtlinie die folgenden Überlegungen:

Vorgänge, die von der Node-Unterbrechungsrichtlinie abgedeckt werden

Vorgänge auf Clusterebene

Aktivierung von Netzwerkrichtlinien und Upgrade von Azure CNI Overlay

Um die erforderlichen Netzwerkkomponenten zu installieren und Netzwerkregeln zu konfigurieren, die die Pod-zu-Pod-Kommunikation sichern und verwalten, müssen Sie die Knoten neu abbilden.

Die folgende Tabelle zeigt Upgrades von Netzwerkrichtlinien, die eine Neuabbildung auslösen:

Von To
Keine (keine Netzwerkrichtlinie) Azure Netzwerkrichtlinie
Keine (keine Netzwerkrichtlinie) Calico
Azure CNI Azure CNI-Überlagerung
Azure Netzwerkrichtlinie Keine (keine Netzwerkrichtlinie)
Calico Keine (keine Netzwerkrichtlinie)

Note

Das Wechseln zwischen Azure- und Calico-Netzwerkrichtlinien, nachdem bereits eine davon aktiviert wurde, erfordert keine Neuabbildung.

Änderungen am Node OS-Upgradekanal

Jeder Kanal verwendet eine andere Infrastruktur und Konfiguration für Betriebssystem-Patches, die Sie auf laufenden Knoten nicht ändern können.

Die folgende Tabelle zeigt Änderungen am Upgradekanal des Knotenbetriebssystems, die eine Neuabbildung auslösen:

Von To
Nicht verwaltet Nichts
Nicht angegeben. Nicht verwaltet
SecurityPatch Nicht verwaltet
NodeImage Nicht verwaltet
Nichts Nicht verwaltet
Nicht angegeben. Nicht verwaltet
Nicht verwaltet SecurityPatch
Nicht verwaltet NodeImage

IPv6 Dual-Stack-Aktivierung

Um die Dual-Stack-Kommunikation zu unterstützen, benötigen Knoten sowohl IPv4- als auch IPv6-IP-Konfigurationen und Netzwerkstapelupdates (z. B. nftables-Regeln).

Die folgende Tabelle zeigt Aktualisierungen der IP-Konfiguration und des Netzwerkstapels, die ein Re-Imaging auslösen:

Von To
Nur IPv4 IPv4 + IPv6 (Dual-Stack)

Änderungen der Cilium-Datenebene

Sie müssen eBPF-Programme installieren oder entfernen, die die Paketverarbeitung auf Kernelebene verarbeiten.

In der folgenden Tabelle werden Cilium-Datenebenenänderungen beschrieben, die eine Neuabbildung auslösen:

Von To
Nichts Cilium
Cilium Nichts

HTTP-Proxykonfigurationsupdates

Alle Knotenkomponenten (containerd, kubelet, Systemdienste) benötigen die aktualisierte Proxykonfiguration, die systemweit angewendet wurde. Wenn Sie die HTTP-Proxykonfiguration aktualisieren, erstellt AKS automatisch alle Knotenpools im Cluster neu.

Die Richtlinie für Node-Unterbrechungen löst eine Neuerstellung des Images aus, wenn Sie eine der folgenden Konfigurationseigenschaften des HTTP-Proxys ändern oder einen der folgenden Vorgänge ausführen:

  • httpProxy: Proxy-URL für HTTP-Verbindungen
  • httpsProxy: Proxy-URL für HTTPS-Verbindungen
  • noProxy: Liste der Ziele, die von der Proxyerstellung ausgeschlossen werden sollen
  • trustedCa: Base64-codiertes alternatives Zertifizierungsstellenzertifikat
  • Aktivieren des HTTP-Proxys in einem Cluster (mit --enable-http-proxy)
  • Deaktivieren des HTTP-Proxys auf einem Cluster (mit --disable-http-proxy)
  • HTTP-Proxy für einen Cluster wieder aktivieren, bei dem er zuvor deaktiviert war

Aktualisierungen für benutzerdefinierte CA-Zertifikate

Sie müssen neue Zertifizierungsstellenzertifikate im Vertrauensspeicher des Betriebssystems installieren, um die TLS-Validierung für interne Dienste und private Registrierungen zu beeinträchtigen.

Die Node-Störungsrichtlinie stößt eine Neuinstallation des Images an, wenn Sie benutzerdefinierte CA-Zertifikate hinzufügen, entfernen oder aktualisieren.

Kubelet-Identitätsänderungen

Sie müssen neue Identitätsanmeldeinformationen auf die Knotenkonfiguration anwenden. Dazu gehören anfängliche Identitätszuweisungen, Identitätsaktualisierungen und Dienstprinzipalprofilzurücksetzungen.

Die Knotenunterbrechungsrichtlinie löst eine Neuabbildung aus, wenn Sie eine verwaltete Identität oder eine benutzerzugewiesene verwaltete Identität für das Kubelet aktualisieren.

Privates DNS Zonenänderungen

Sie müssen die DNS-Resolvereinstellungen aktualisieren, um den Endpunkt des privaten API-Servers mithilfe der neuen DNS-Zone aufzulösen.

Die Node-Unterbrechungsrichtlinie löst eine Neuimage aus , wenn Sie eine private DNS-Zonenkonfiguration in einem privaten Cluster ändern.

API-Server-VNet-Integration aktivieren

Sie müssen die Knoten neu konfigurieren, um mit dem API-Server über die interne Lastenausgleichs-IP zu kommunizieren, die in das delegierte Subnetz projiziert wird.

Die Knotenunterbrechungsrichtlinie löst eine Neuabbildung aus, wenn Sie die API-Server-VNet-Integration in einem vorhandenen Cluster aktivieren, in dem diese zuvor nicht verwendet wurde. Diese Änderung entspricht dem Ändern der apiServerAccessProfile.enableVnetIntegration Eigenschaft (intern das privateConnectProfile.enabled Feld) von false (oder nicht festgelegt) in true:

Von To
apiServerAccessProfile.enableVnetIntegration: false oder nicht festgelegt apiServerAccessProfile.enableVnetIntegration: true

Änderungen des eBPF-Hostroutings

Sie müssen eBPF-Programme installieren oder entfernen, die eine leistungsfähige Paketweiterleitung (BpfVeth-Beschleunigungsmodus) bereitstellen.

In der folgenden Tabelle werden Änderungen des eBPF-Hostroutings beschrieben, die ein Erneutes Abbild auslösen:

Von To
Standardrouting eBPF-Hostrouting aktiviert
eBPF-Hostrouting aktiviert Standardweiterleitung

Vorgänge auf Knotenpoolebene

Diese Vorgänge wirken sich nur auf die spezifischen Knotenpools aus, in denen Sie Änderungen vornehmen. Sie lösen ein rollierendes Reimage innerhalb dieser Knotenpools aus:

Aktualisierungen des lokalen DNS-Profils

Sie müssen Änderungen an den DNS-Cachedaemon- und DNS-Weiterleitungsregeln auf Knotenebene anwenden.

Die Node-Unterbrechungsrichtlinie löst eine Neuimageerstellung aus, wenn Sie eine Konfiguration des LocalDNS-Profils ändern.

Sicherheitsänderungen bei Trusted Launch

Sie können die VM-Firmwarekonfiguration und die Startprozesseinstellungen für die Ausführung von virtuellen Computern nicht ändern. Für diese Änderungen müssen Sie die virtuellen Computer neu erstellen.

Die folgende Tabelle enthält Sicherheitsänderungen bei Trusted Launch, die eine Neuerstellung des Images auslösen:

Konfiguration Von To
vTPM (virtual Trusted Platform Module) Disabled Aktiviert
vTPM (virtual Trusted Platform Module) Aktiviert Disabled
Sicherer Start Disabled Aktiviert
Sicherer Start Aktiviert Disabled

Änderungen am Artefakt-Streaming

Sie müssen Komponenten für Artefakt-Streaming installieren oder entfernen, um ein schnelleres Herunterladen von Container-Images zu ermöglichen, indem Image-Layer bei Bedarf gestreamt werden.

In der folgenden Tabelle sind Änderungen am Artefakt-Streaming aufgeführt, die eine Neuerstellung des Images auslösen:

Von To
Disabled Aktiviert
Aktiviert Disabled

Aktualisierungen des Windows-GMSA-Profils (nur für Windows-Knotenpools)

Sie müssen neue GMSA-Einstellungen, DNS-Serverkonfiguration und Domänenbeitrittsanmeldeinformationen für Active Directory Integration auf die Windows Knoten anwenden.

Die Knotenunterbrechungsrichtlinie löst eine Neuimage der Windows Knotenpools aus, wenn eine GMSA-Änderung die Anwendung einer neuen Knotenkonfiguration erfordert:

Von To Löst die Neuinstallation aus
GMSA deaktiviert GMSA aktiviert Ja
GMSA aktiviert (DNS-Server / Stammdomäne festgelegt oder geändert) GMSA mit aktualisierter DNS-Server- oder Stammdomäne aktiviert Ja
GMSA aktiviert (DNS-Serversatz) GMSA deaktiviert Ja
GMSA aktiviert (kein DNS-Server festgelegt) GMSA deaktiviert Nein (keine zu übernehmende Knotenkonfiguration)

Anhang der Kapazitätsreservierungsgruppe

Sie müssen die zugrunde liegenden virtuellen Maschinen neu erstellen, damit sie aus der reservierten Kapazität in der Kapazitätsreservierungsgruppe (Capacity Reservation Group, CRG) bereitgestellt werden. Vorhandene Knoten wurden nicht für die CRG bereitgestellt, sodass AKS den Knotenpool neu abbilden muss, um sie der Reservierung zuzuordnen.

Die Richtlinie für Knotenunterbrechungen löst eine Neuerstellung des Images aus, wenn Sie einem vorhandenen Knotenpool, dem noch keine Kapazitätsreservierungsgruppe zugewiesen ist, eine Kapazitätsreservierungsgruppe zuweisen.

Von To Löst eine Neuinstallation des Images aus
Keine Kapazitätsreservierungsgruppe zugeordnet Kapazitätsreservierungsgruppe angefügt Ja

Vorgänge, die noch nicht von der Node-Unterbrechungsrichtlinie abgedeckt sind

Für die folgenden Konfigurationsänderungen ist eine Knotenreimage erforderlich, aber noch nicht von der Node-Unterbrechungsrichtlinie abgedeckt. Ein zukünftiges Kubernetes-Nebenversionsupdate behandelt diese Änderungen, da durch diese Änderung ein neues Verhalten eingeführt wird.
Nachdem Sie diese Konfigurationsänderungen vorgenommen haben, müssen Sie manuell ausführen az aks nodepool upgrade--node-image-only , um die Änderungen auf Ihre Knoten anzuwenden.

  • SSH-Konfigurationsänderungen: Ändern von SSH-Zugriffsmethoden (Deaktiviertes SSH, Entra ID basierendes SSH oder lokales Benutzer-SSH) oder Aktualisieren von öffentlichen SSH-Schlüsseln in Knotenpools.
  • Änderungen an der IMDS-Einschränkung: Aktivieren oder Deaktivieren der Einschränkung des Instance Metadata Service (IMDS), um den Pod-Zugriff auf den IMDS-Endpunkt zu blockieren.
  • Änderungen am Bootstrap-Profil: Ändern des Bootstrap-Profils, z. B. das Wechseln von artifactSource zwischen Direct und Cache oder das Ändern von containerRegistryId (die für netzwerkisolierte Cluster verwendete Azure Container Registry).
  • Änderungen des ausgehenden Typs: Ändern des ausgehenden Verbindungstyps des Clusters (loadBalancer, userDefinedRouting, managedNATGateway oder userAssignedNATGateway).

Upgradevorgänge, die nicht durch die Node-Unterbrechungsrichtlinie gesteuert werden

Die Knotenunterbrechungsrichtlinie steuert nicht die folgenden Upgradevorgänge. Diese Upgradevorgänge werden unabhängig von Ihrer Richtlinieneinstellung fortgesetzt. Upgrades werden entweder vom Kunden initiiert oder von AKS innerhalb geplanter Wartungsfenster initiiert. Damit diese Vorgänge wie geplant fortgesetzt werden können, behalten Sie sie absichtlich außerhalb des Bereichs der Node-Unterbrechungsrichtlinie. Wenn Vorgänge, die von der Node-Unterbrechungsrichtlinie abgedeckt werden, in denselben Konfigurationsänderungen mit Upgrades enthalten sind, werden sie nicht von der Node-Unterbrechungsrichtlinie gesteuert.

  • Updates der Knotenimageversion: Aktualisierung auf eine neue Knoten-Betriebssystemimageversion (manuell oder über automatische Upgradekanäle). Dieser Vorgang ist der am häufigsten verwendete Reimage-Vorgang und umfasst Sicherheitspatches, Betriebssystemupdates und AKS-Knotenimageversionen.
  • Kubernetes-Versionsupgrades: Aktualisieren der Kubernetes-Version auf einem Knotenpool, die neue Kubernetes-Binärdateien, aktualisierte Kubelet-Konfiguration und Änderungen auf Betriebssystemebene anwendet.

Wiederherstellungsvorgänge, die nicht der Knotenunterbrechungsrichtlinie unterliegen

Die Knotenunterbrechungsrichtlinie steuert nicht die folgenden automatisierten Wiederherstellungsvorgänge. Diese Vorgänge können unabhängig von Ihrer Richtlinieneinstellung auftreten, um die Clusterintegrität und -wiederherstellung sicherzustellen.

  • Rollback der Knotenpoolkonfiguration: Wenn die Aktualisierung eines Knotenpools aufgrund einer ungültigen Konfiguration oder von Infrastrukturproblemen fehlschlägt, setzt AKS automatisch auf den letzten bekannten funktionsfähigen Zustand zurück und stellt die Knoten per Reimaging wieder her, um die Konfiguration zurückzusetzen.
  • Wiederherstellungsvorgänge des Verwaltungsclusters: Wenn Azure-Supporttechniker im Rahmen der Vorfallbehebung administrative Wiederherstellungen des Clusters durchführen, werden Knoten neu aufgesetzt, um die Konsistenz zwischen dem Status der Steuerungsebene und der Knotenkonfiguration sicherzustellen.
  • Aktualisierungen von Knotenidentitätsanmeldeinformationen: AKS aktualisiert regelmäßig Knotenidentitätsanmeldeinformationen für Sicherheit und Compliance. Diese vom System initiierten Updates lösen Knotenneuimages aus, um die neuen Anmeldeinformationen auf alle Knotenpools anzuwenden.

Integration mit geplanter Wartung

Die Node-Unterbrechungsrichtlinie funktioniert nahtlos mit geplanten Wartungsfenstern von AKS . Wenn Sie die Richtlinie auf AllowDuringMaintenanceWindow festlegen, sind störende Vorgänge auf Ihr aksManagedNodeOSUpgradeSchedule Wartungsfenster abgestimmt, wodurch sichergestellt wird, dass:

  • Änderungen treten nur während genehmigter Zeitfenster auf.
  • Vorgänge koordinieren sich mit anderen geplanten Wartungen.
  • Teams sind sich bewusst, wann Unterbrechungen auftreten können.

Diese Integration bietet einen umfassenden Ansatz zum Verwalten von Clusteränderungen und zur Minimierung der Auswirkungen auf ausgeführte Workloads.

Note

Bei Verwendung AllowDuringMaintenanceWindowmüssen Sie ein aksManagedNodeOSUpgradeSchedule Wartungsfenster konfigurieren. Die Verwendung des default Wartungsfensters oder aksManagedAutoUpgradeSchedule (automatisches Clusterupgrade) erfüllt diese Anforderung nicht. Wenn Sie AllowDuringMaintenanceWindow festlegen, ohne dass ein aksManagedNodeOSUpgradeSchedule-Fenster konfiguriert ist, sind alle störenden Vorgänge zulässig (die Richtlinie hat kein Fenster, durch das sie eingeschränkt werden könnten). Weitere Informationen zum Einrichten von Wartungsfenstern finden Sie unter Verwenden der geplanten Wartung zum Planen und Steuern von Upgrades für Ihren Azure Kubernetes Service Cluster.

Bewährte Methoden

Beachten Sie bei der Implementierung der Node-Unterbrechungsrichtlinie die folgenden Empfehlungen:

  • Verwendung für die Produktion: Kombinieren Sie AllowDuringMaintenanceWindowmit geplanten Wartungsfenstern, um zu steuern, wann Unterbrechungen in Produktionsumgebungen auftreten.
  • Während kritischer Zeiträume festgelegtBlock: Vorübergehende Blockierung störender Vorgänge bei Ereignissen mit hohem Datenverkehr, Produktstarts oder Vorfallreaktionen. Verwenden Sie nicht Block unbegrenzt. Block eignet sich für kurzfristige Einfrierungen (geplante Ereignisse, Reaktionen auf Vorfälle).
  • Flexibilität in Nichtproduktion zulassen: Verwendung Allow in Entwicklungs- und Testumgebungen, in denen schnelle Iteration wichtiger als Stabilität ist.
  • Richtlinienänderungen kommunizieren: Stellen Sie sicher, dass Ihr Team die aktuelle Richtlinie versteht und weiß, wann Vorgänge möglicherweise blockiert werden.
  • Planen Sie Wartungsfenster angemessen: Bemessen Sie Ihre Wartungsfenster so, dass sie die erforderlichen Arbeiten abdecken.
  • Testen des Richtlinienverhaltens: Überprüfen von Richtlinieneinstellungen in Nicht-Produktionsumgebungen, bevor sie auf Produktionscluster angewendet werden.
  • Überwachen Sie blockierte Vorgänge: Verfolgen Sie, wann Vorgänge blockiert werden, um Ihren Wartungszeitplan zu optimieren.

Verwandte Inhalte

  • Last updated on