Zásady přerušení uzlu v Azure Kubernetes Service (AKS) (Preview)

Při správě a údržbě clusterů AKS některé změny konfigurace vyžadují znovuvytvoření image uzlů. Tato operace opětovného vytvoření spustí průběžnou aktualizaci, která znovu vytvoří uzly. Během operace opětovného vytvoření vyprázdní AKS uzel (zabrání plánování nových podů), vyprázdní stávající pody (vyřazuje je a znovu plánuje na jiných dostupných uzlech při zachování rozpočtů přerušení podů) a pak znovu vytvoří uzel s aktualizovanou konfigurací. Tento proces představuje úplné znovuvytvoření uzlu, nikoli restart – podkladový virtuální počítač je znovu vytvořen pomocí nového obrazu operačního systému. I když správně nakonfigurované trvalé svazky (využívající Azure Disks, Azure Files nebo jiné externí úložiště) nejsou ovlivněny, veškerá data uložená v místním dočasném úložišti uzlu (například ve svazcích EmptyDir nebo v místních cestách) jsou trvale ztracena. Tyto operace jsou nezbytné k instalaci důležitých aktualizací, ale mohou narušit spouštění úloh a ovlivnit dostupnost aplikace. Zásady přerušení uzlu umožňují jemně odstupňovanou kontrolu nad tím, kdy tyto rušivé operace můžou pokračovat a pomáhají vyvážit potřebu aktualizací s provozní stabilitou.

Important

Funkce AKS ve verzi Preview jsou k dispozici na bázi samoobsluhy a dobrovolného přihlášení. Ukázky jsou poskytovány "tak, jak jsou" a "dle dostupnosti" a jsou vyloučeny ze smluv o úrovni služeb a z omezené záruky. Předběžné verze AKS jsou částečně pokryty zákaznickou podporou podle možností. Proto tyto funkce nejsou určené pro produkční použití. Další informace najdete v následujících článcích podpory:

Co jsou zásady přerušení uzlu?

Zásady přerušení uzlu jsou konfigurace na úrovni clusteru, která určuje, kdy se dá spustit operace vyžadující opětovné sestavení uzlu a opětovné nasazení. Funguje jako řídicí brána, která umožňuje:

  • Sladění rušivých operací s časovými obdobími údržby
  • Zablokujte změny konfigurace během kritických obchodních období a současně umožněte provádět aktualizace bitových kopií uzlů a instalaci bezpečnostních oprav.
  • Udržujte předvídatelné chování clusteru během událostí s vysokým provozem.

Tato zásada se vztahuje na změny konfigurace iniciované uživatelem, které vyžadují opětovné vytvoření uzlu, jako je aktualizace certifikátů důvěryhodnosti vlastní certifikační autority (CA), úprava nastavení profilu zabezpečení nebo změna konfigurace operačního systému uzlu.

Note

Důležité je, že zásada neblokuje aktualizace verzí imagí uzlů (včetně kanálů upgradu SecurityPatch a NodeImage) ani aktualizace verzí Kubernetes. Tyto operace budou pokračovat podle nakonfigurovaných plánů i v případě, že je zásada nastavená na Block. Podrobnosti najdete v tématu Operace upgradu, které nejsou řízeny zásadami přerušení uzlů. Kromě toho některé operace obnovení nejsou touto zásadou řízeny, aby se zajistil stav a dostupnost clusteru. Podrobnosti najdete v tématu Operace obnovení, které nejsou řízeny zásadami přerušení uzlů.

Jak fungují zásady přerušení uzlu

Zásady přerušení uzlů nakonfigurujete na úrovni clusteru nodeDisruptionProfile prostřednictvím vlastnosti. Když se pokusíte provést operaci, která vyžaduje opětovné vytvoření bitové kopie uzlu, AKS zkontroluje aktuální nastavení zásady:

  • Vyhodnocení zásad: AKS vyhodnotí, jestli je operace povolená na základě aktuální zásady.
  • Kontrola časového období údržby (pokud je k dispozici): Pokud používáte AllowDuringMaintenanceWindow, AKS ověří, jestli aktuální čas spadá do nakonfigurovaného časového období údržby.
  • Provádění operací nebo blokování: Operace narušování uzlu pokračuje, pokud je povolená nebo odmítnuta s chybovou zprávou, pokud je blokována.

Možnosti zásad

Zásady přerušení uzlu podporují tři konfigurace zásad:

Policy Description Případ použití
Allow Umožňuje, aby operace vyžadující přeimageování uzlu proběhly kdykoli. Toto je výchozí chování. Použijte, když chcete upřednostnit rychlé aplikování aktualizací a tolerovat přerušení úloh.
AllowDuringMaintenanceWindow Blokuje operace, které vyžadují přeinstalaci uzlu, pokud neproběhnou v rámci aksManagedNodeOSUpgradeSchedule okna údržby. Konfigurace může používat vložený plán nebo odkaz na sdílené okno údržby. Použijte, když chcete omezit přerušení na konkrétní časová období údržby, která odpovídají vašemu provoznímu plánu.
Block Blokuje všechny operace, které vyžadují obnovení image uzlu. Použijte, když potřebujete zabránit přerušení uzlů, například během důležitých obchodních období nebo událostí s vysokým provozem.

Note

Při použití AllowDuringMaintenanceWindowje nutné nakonfigurovat aksManagedNodeOSUpgradeSchedule časové období údržby. Konfigurace údržby může definovat plán přímo nebo odkazovat na sdílené okno údržby. Další informace o nastavení časových období údržby najdete v tématu Plánování a řízení upgradů pro cluster Azure Kubernetes Service. Pokud nenakonfigurujete okno údržby, budou povoleny operace narušující činnost uzlu.

Considerations

Při používání zásad přerušení uzlů mějte na paměti následující skutečnosti:

  • Obor: Zásada se vztahuje na operace iniciované uživatelem, které vyžadují opětovné vytvoření uzlu, nikoli na údržbu systému iniciovanou službou AKS. Podrobnosti najdete v tématu Operace obnovení, které nejsou řízeny zásadami přerušení uzlů.
  • Blokované operace: Pokud dojde k zablokování rušivé operace, volání rozhraní API selže s chybovou zprávou. Musíte buď změnit zásady, nebo počkat na okno údržby.
  • Tísňová údržba: Azure si vyhrazuje právo provádět naléhavé nebo kritické operace údržby bez ohledu na nastavení zásad.
  • Plánování aktualizací: Nastavení zásad tak, aby Block zabránilo určitým aktualizacím clusteru. Podrobnosti najdete v tématu Operace, na které se vztahují zásady přerušení uzlů. Naplánujte podle toho, abyste měli jistotu, že v případě potřeby budete moct použít potřebné aktualizace.
  • Závislost na okně údržby: Zásada AllowDuringMaintenanceWindow vyžaduje, aby bylo aksManagedNodeOSUpgradeSchedule nakonfigurováno okno údržby. Podrobnosti najdete v tématu Plánování a řízení upgradů clusteru Azure Kubernetes Service pomocí plánované údržby.

Operace, na které se vztahují zásady přerušení uzlů

Operace na úrovni clusteru

Povolení síťových zásad a aktualizace Azure CNI Overlay

Pokud chcete nainstalovat požadované síťové komponenty a nakonfigurovat pravidla sítě, která zabezpečují a spravují komunikaci mezi pody, musíte uzly znovu vytvořit.

Následující tabulka uvádí aktualizace síťových zásad, které vyžadují přeinstalaci bitové kopie:

Od To
Žádné (žádné zásady sítě) zásady sítě Azure
Žádné (žádné zásady sítě) Calico
Azure CNI Azure CNI překryvná vrstva
zásady sítě Azure Žádné (žádné zásady sítě)
Calico Žádné (žádné zásady sítě)

Note

Přepnutí mezi síťovými zásadami Azure a Calico nevyžaduje přeimageování, ani když už jsou jedny z nich povolené.

Změny kanálu upgradu operačního systému uzlu

Každý kanál používá jinou infrastrukturu a konfiguraci oprav operačního systému, kterou nemůžete upravovat na spuštěných uzlech.

Následující tabulka popisuje změny kanálu upgradu operačního systému uzlu, které aktivují opětovné vytvoření image:

Od To
Neřízené None
Nespecifikovaný Neřízené
SecurityPatch Neřízené
NodeImage Neřízené
None Neřízené
Nespecifikovaný Neřízené
Neřízené SecurityPatch
Neřízené NodeImage

Povolení protokolu IPv6 v režimu dual-stack

Aby bylo možné podporovat komunikaci v režimu dual-stack, musí mít uzly konfiguraci IPv4 i IPv6 a aktualizace síťového zásobníku (například pravidel nftables).

Následující tabulka popisuje konfiguraci IP a aktualizace síťového zásobníku, které spouštějí opětovné vytvoření bitové kopie:

Od To
Jenom protokol IPv4 IPv4 + IPv6 (duální stack)

Změny datové roviny Cilium

Potřebujete nainstalovat nebo odebrat programy eBPF, které zpracovávají zpracování paketů na úrovni jádra.

Následující tabulka uvádí změny datové roviny Cilium, které vyžadují reimaging:

Od To
None Cilium
Cilium None

Aktualizace konfigurace proxy serveru HTTP

Všechny komponenty uzlu (kontejner, kubelet, systémové služby) potřebují aktualizovanou konfiguraci proxy serveru použitou v celém systému. Když aktualizujete konfiguraci proxy serveru HTTP, AKS automaticky znovu vytvoří všechny fondy uzlů v clusteru.

Zásada narušení uzlu spustí opětovné vytvoření bitové kopie, když upravíte některou z následujících konfiguračních vlastností proxy serveru HTTP nebo provedete některou z následujících operací:

  • httpProxy: Adresa URL proxy serveru pro připojení HTTP
  • httpsProxy: Adresa URL proxy serveru pro připojení HTTPS
  • noProxy: Seznam cílů, které se mají vyloučit z použití proxy serveru
  • trustedCa: Alternativní certifikát certifikační autority zakódovaný v kódování Base64
  • Povolení proxy serveru HTTP v clusteru (s --enable-http-proxy)
  • Zakázání proxy serveru HTTP v clusteru (s --disable-http-proxy)
  • Opětovné povolení proxy serveru HTTP v clusteru, který ho dříve zakázal

Aktualizace vlastních certifikátů certifikační autority

Abyste mohli ovlivnit ověřování protokolu TLS pro interní služby a privátní registry, musíte do úložiště důvěryhodnosti operačního systému nainstalovat nové certifikáty certifikační autority.

Zásada narušení uzlu spustí opětovné vytvoření bitové kopie při přidání, odebrání nebo aktualizaci vlastních certifikátů CA.

Změny identity Kubeletu

Pro konfiguraci uzlu musíte použít nové přihlašovací údaje identity. To zahrnuje prvotní přiřazení identity, aktualizace identity a resetování profilu instančního objektu služby.

Zásady narušení uzlu vyvolají opětovné vytvoření bitové kopie při aktualizaci spravované identity nebo uživatelem přiřazené spravované identity pro kubelet.

Změny privátní zóny DNS

Abyste mohli přeložit koncový bod serveru privátního rozhraní API pomocí nové zóny DNS, musíte aktualizovat nastavení překladače DNS.

Zásada narušení uzlu spustí přeimageování při úpravě konfigurace privátní zóny DNS v privátním clusteru.

Povolení integrace API Serveru se sítí VNet

Uzly musíte překonfigurovat tak, aby komunikovaly se serverem rozhraní API prostřednictvím interní IP adresy nástroje pro vyrovnávání zatížení, která je promítaná do delegované podsítě.

Zásada narušení uzlu spustí opětovné vytvoření bitové kopie, když v existujícím clusteru povolíte integraci virtuální sítě serveru API, která se v něm dříve nepoužívala. Tato změna odpovídá změně vlastnosti apiServerAccessProfile.enableVnetIntegration (interně pole privateConnectProfile.enabled) z false (nebo nenastaveno) na true:

Od To
apiServerAccessProfile.enableVnetIntegration: false nebo nenastaveno apiServerAccessProfile.enableVnetIntegration: true

Změny směrování hostitelů eBPF

Potřebujete nainstalovat nebo odebrat programy eBPF, které poskytují vysoce výkonné předávání paketů (režim zrychlení BpfVeth).

Následující tabulka uvádí změny směrování eBPF na hostiteli, které vyžadují přeimageování:

Od To
Standardní směrování Na hostiteli je povoleno směrování eBPF
Na hostiteli je povoleno směrování eBPF Standardní směrování

Operace na úrovni fondu uzlů

Tyto operace ovlivňují pouze konkrétní fondy uzlů, ve kterých provedete změny. Spustí postupné přeinstalování bitové kopie v těchto fondech uzlů:

Aktualizace místního profilu DNS

Je potřeba provést změny démona pro ukládání DNS do mezipaměti a pravidel předávání DNS na úrovni uzlu.

Zásada narušení uzlu při úpravě konfigurace profilu LocalDNS spustí nové vytvoření bitové kopie.

Změny zabezpečení funkce Trusted Launch

Na spuštěných virtuálních počítačích nemůžete změnit konfiguraci firmwaru virtuálního počítače a nastavení procesu spouštění. Tyto změny vyžadují opětovné vytvoření virtuálních počítačů.

Následující tabulka uvádí změny zabezpečení Trusted Launch, které vedou k novému vytvoření bitové kopie:

Konfigurace Od To
vTPM (virtual Trusted Platform Module) Disabled Povoleno
vTPM (virtual Trusted Platform Module) Povoleno Disabled
Zabezpečené spouštění Disabled Povoleno
Zabezpečené spouštění Povoleno Disabled

Streamování artefaktů – změny

Chcete-li povolit rychlejší stahování imagí kontejnerů pomocí streamování vrstev imagí na vyžádání, musíte nainstalovat nebo odebrat komponenty pro streamování artefaktů.

Následující tabulka uvádí změny ve streamování artefaktů, které vyvolávají reimaging:

Od To
Disabled Povoleno
Povoleno Disabled

Aktualizace profilu Windows GMSA (pouze pro fondy uzlů Windows)

Pro služba Active Directory integraci na uzlech Windows musíte použít nová nastavení GMSA, konfiguraci serveru DNS a přihlašovací údaje pro připojení k doméně.

Zásady narušení uzlu spustí opětovné vytvoření bitové kopie fondů uzlů Windows, když změna GMSA vyžaduje použití nové konfigurace uzlu:

Od To Spustí nové vytvoření bitové kopie
GMSA zakázáno GMSA je povoleno Yes
GMSA povoleno (server DNS / kořenová doména byly nastaveny nebo změněny) GmSA povoleno s aktualizovaným serverem DNS nebo kořenovou doménou Yes
GMSA povoleno (server DNS nastaven) GMSA zakázáno Yes
Povolená služba GMSA (bez nastavení serveru DNS) GMSA zakázáno Ne (nemá se použít žádná konfigurace uzlu)

Příloha skupiny rezervací kapacity

Musíte znovu vytvořit podkladové virtuální počítače, aby jim byla přidělena kapacita z rezervované kapacity ve skupině Capacity Reservation Group (CRG). Existující uzly nebyly zřízeny pro CRG, takže AKS musí znovu vytvořit fond uzlů, aby je přidružil k rezervaci.

Zásady narušení uzlu spustí opětovné vytvoření bitové kopie, když připojíte skupinu rezervací kapacity k existujícímu fondu uzlů, který ji ještě nemá přiřazenou.

Od To Spustí nové vytvoření bitové kopie
Není přidružena žádná skupina rezervace kapacity. Skupina rezervací kapacity připojena Yes

Operace, na které se vztahují zásady přerušení uzlů v Kubernetes 1.37 a novější

Zásady přerušení uzlů v Kubernetes 1.37 a novějších zahrnují následující změny konfigurace, které vyžadují opětovné sestavení uzlu. V Kubernetes 1.36 a starších verzích musíte po provedení těchto změn konfigurace spustit az aks nodepool upgrade--node-image-only ručně, abyste je mohli použít na uzly.

  • Změny konfigurace SSH: Změna metod přístupu přes SSH (zakázané SSH, SSH založené na Entra ID nebo SSH místního uživatele) nebo aktualizace veřejných klíčů SSH v poolech uzlů.
  • Změny omezení IMDS: Povolení nebo zakázání omezení služby IMDS (Instance Metadata Service) pro blokování přístupu podů ke koncovému bodu IMDS
  • Změny profilu bootstrap: Změna profilu bootstrap, například přepínání artifactSource mezi Direct a Cachenebo změna containerRegistryId (Azure Container Registry používané pro clustery izolované v síti).
  • Změny odchozího typu: Úprava typu odchozího připojení clusteru (loadBalancer, userDefinedRouting, managedNATGateway nebo userAssignedNATGateway).

Operace aktualizace, které nejsou řízeny zásadami Node Disruption Policy

Zásady přerušení uzlu neřídí následující operace upgradu. Tyto operace upgradu budou pokračovat bez ohledu na nastavení zásad. Upgrady jsou iniciované zákazníkem nebo iniciované službou AKS v rámci časových období plánované údržby. Pokud chcete těmto operacím umožnit pokračovat podle plánu, záměrně je vynechejte z rozsahu zásad přerušení uzlu. Pokud jsou operace, na které se vztahují zásady přerušení uzlů, zahrnuty do stejných změn konfigurace s upgrady, nebudou řízeny zásadami přerušení uzlů.

  • Aktualizace verze image uzlu: Upgrade na novou verzi image operačního systému uzlu (ručně nebo prostřednictvím kanálů automatického upgradu) Toto je nejběžnější operace reimagingu a zahrnuje opravy zabezpečení, aktualizace operačního systému a vydání imagí uzlů AKS.
  • Verze Kubernetes – upgrady: Upgrade verze Kubernetes ve fondu uzlů, při kterém se použijí nové binární soubory Kubernetes, aktualizovaná konfigurace kubeletu a změny na úrovni operačního systému.

Operace obnovení nejsou řízeny zásadami narušení uzlu

Zásady přerušení uzlů neřídí následující automatizované operace obnovení. K těmto operacím může dojít bez ohledu na nastavení zásad, aby se zajistil stav a obnovení clusteru.

  • Obnovení předchozí konfigurace fondu uzlů: Pokud operace aktualizace fondu uzlů selže kvůli neplatné konfiguraci nebo problémům s infrastrukturou, AKS automaticky obnoví poslední známý funkční stav a znovu naimageruje uzly, aby se obnovila konfigurace.
  • Operace obnovení clusteru správy: Když technici podpory Azure během řešení incidentů provádějí administrativní obnovení clusteru, uzly se znovu vytvoří z bitové kopie, aby se zajistila konzistence mezi stavem řídicí roviny a konfigurací uzlů.
  • Aktualizace přihlašovacích údajů identity uzlu: AKS pravidelně aktualizuje přihlašovací údaje identity uzlu pro zabezpečení a dodržování předpisů. Tyto systémem iniciované aktualizace spouštějí opětovné vytvoření imagí uzlů, aby se nové přihlašovací údaje uplatnily ve všech fondech uzlů.

Integrace s plánovanou údržbou

Zásady přerušení uzlů bezproblémově fungují s časovými obdobími plánované údržby AKS . Když nastavíte zásadu na AllowDuringMaintenanceWindow, rušivé operace jsou v souladu s vaším časovým aksManagedNodeOSUpgradeSchedule obdobím údržby. Harmonogram může být vložený přímo nebo propojený se sdíleným oknem údržby. Tato integrace zajišťuje, že:

  • Ke změnám dochází pouze během schválených časových intervalů.
  • Operace jsou v koordinaci s další plánovanou údržbou.
  • Týmy vědí, kdy může dojít k přerušení.

Tato integrace poskytuje komplexní přístup ke správě změn clusteru a minimalizaci dopadu na spouštění úloh.

Note

Při použití AllowDuringMaintenanceWindowje nutné nakonfigurovat aksManagedNodeOSUpgradeSchedule časové období údržby. Použití default okna údržby nebo aksManagedAutoUpgradeSchedule (automatického upgradu clusteru) nesplňuje tento požadavek. Konfigurace propojená se sdíleným časovým obdobím údržby tento aksManagedNodeOSUpgradeSchedule požadavek splňuje. Pokud nastavíte AllowDuringMaintenanceWindow, aniž je nakonfigurováno okno aksManagedNodeOSUpgradeSchedule, budou povoleny všechny narušující operace (zásada nemá žádné okno, kterým by je omezila). Další informace o nastavení časových období údržby najdete v tématu Plánování a řízení upgradů pro cluster Azure Kubernetes Service.

Osvědčené postupy

Při implementaci zásad přerušení uzlů zvažte tato doporučení:

  • Použití AllowDuringMaintenanceWindow pro produkční prostředí: Zkombinujte s časovými intervaly plánované údržby, abyste mohli řídit, kdy dojde k přerušení v produkčních prostředích.
  • Nastavit Block během kritických období: Během událostí s vysokým provozem, spuštění produktů nebo reakce na incidenty dočasně blokují rušivé operace. Nepoužívejte Block neomezenou dobu. I když Block je vhodný pro krátkodobé zablokování (plánované události, reakce na incidenty).
  • Povolit flexibilitu v neprodukčním prostředí: Použití Allow ve vývojových a testovacích prostředích, kde je rychlá iterace důležitější než stabilita.
  • Komunikace změn zásad: Ujistěte se, že váš tým rozumí aktuálním zásadám a ví, kdy může být provoz blokovaný.
  • Naplánujte časové intervaly údržby odpovídajícím způsobem: Nastavte velikost časových intervalů údržby tak, aby vyhovovala operacím, které potřebujete provést.
  • Chování testovacích zásad: Před použitím nastavení zásad v produkčních clusterech ověřte nastavení zásad v neprodukčním prostředí.
  • Monitorování blokovaných operací: Sledujte, kdy jsou operace blokované za účelem optimalizace plánu údržby.

Související obsah

  • Poslední aktualizace v