Knooppuntonderbrekingsbeleid in Azure Kubernetes Service (AKS) (preview)

Wanneer u uw AKS-clusters beheert en onderhoudt, moeten voor bepaalde configuratiewijzigingen de installatiekopie van knooppunten opnieuw worden gemaakt. Met deze bewerking voor opnieuw installeren wordt een gefaseerde update gestart waarbij knooppunten opnieuw worden aangemaakt. Tijdens een reimagebewerking cordont AKS het knooppunt (waardoor er geen nieuwe pods op worden gepland), verwijdert het de bestaande pods van het knooppunt (door deze te verwijderen en opnieuw te plannen op andere beschikbare knooppunten, met inachtneming van Pod Disruption Budgets) en voorziet het vervolgens het knooppunt opnieuw van een installatiekopie met de bijgewerkte configuratie. Dit proces is een volledige hercreatie van het knooppunt, geen herstart: de onderliggende VM wordt opnieuw ingericht met een nieuwe installatiekopie van het besturingssysteem. Hoewel correct geconfigureerde persistente volumes (met Azure Disks, Azure Files of andere externe opslag) niet worden beïnvloed, gaan alle gegevens die zijn opgeslagen in de lokale tijdelijke opslag van het knooppunt (zoals EmptyDir-volumes of lokale paden) permanent verloren. Deze bewerkingen zijn nodig om belangrijke updates toe te passen, maar ze kunnen de actieve workloads verstoren en de beschikbaarheid van toepassingen beïnvloeden. Knooppuntonderbrekingsbeleid geeft u gedetailleerde controle over wanneer deze verstorende bewerkingen mogen doorgaan, zodat u de behoefte aan updates met operationele stabiliteit kunt verdelen.

Wat is knooppuntonderbrekingsbeleid?

Beleid voor knooppuntverstoring is een configuratie op clusterniveau die bepaalt wanneer bewerkingen kunnen worden uitgevoerd waarvoor knooppunten opnieuw van een image moeten worden voorzien en opnieuw moeten worden geïmplementeerd. Het fungeert als een controlepoort, zodat u het volgende kunt doen:

• Lijn storende bewerkingen af met uw onderhoudsvensters.
• Blokkeer configuratiewijzigingen tijdens kritieke bedrijfsperioden terwijl het nog steeds mogelijk is om upgrades van knooppuntinstallatiekopieën en beveiligingspatches door te voeren.
• Voorspelbaar clustergedrag behouden tijdens gebeurtenissen met veel verkeer.

Het beleid is van toepassing op door de gebruiker geïnitieerde configuratiewijzigingen waarvoor knooppuntrecreatie is vereist, zoals het bijwerken van aangepaste certificeringsinstantievertrouwenscertificaten, het wijzigen van beveiligingsprofielinstellingen of het wijzigen van de configuratie van het knooppuntbesturingssysteem.

Werking van knooppuntonderbrekingsbeleid

U configureert nodeonderbrekingsbeleid op clusterniveau via de nodeDisruptionProfile eigenschap. Wanneer u een bewerking probeert uit te voeren waarvoor een knooppunt opnieuw van een installatiekopie moet worden voorzien, controleert AKS de huidige beleidsinstelling:

• Beleidsevaluatie: AKS evalueert of de bewerking is toegestaan op basis van het huidige beleid.
• Controle van onderhoudsvenster (indien van toepassing): Als u AKS gebruikt AllowDuringMaintenanceWindow, wordt gecontroleerd of de huidige tijd binnen het geconfigureerde onderhoudsvenster valt.
• Uitvoering of blokkering van de bewerking: de knooppuntstorende bewerking wordt uitgevoerd als dit is toegestaan of geweigerd met een foutbericht als deze wordt geblokkeerd.

Beleidsopties

Knooppuntonderbrekingsbeleid ondersteunt drie beleidsconfiguraties:

Considerations

Houd rekening met de volgende overwegingen bij het gebruik van nodeonderbrekingsbeleid:

• Reikwijdte: Het beleid is van toepassing op door de gebruiker geïnitieerde bewerkingen waarvoor het opnieuw image’n van knooppunten is vereist, en niet op door AKS geïnitieerd systeemonderhoud. Zie Herstelbewerkingen die niet worden beheerd door knooppuntonderbrekingsbeleid voor meer informatie.
• Geblokkeerde bewerkingen: wanneer een verstorende bewerking wordt geblokkeerd, mislukt de API-aanroep met een foutbericht. U moet het beleid wijzigen of wachten op het onderhoudsvenster.
• Noodonderhoud: Azure behoudt zich het recht voor om dringende of kritieke onderhoudswerkzaamheden uit te voeren, ongeacht de beleidsinstelling.
• Planning bijwerken: het beleid zo Block instellen dat bepaalde clusterupdates worden voorkomen. Zie Bewerkingen die worden gedekt door knooppuntonderbrekingsbeleid voor meer informatie. Plan dienovereenkomstig om ervoor te zorgen dat u de benodigde updates kunt toepassen wanneer dat nodig is.
• Afhankelijkheid van onderhoudsvenster: Voor het AllowDuringMaintenanceWindow beleid moet een aksManagedNodeOSUpgradeSchedule onderhoudsvenster worden geconfigureerd. Zie Gepland onderhoud gebruiken om upgrades voor uw Azure Kubernetes Service-cluster te plannen en te beheren voor meer informatie.

Bewerkingen die worden gedekt door knooppuntonderbrekingsbeleid

Bewerkingen op clusterniveau

Netwerkbeleid inschakelen en Azure CNI-overlay-upgrade

Als u de vereiste netwerkcomponenten wilt installeren en netwerkregels wilt configureren die pod-naar-pod-communicatie beveiligen en beheren, moet u de knooppunten opnieuw installeren.

De volgende tabel bevat een overzicht van netwerkbeleidsupgrades die opnieuw installatiekopie activeren:

Wijzigingen in het upgradekanaal van het nodebesturingssysteem

Elk kanaal maakt gebruik van een andere infrastructuur en configuratie voor patching van het besturingssysteem die u niet kunt wijzigen op actieve knooppunten.

De volgende tabel geeft een overzicht van wijzigingen in het upgradekanaal van het knooppuntbesturingssysteem die een herinstallatie van de installatiekopie veroorzaken:

IPv6 dual-stack inschakelen

Knooppunten hebben zowel IPv4- als IPv6-IP-configuraties en netwerkstackupdates (zoals regels voor nftables) nodig om communicatie tussen twee stacks te ondersteunen.

De volgende tabel bevat een overzicht van IP-configuratie- en netwerkstackupdates die opnieuw installatiekopie activeren:

Wijzigingen in het gegevensvlak van de Cilium

U moet eBPF-programma's installeren of verwijderen die pakketverwerking op kernelniveau verwerken.

De volgende tabel geeft een overzicht van wijzigingen in de Cilium-data plane die een nieuwe image vereisen:

Updates voor HTTP-proxyconfiguratie

Alle knooppuntonderdelen (containerd, kubelet, systeemservices) hebben de bijgewerkte proxyconfiguratie nodig die op het hele systeem is toegepast. Wanneer u de HTTP-proxyconfiguratie bijwerkt, voorziet AKS automatisch alle knooppuntgroepen in het cluster opnieuw van een installatiekopie.

Knooppuntonderbrekingsbeleid activeert een nieuwe installatiekopie wanneer u een van de volgende configuratie-eigenschappen van de HTTP-proxy wijzigt of een van de volgende bewerkingen uitvoert:

• httpProxy: Proxy-URL voor HTTP-verbindingen
• httpsProxy: Proxy-URL voor HTTPS-verbindingen
• noProxy: Lijst met bestemmingen die moeten worden uitgesloten van proxying
• trustedCa: met Base64 gecodeerd alternatief CA-certificaat
• HTTP-proxy inschakelen op een cluster (met --enable-http-proxy)
• HTTP-proxy op een cluster uitschakelen (met --disable-http-proxy)
• Http-proxy opnieuw inschakelen op een cluster waarvoor deze eerder was uitgeschakeld

Updates voor aangepaste CA-certificaten

U moet nieuwe CA-certificaten installeren in het vertrouwensarchief van het besturingssysteem om de TLS-validatie voor interne services en privéregisters te beïnvloeden.

Knooppuntonderbrekingsbeleid activeert opnieuw installatiekopie wanneer u aangepaste CA-certificaten toevoegt, verwijdert of bijwerkt.

Kubelet-identiteitswijzigingen

U moet nieuwe identiteitsreferenties toepassen op de knooppuntconfiguratie. Dit omvat de eerste identiteitstoewijzing, identiteitsupdates en het opnieuw instellen van het service-principal-profiel.

Knooppuntonderbrekingsbeleid activeert een nieuwe installatiekopie wanneer u een beheerde identiteit of door de gebruiker toegewezen beheerde identiteit voor de kubelet bijwerkt.

Privé-DNS zonewijzigingen

U moet dns-resolver-instellingen bijwerken om het privé-API-servereindpunt op te lossen met behulp van de nieuwe DNS-zone.

Knooppuntonderbrekingsbeleid activeert opnieuw installatiekopie wanneer u een privé-DNS-zoneconfiguratie in een privécluster wijzigt.

Inschakeling van VNet-integratie voor API Server

U moet de knooppunten opnieuw configureren om te communiceren met de API-server via het interne IP-adres van de load balancer dat in het gedelegeerde subnet wordt geprojecteerd.

Beleid voor knooppuntonderbreking activeert het opnieuw installeren van de installatiekopie wanneer u API Server-VNet-integratie inschakelt op een bestaand cluster dat hier niet eerder gebruik van maakte. Deze wijziging komt overeen met een wijziging van de eigenschap apiServerAccessProfile.enableVnetIntegration (intern het veld privateConnectProfile.enabled) van false (of niet ingesteld) naar true:

Routeringswijzigingen voor eBPF-hosts

U moet eBPF-programma's installeren of verwijderen die het doorsturen van pakketten met hoge prestaties (BpfVeth-versnellingsmodus) bieden.

De volgende tabel bevat een overzicht van eBPF-hostrouteringswijzigingen die opnieuw installatiekopie activeren:

Bewerkingen op knooppuntgroepniveau

Deze bewerkingen zijn alleen van invloed op de specifieke knooppuntgroepen waar u wijzigingen aanbrengt. Ze activeren een rolling reimage binnen deze knooppuntgroepen:

Updates van lokale DNS-profielen

U moet wijzigingen toepassen op de DNS-cache-daemon- en DNS-doorstuurregels op knooppuntniveau.

Knooppuntonderbrekingsbeleid activeert opnieuw installatiekopie wanneer u een LocalDNS-profielconfiguratie wijzigt.

Trusted Launch-beveiligingswijzigingen

U kunt de configuratie van vm-firmware en opstartprocesinstellingen niet wijzigen op actieve VM's. Voor deze wijzigingen moet u de VM's opnieuw aanmaken.

De volgende tabel geeft een overzicht van beveiligingswijzigingen in Trusted Launch die een herinstallatie activeren:

Wijzigingen in artifactstreaming

U moet onderdelen voor artifactstreaming installeren of verwijderen om containerimages sneller te kunnen ophalen door imagelagen on-demand te streamen.

De volgende tabel geeft een overzicht van wijzigingen in artifactstreaming die een herinstallatie veroorzaken:

Windows GMSA-profielupdates (alleen Windows knooppuntgroepen)

U moet nieuwe GMSA-instellingen, DNS-serverconfiguratie en domeindeelnamereferenties toepassen voor Active Directory-integratie op de Windows-knooppunten.

Knooppuntonderbrekingsbeleid activeert een nieuwe installatiekopie van de Windows-knooppuntgroepen wanneer voor een GMSA-wijziging nieuwe knooppuntconfiguratie moet worden toegepast:

Bijlage van capaciteitsreserveringsgroep

U moet de onderliggende VM's opnieuw maken, zodat deze worden toegewezen vanuit de gereserveerde capaciteit in de CRG (Capacity Reservation Group). Bestaande knooppunten zijn niet ingericht voor de CRG, dus AKS moet de knooppuntgroep opnieuw instellen om deze aan de reservering te koppelen.

Knooppuntonderbrekingsbeleid activeert een nieuwe installatiekopie wanneer u een capaciteitsreserveringsgroep koppelt aan een bestaande knooppuntgroep die nog geen groep heeft.

Bewerkingen die nog niet worden gedekt door knooppuntonderbrekingsbeleid

De volgende configuratiewijzigingen vereisen het opnieuw provisionen van een node, maar vallen nog niet onder de Node Disruption Policy. In een toekomstige update van de secundaire kubernetes-versie worden deze wijzigingen behandeld, omdat deze wijziging nieuw gedrag introduceert.
Nadat u deze configuratiewijzigingen hebt aangebracht, moet u az aks nodepool upgrade handmatig uitvoeren met --node-image-only om de wijzigingen op uw nodes toe te passen.

• SSH-configuratiewijzigingen: SSH-toegangsmethoden wijzigen (uitgeschakelde SSH, Entra ID op basis van SSH of lokale gebruikers-SSH) of openbare SSH-sleutels bijwerken in knooppuntgroepen.
• IMDS-beperkingswijzigingen: imds-beperking (Instance Metadata Service) in- of uitschakelen om podtoegang tot het IMDS-eindpunt te blokkeren.
• Bootstrap-profielwijzigingen: het bootstrapprofiel wijzigen, zoals het schakelen tussen artifactSource enDirectCache, of het containerRegistryId wijzigen (de Azure Container Registry gebruikt voor netwerkisolatieclusters).
• Wijzigingen in uitgaand type: het uitgaande connectiviteitstype van het cluster wijzigen (loadBalancer, userDefinedRouting, managedNATGateway of userAssignedNATGateway).

Upgradebewerkingen die niet worden beheerd door knooppuntonderbrekingsbeleid

Het knooppuntonderbrekingsbeleid heeft geen controle over de volgende upgradebewerkingen. Deze upgradebewerkingen worden uitgevoerd, ongeacht uw beleidsinstelling. Upgrades worden door de klant geïnitieerd of geïnitieerd door AKS binnen geplande onderhoudsvensters. Als u wilt toestaan dat deze bewerkingen worden voortgezet zoals gepland, houdt u ze opzettelijk buiten het bereik van het knooppuntonderbrekingsbeleid. Daarnaast vallen bewerkingen die onder het Node Disruption Policy vallen, als ze als onderdeel van dezelfde configuratiewijzigingen als upgrades zijn opgenomen, niet onder het Node Disruption Policy.

• Updates van versie van knooppuntinstallatiekopieën: upgraden naar een nieuwe versie van het besturingssysteem van het knooppunt (handmatig of via kanalen voor automatische upgrade). Deze bewerking is de meest voorkomende herinstallatiekopiebewerking en bevat beveiligingspatches, besturingssysteemupdates en installatiekopieversies van AKS-knooppunten.
• Kubernetes-versie-upgrades: de Kubernetes-versie bijwerken in een knooppuntgroep, waarmee nieuwe binaire Kubernetes-bestanden, bijgewerkte kubelet-configuratie en wijzigingen op besturingssysteemniveau worden toegepast.

Herstelbewerkingen die niet worden beheerd door knooppuntonderbrekingsbeleid

Knooppuntonderbrekingsbeleid bepaalt niet de volgende geautomatiseerde herstelbewerkingen. Deze bewerkingen kunnen ongeacht de instelling van uw beleid plaatsvinden om de gezondheid van het cluster en herstel te waarborgen.

• Terugdraaien van de configuratie van een knooppuntgroep: wanneer een updatebewerking voor een knooppuntgroep mislukt vanwege een ongeldige configuratie of infrastructuurproblemen, draait AKS automatisch terug naar de laatst bekende goede status en worden knooppunten opnieuw van een installatiekopie voorzien om de configuratie terug te zetten.
• Herstelbewerkingen voor beheerclusters: Wanneer ondersteuningsmedewerkers van Azure tijdens het oplossen van incidenten een beheercluster herstellen, worden knooppunten opnieuw van een installatiekopie voorzien om consistentie tussen de status van de control plane en de knooppuntconfiguratie te waarborgen.
• Updates van knooppuntidentiteitsreferenties: AKS werkt periodiek identiteitsreferenties voor knooppunten bij voor beveiliging en naleving. Deze door het systeem geïnitieerde updates leiden ertoe dat knooppunten opnieuw worden geïnstalleerd om de nieuwe inloggegevens in alle knooppuntgroepen door te voeren.

Integratie met gepland onderhoud

Knooppuntonderbrekingsbeleid werkt naadloos met geplande onderhoudsvensters van AKS . Wanneer u het beleid instelt op AllowDuringMaintenanceWindow, worden verstorende bewerkingen afgestemd op uw aksManagedNodeOSUpgradeSchedule onderhoudsvenster, zodat:

• Wijzigingen vinden alleen plaats tijdens goedgekeurde tijdvensters.
• De werkzaamheden worden gecoördineerd met ander gepland onderhoud.
• Teams zijn op de hoogte van wanneer er onderbrekingen kunnen optreden.

Deze integratie biedt een uitgebreide benadering voor het beheren van clusterwijzigingen en het minimaliseren van de impact op actieve workloads.

Beste praktijken

Houd rekening met deze aanbevelingen bij het implementeren van nodeonderbrekingsbeleid:

• Gebruik AllowDuringMaintenanceWindow voor productie: Combineer met geplande onderhoudsvensters om te bepalen wanneer er onderbrekingen optreden in productieomgevingen.
• Instellen Block tijdens kritieke perioden: Storende bewerkingen tijdelijk blokkeren tijdens gebeurtenissen met veel verkeer, productlanceringen of incidentrespons. Gebruik niet Block voor onbepaalde tijd. Hoewel Block dit geschikt is voor kortdurende bevriezen (geplande gebeurtenissen, reactie op incidenten).
• Flexibiliteit in niet-productie toestaan: gebruik Allow in ontwikkel- en testomgevingen waarbij snelle iteratie belangrijker is dan stabiliteit.
• Beleidswijzigingen doorgeven: zorg ervoor dat uw team het huidige beleid begrijpt en weet wanneer bewerkingen mogelijk worden geblokkeerd.
• Onderhoudsvensters plannen op de juiste manier: de grootte van uw onderhoudsvensters aanpassen aan de bewerkingen die u moet uitvoeren.
• Gedrag van het testbeleid: Valideer beleidsinstellingen in niet-productieomgevingen voordat u deze toepast op productieclusters.
• Geblokkeerde bewerkingen bewaken: bijhouden wanneer bewerkingen worden geblokkeerd om uw onderhoudsschema te optimaliseren.

Verwante onderwerpen

• Meer informatie over het configureren van knooppuntonderbrekingsbeleid.
• Inzicht in gepland onderhoud in AKS.