Delen via

Patch- en upgraderichtlijnen voor Azure Kubernetes Service

  • Artikel

In deze sectie van de dagelijkse AKS-handleiding (Azure Kubernetes Service) worden patch- en upgradestrategieën voor AKS-werkknooppunten en Kubernetes-versies beschreven. Als clusteroperator moet u een plan hebben om uw clusters up-to-date te houden en kubernetes-API-wijzigingen en -afschaffingen in de loop van de tijd te bewaken.

Achtergrond en typen updates

Er zijn drie soorten updates voor AKS, elk op de volgende:

Updatetype Frequentie van upgrade Gepland onderhoud ondersteund Ondersteunde bewerkingsmethoden Doel Koppeling naar documentatie
Beveiligingspatches voor knooppuntbesturingssystemen Nachtelijk Ja Automatisch (wekelijks), handmatig/onbeheerd (nacht) Knooppunt Knooppuntinstallatiekopieën automatisch upgraden
Upgrades van versie van knooppuntinstallatiekopieën Linux: Wekelijks
Windows: Maandelijks		 Ja Automatisch, handmatig Knooppuntgroep Upgrade van AKS-knooppuntinstallatiekopieën
Upgrades van Kubernetes-versie (cluster) Driemaandelijks Ja Automatisch, handmatig Cluster- en knooppuntgroep Upgrade van AKS-cluster

Typen bijwerken

  • Beveiligingspatches voor knooppuntbesturingssystemen (alleen Linux). Voor Linux-knooppunten maken zowel Canonical Ubuntu als Azure Linux besturingssysteembeveiligingspatches eenmaal per dag beschikbaar. Microsoft test en bundelt deze patches in de wekelijkse updates voor knooppuntinstallatiekopieën.

  • Wekelijkse updates voor knooppuntinstallatiekopieën. AKS biedt wekelijkse updates voor knooppuntinstallatiekopieën. Deze updates omvatten de nieuwste besturingssysteem- en AKS-beveiligingspatches, bugfixes en verbeteringen. Knooppuntupdates wijzigen de Kubernetes-versie niet. Versies worden opgemaakt op datum (bijvoorbeeld 202311.07.0) voor Linux en op windows Server os build en datum (bijvoorbeeld 20348.2113.231115) voor Windows. Zie de status van de AKS-release voor meer informatie.

  • Kwartaalversies van Kubernetes. AKS biedt kwartaalupdates voor Kubernetes-releases. Met deze updates kunnen AKS-gebruikers profiteren van de nieuwste Kubernetes-functies en -verbeteringen. Ze bevatten beveiligingspatches en updates voor knooppuntinstallatiekopieën. Zie Ondersteunde Kubernetes-versies in AKS voor meer informatie.

Overwegingen vóór de upgrade

Algemene impact op het cluster

  • In-place upgrades (zowel knooppunt als cluster) zijn van invloed op de prestaties van uw Kubernetes-omgeving terwijl ze worden uitgevoerd. U kunt dit effect minimaliseren door de juiste configuratie van budgetten voor podonderbrekingen, configuratie van knooppuntpieken en de juiste planning.
  • Als u een blauw/groen-updatestrategie gebruikt in plaats van een upgrade uit te voeren, heeft dit geen invloed op de prestaties van het cluster, maar worden de kosten en complexiteit verhoogd.
  • Ongeacht uw upgrade- en patchstrategie moet u beschikken over een robuust test- en validatieproces voor uw cluster. Patch en upgrade eerst lagere omgevingen en voer een validatie na onderhoud uit om de status van het cluster, knooppunt, de implementatie en de toepassing te controleren.

Best practices voor AKS-workloads

Volg deze aanbevolen procedures om de werking van uw AKS-cluster tijdens onderhoud soepel te laten verlopen:

  • Budgetten voor podonderbrekingen (PDBs) definiëren. Het instellen van budgetten voor podonderbrekingen voor uw implementaties is essentieel. PDBs dwingen een minimum aantal beschikbare toepassingsreplica's af om continue functionaliteit te garanderen tijdens onderbrekingsevenementen. PDBs helpen de stabiliteit van uw cluster te behouden tijdens onderhoud of knooppuntfouten.

    Waarschuwing

    Onjuist geconfigureerde PDBS kunnen het upgradeproces blokkeren omdat de Kubernetes-API voorkomt dat de benodigde cordon en afvoer optreden met een upgrade van een rolling node-image. Als er te veel pods tegelijk worden verplaatst, kan er bovendien een storing in de toepassing optreden. Dit risico wordt beperkt door de PDB-configuratie.

  • Controleer de beschikbare reken- en netwerklimieten. Controleer de beschikbare reken- en netwerklimieten in uw Azure-abonnement via de quotumpagina in Azure Portal of met behulp van de opdracht az quota . Controleer de reken- en netwerkresources, met name vm-vCPU's voor uw knooppunten, en het aantal virtuele machines en virtuele-machineschaalsets. Als u dicht bij een limiet bent, vraagt u een quotumverhoging aan voordat u een upgrade uitvoert.
  • Controleer de beschikbare IP-ruimte in subnetten van knooppunten. Tijdens updates worden er extra piekknooppunten in uw cluster gemaakt en worden pods verplaatst naar deze knooppunten. Het is belangrijk dat u de IP-adresruimte in de subnetten van uw knooppunt bewaakt om ervoor te zorgen dat er voldoende adresruimte is voor deze wijzigingen. Verschillende Kubernetes-netwerkconfiguraties hebben verschillende IP-vereisten. Bekijk deze overwegingen als uitgangspunt:
    • Tijdens een upgrade neemt het aantal IP-adressen van knooppunten toe op basis van uw piekwaarde. (De minimale piekwaarde is 1.)
    • Clusters die zijn gebaseerd op Azure CNI wijzen IP-adressen toe aan afzonderlijke pods, dus er moet voldoende IP-ruimte zijn voor podverplaatsing.
    • Uw cluster blijft werken tijdens upgrades. Zorg ervoor dat er voldoende IP-ruimte beschikbaar is om knooppuntschalen toe te staan (als dit is ingeschakeld).
  • Meerdere omgevingen instellen. U wordt aangeraden afzonderlijke omgevingen in te stellen, zoals ontwikkeling, fasering en productie, zodat u wijzigingen kunt testen en valideren voordat u ze implementeert in productie.
  • Upgradewaarden voor pieken afstemmen. Standaard heeft AKS een piekwaarde van 1, wat betekent dat er één extra knooppunt tegelijk wordt gemaakt als onderdeel van het upgradeproces. U kunt de snelheid van een AKS-upgrade verhogen door deze waarde te verhogen. 33% piek is de aanbevolen maximumwaarde voor workloads die gevoelig zijn voor onderbrekingen. Zie Piekupgrade van knooppunten aanpassen voor meer informatie.
  • Time-out van knooppuntafvoer afstemmen. Time-out voor het leegmaken van knooppunten geeft de maximale hoeveelheid tijd aan die een cluster wacht tijdens het opnieuw plannen van pods op een knooppunt dat wordt bijgewerkt. De standaardwaarde hiervoor is 30 minuten. Voor workloads die moeite hebben om pods opnieuw te plannen, kan het handig zijn om deze standaardwaarde aan te passen.
  • Onderhoudsvensters plannen en plannen. Upgradeprocessen kunnen van invloed zijn op de algehele prestaties van uw Kubernetes-cluster. Plan in-place upgradeprocessen buiten piekvensters voor gebruik en bewaak de clusterprestaties om een adequate grootte te garanderen, met name tijdens updateprocessen.
  • Controleer andere afhankelijkheden in uw cluster. Kubernetes-operators implementeren vaak andere hulpprogramma's in het Kubernetes-cluster als onderdeel van bewerkingen, zoals KEDA-schaalders, Dapr en service-meshes. Wanneer u uw upgradeprocessen plant, controleert u de releaseopmerkingen voor alle onderdelen die u gebruikt om compatibiliteit met de doelversie te garanderen.

Wekelijkse updates voor knooppuntinstallatiekopieën beheren

Microsoft maakt ongeveer één keer per week een nieuwe knooppuntinstallatiekopieën voor AKS-knooppunten. Een knooppuntinstallatiekopieën bevatten bijgewerkte besturingssysteembeveiligingspatches, besturingssysteemkernelupdates, Kubernetes-beveiligingsupdates, bijgewerkte versies van binaire bestanden, zoals kubelet en onderdelenversie-updates die worden vermeld in de releaseopmerkingen.

Wanneer een knooppuntinstallatiekopie wordt bijgewerkt, wordt een cordon- en afvoeractie geactiveerd op de knooppunten van de doelknooppuntgroep:

  • Er wordt een knooppunt met de bijgewerkte installatiekopieën toegevoegd aan de knooppuntgroep. Het aantal knooppunten dat tegelijkertijd wordt toegevoegd, wordt bepaald door de piekwaarde.
  • Afhankelijk van de piekwaarde worden een batch bestaande knooppunten ingesnoerd en leeggezogen. Cordoning zorgt ervoor dat het knooppunt geen pods plant. Door het leegmaken worden de pods verwijderd en worden ze gepland op andere knooppunten.
  • Nadat deze knooppunten volledig zijn verwijderd, worden ze verwijderd uit de knooppuntgroep. De bijgewerkte knooppunten die door de piek zijn toegevoegd, vervangen ze.
  • Dit proces wordt herhaald voor elke resterende batch knooppunten die moeten worden bijgewerkt in de knooppuntgroep.

Een vergelijkbaar proces vindt plaats tijdens een clusterupgrade.

Automatische upgrades van knooppuntinstallatiekopieën

Over het algemeen moeten de meeste clusters het NodeImage updatekanaal gebruiken. Dit kanaal biedt wekelijks een bijgewerkte VHD voor knooppuntinstallatiekopieën en wordt bijgewerkt volgens het onderhoudsvenster van uw cluster.

Beschikbare kanalen zijn onder andere:

  • None. Er worden geen updates automatisch toegepast.
  • Unmanaged. Ubuntu- en Azure Linux-updates worden 's nachts door het besturingssysteem toegepast. Opnieuw opstarten moet afzonderlijk worden beheerd. AKS kan dit niet testen en kan het frequentie van dit niet controleren.
  • SecurityPatch. Beveiligingspatches voor het besturingssysteem die door AKS zijn getest, volledig beheerd en worden toegepast met veilige implementatieprocedures. Het bevat geen bugfixes voor het besturingssysteem, alleen beveiligingsupdates.
  • NodeImage. AKS werkt de knooppunten bij met een nieuw gepatchte VHD met beveiligingscorrecties en bugfixes op een wekelijkse frequentie. Dit is volledig getest en geïmplementeerd met veilige implementatieprocedures. Voor realtime informatie over momenteel geïmplementeerde knooppuntinstallatiekopieën raadpleegt u de sectie [AKS-knooppuntinstallatiekopieën in de releasetracker][release-tracker].

Als u de standaardfrequenties wilt begrijpen zonder dat er een onderhoudsvenster tot stand is gebracht, raadpleegt u het eigendom en de frequentie van het bijwerken.

Als u het Unmanaged updatekanaal kiest, moet u het proces voor opnieuw opstarten beheren met behulp van een hulpprogramma zoals kured. Unmanaged wordt niet geleverd met door AKS geleverde veilige implementatieprocedures en werkt niet onder onderhoudsvensters. Als u het SecurityPatch updatekanaal kiest, kunnen updates zo vaak als wekelijks worden toegepast. Voor dit patchniveau moeten de VHD's worden opgeslagen in uw resourcegroep, waarvoor een nominale kosten in rekening worden gebracht. Bepaal wanneer de SecurityPatch toepassing wordt toegepast door een geschikte aksManagedNodeOSUpgradeSchedule instelling in te stellen die overeenkomt met een frequentie die het beste werkt voor uw workload. Zie Een onderhoudsvenster maken voor meer informatie. Als u ook oplossingen voor fouten nodig hebt die doorgaans worden geleverd met nieuwe knooppuntinstallatiekopieën (VHD), moet u het NodeImage kanaal kiezen in plaats van SecurityPatch.

Als best practice kunt u het NodeImage updatekanaal gebruiken en een aksManagedNodeOSUpgradeSchedule onderhoudsvenster configureren tot een tijdstip waarop het cluster zich buiten piekvensters bevindt. Zie Een onderhoudsvenster maken voor kenmerken die u kunt gebruiken om het onderhoudsvenster van het cluster te configureren. De belangrijkste kenmerken zijn:

  • name. Gebruiken aksManagedNodeOSUpgradeSchedule voor updates van knooppuntbesturingssystemen.
  • utcOffset. Configureer de tijdzone.
  • startTime. Stel de begintijd van het onderhoudsvenster in.
  • dayofWeek. Stel de dagen van de week voor het venster in. Bijvoorbeeld: Saturday.
  • schedule. Stel de frequentie van het venster in. Voor NodeImage updates raden we u aan weekly.
  • durationHours. Stel dit kenmerk in op ten minste vier uur.

In dit voorbeeld wordt een wekelijks onderhoudsvenster ingesteld op 18:00 uur Eastern Time op zaterdag:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Zie Een onderhoudsvensterconfiguratie toevoegen met Azure CLI voor meer voorbeelden.

Deze configuratie zou idealiter worden geïmplementeerd als onderdeel van de implementatie van infrastructuur als code van het cluster.

U kunt controleren op geconfigureerde onderhoudsvensters met behulp van de Azure CLI:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

U kunt ook de details van een specifiek onderhoudsvenster controleren met behulp van de CLI:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Als een clusteronderhoudsvenster niet is geconfigureerd, worden updates van knooppuntinstallatiekopieën tweewekelijks uitgevoerd. AKS-onderhoud vindt zoveel mogelijk plaats in het geconfigureerde venster, maar de tijd van onderhoud is niet gegarandeerd.

Belangrijk

Als u een knooppuntgroep met een groot aantal knooppunten hebt, maar deze niet is geconfigureerd met een piek in het knooppunt, wordt de gebeurtenis voor automatische upgrade mogelijk niet geactiveerd. Knooppuntinstallatiekopieën in een knooppuntgroep worden alleen bijgewerkt terwijl de geschatte totale upgradetijd binnen 24 uur ligt.

In deze situatie kunt u een van de volgende zaken overwegen:

  • knooppunten splitsen in verschillende knooppuntgroepen als uw vCPU-quotum bijna vol is en u het vCPU-quotum niet kunt verhogen
  • knooppuntpieken configureren om de geschatte upgradetijd te verlagen als uw vCPU-quotum voldoende is

U kunt de status van upgrade-gebeurtenissen controleren via uw Azure-activiteitenlogboeken of door de resourcelogboeken in uw cluster te controleren.

U kunt zich abonneren op AKS-gebeurtenissen (Azure Kubernetes Service) met Azure Event Grid , waaronder AKS-upgrade-gebeurtenissen. Deze gebeurtenissen kunnen u waarschuwen wanneer er een nieuwe versie van Kubernetes beschikbaar is en u kunt helpen bij het bijhouden van wijzigingen in de status van knooppunten tijdens de upgradeprocessen.

U kunt het wekelijkse updateproces ook beheren met behulp van GitHub Actions. Deze methode biedt een gedetailleerdere controle over het updateproces.

Proces voor handmatig bijwerken van knooppunten

U kunt de opdracht kubectl knooppunten beschrijven om de kernelversie van het besturingssysteem en de versie van de besturingssysteeminstallatiekopieën van de knooppunten in uw cluster te bepalen:

kubectl describe nodes <NodeName>

Voorbeelduitvoer (afgekapt):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Gebruik de azure CLI az aks nodepool list command om de versie van de knooppuntinstallatiekopieën van de knooppunten in een cluster te bepalen:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Voorbeelduitvoer:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Gebruik az aks nodepool get-upgrades om de meest recente beschikbare versie van de knooppuntinstallatiekopieën voor een specifieke knooppuntgroep te bepalen:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Voorbeelduitvoer:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Clusterupgrades

De Kubernetes-community brengt ongeveer elke drie maanden secundaire versies van Kubernetes uit. Om u op de hoogte te houden van nieuwe AKS-versies en -releases, wordt de pagina met opmerkingen bij de AKS-release regelmatig bijgewerkt. U kunt zich ook abonneren op de GitHub AKS RSS-feed, die realtime updates biedt over wijzigingen en verbeteringen.

AKS volgt een N- 2-ondersteuningsbeleid , wat betekent dat volledige ondersteuning wordt geboden voor de nieuwste versie (N) en twee eerdere secundaire versies. Beperkte platformondersteuning wordt aangeboden voor de derde secundaire versie. Zie AKS-ondersteuningsbeleid voor meer informatie.

Om ervoor te zorgen dat uw AKS-clusters ondersteund blijven, moet u een proces voor continue clusterupgrade tot stand brengen. Dit proces omvat het testen van nieuwe versies in lagere omgevingen en het plannen van de upgrade naar productie voordat de nieuwe versie de standaardversie wordt. Deze aanpak kan voorspelbaarheid in uw upgradeproces behouden en onderbrekingen van toepassingen minimaliseren. Zie Een AKS-cluster upgraden voor meer informatie.

Als voor uw cluster een langere upgradecyclus is vereist, gebruikt u AKS-versies die ondersteuning bieden voor de optie Long Term Support (LTS). Als u de LTS-optie inschakelt, biedt Microsoft gedurende twee jaar uitgebreide ondersteuning voor Kubernetes-versies, waardoor een langere en gecontroleerde upgradecyclus mogelijk is. Zie Ondersteunde Kubernetes-versies in AKS voor meer informatie.

Een clusterupgrade omvat een knooppuntupgrade en maakt gebruik van een vergelijkbaar cordon- en afvoerproces.

Voordat u een upgrade uitvoert

Als best practice moet u altijd upgraden en testen in lagere omgevingen om het risico op onderbrekingen in de productie te minimaliseren. Voor clusterupgrades is extra tests vereist, omdat er API-wijzigingen nodig zijn, wat van invloed kan zijn op Kubernetes-implementaties. De volgende bronnen kunnen u helpen bij het upgradeproces:

  • AKS-werkmap voor afgeschafte API's. Op de overzichtspagina van het cluster in Azure Portal kunt u Problemen vaststellen en oplossen selecteren, naar de categorie Maken, Upgraden, Verwijderen en Schalen gaan en vervolgens Kubernetes-API-afschaffingen selecteren. Hiermee wordt een werkmap uitgevoerd waarmee wordt gecontroleerd op afgeschafte API-versies die in uw cluster worden gebruikt. Zie Het gebruik van afgeschafte API's verwijderen voor meer informatie.
  • Pagina met opmerkingen bij de release van AKS. Deze pagina bevat uitgebreide informatie over nieuwe AKS-versies en -releases. Bekijk deze notities om op de hoogte te blijven van de meest recente updates en wijzigingen.
  • Pagina met opmerkingen bij de release van Kubernetes. Deze pagina biedt gedetailleerde inzichten in de nieuwste Kubernetes-versies. Let vooral op urgente upgradenotities, waarin kritieke informatie wordt gemarkeerd die van invloed kan zijn op uw AKS-cluster.
  • AKS-onderdelen die wijzigingen veroorzaken per versie. Deze tabel biedt een uitgebreid overzicht van belangrijke wijzigingen in AKS-onderdelen per versie. Door naar deze handleiding te verwijzen, kunt u proactief mogelijke compatibiliteitsproblemen vóór het upgradeproces oplossen.

Naast deze Microsoft-resources kunt u gebruikmaken van opensource-hulpprogramma's om uw clusterupgradeproces te optimaliseren. Een van deze hulpprogramma's is Fairwinds pluto, waarmee u uw implementaties en Helm-grafieken kunt scannen op afgeschafte Kubernetes-API's. Met deze hulpprogramma's kunt u ervoor zorgen dat uw toepassingen compatibel blijven met de nieuwste Kubernetes-versies.

Upgradeproces

Als u wilt controleren wanneer voor uw cluster een upgrade is vereist, gebruikt u az aks get-upgrades om een lijst met beschikbare upgradeversies voor uw AKS-cluster op te halen. Bepaal de doelversie voor uw cluster uit de resultaten.

Hier volgt een voorbeeld:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Voorbeelduitvoer:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Controleer de Kubernetes-versies van de knooppunten in uw knooppuntgroepen om te bepalen welke pools moeten worden bijgewerkt:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Voorbeelduitvoer:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Handmatig upgraden

Als u onderbrekingen wilt minimaliseren en een soepele upgrade voor uw AKS-cluster wilt garanderen, volgt u deze upgradebenadering:

  1. Werk het AKS-besturingsvlak bij. Begin met het upgraden van het AKS-besturingsvlak. Deze stap omvat het upgraden van de onderdelen van het besturingsvlak die verantwoordelijk zijn voor het beheren en organiseren van uw cluster. Als u het besturingsvlak bijwerken, zorgt u eerst voor compatibiliteit en stabiliteit voordat u de afzonderlijke knooppuntgroepen bijwerken.
  2. Voer een upgrade uit voor uw systeemknooppuntgroep. Nadat u het besturingsvlak hebt bijgewerkt, voert u een upgrade uit van de systeemknooppuntgroep in uw AKS-cluster. Knooppuntgroepen bestaan uit de exemplaren van virtuele machines waarop uw toepassingsworkloads worden uitgevoerd. Als u de knooppuntgroepen afzonderlijk bijwerken, kunt u een gecontroleerde en systematische upgrade uitvoeren van de onderliggende infrastructuur die ondersteuning biedt voor uw toepassingen.
  3. Upgrade gebruikersknooppuntgroepen. Nadat u de systeemknooppuntgroep hebt bijgewerkt, moet u alle gebruikersknooppuntgroepen in uw AKS-cluster bijwerken.

Door deze aanpak te volgen, kunt u onderbrekingen tijdens het upgradeproces minimaliseren en de beschikbaarheid van uw toepassingen behouden. Dit zijn de gedetailleerde stappen:

  1. Voer de opdracht az aks upgrade uit met de --control-plane-only vlag om alleen het clusterbesturingsvlak te upgraden en niet de knooppuntgroepen van het cluster:

    az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>

  2. Voer az aks nodepool upgrade uit om knooppuntgroepen te upgraden naar de doelversie:

    az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>

    Tijdens de upgrade van de knooppuntgroep maakt AKS een piekknooppunt, cordons en leegloopt pods in het knooppunt dat wordt bijgewerkt, herinstallatiekopie van het knooppunt en verwijdert vervolgens de pods. Dit proces wordt vervolgens herhaald voor eventuele andere knooppunten in de knooppuntgroep.

U kunt de status van het upgradeproces controleren door uit te voeren kubectl get events. Raadpleeg de documentatie voor het oplossen van problemen met clusterupgrades voor AKS voor informatie over het oplossen van problemen met clusterupgrades.

Clusters inschrijven bij releasekanalen voor automatisch upgraden

AKS biedt ook een oplossing voor automatische clusterupgrades om uw cluster up-to-date te houden. Als u deze oplossing gebruikt, moet u deze koppelen aan een onderhoudsvenster om de timing van upgrades te beheren. Het upgradevenster moet vier uur of langer zijn. Wanneer u een cluster inschrijft in een releasekanaal, beheert Microsoft automatisch de versie en upgradefrequentie voor het cluster en de bijbehorende knooppuntgroepen.

De automatische upgrade van het cluster biedt verschillende releasekanaalopties. Hier volgt een aanbevolen omgevings- en releasekanaalconfiguratie:

Omgeving Upgradekanaal Beschrijving
Productie stable Gebruik voor stabiliteit en versierijpheid het stabiele of reguliere kanaal voor productieworkloads.
Fasering, testen, ontwikkelen Hetzelfde als productie Gebruik hetzelfde releasekanaal als productie om ervoor te zorgen dat uw tests wijzen op de versie waarnaar u uw productieomgeving gaat upgraden.
Canary rapid Gebruik het rapid kanaal om de nieuwste Kubernetes-releases en nieuwe AKS-functies of API's te testen. U kunt uw markttijd verbeteren wanneer de versie rapid wordt gepromoveerd naar het kanaal dat u gebruikt voor productie.

Overwegingen

In de volgende tabel worden de kenmerken van verschillende AKS-upgrade- en patchscenario's beschreven:

Scenario Door de gebruiker geïnitieerd Kubernetes-upgrade Upgrade van besturingssysteemkernel Upgrade van knooppuntinstallatiekopie
Beveiligingspatching Nee Nr. Ja, na opnieuw opstarten Ja
Cluster maken Ja Misschien Ja, als een bijgewerkte knooppuntinstallatiekopieën een bijgewerkte kernel gebruiken Ja, ten opzichte van een bestaand cluster als er een nieuwe release beschikbaar is
Kubernetes-upgrade van het besturingsvlak Ja Ja No Nr.
Kubernetes-upgrade van knooppuntgroep Ja Ja Ja, als een bijgewerkte knooppuntinstallatiekopieën een bijgewerkte kernel gebruiken Ja, als er een nieuwe release beschikbaar is
Knooppuntgroep omhoog schalen Ja No Nee Nr.
Upgrade van knooppuntinstallatiekopie Ja Nr. Ja, als een bijgewerkte knooppuntinstallatiekopieën een bijgewerkte kernel gebruiken Ja
Automatische upgrade van cluster Nr. Ja Ja, als een bijgewerkte knooppuntinstallatiekopieën een bijgewerkte kernel gebruiken Ja, als er een nieuwe release beschikbaar is
  • Een besturingssysteembeveiligingspatch die wordt toegepast als onderdeel van een upgrade van een knooppuntinstallatiekopie, kan een latere versie van de kernel installeren dan het maken van een nieuw cluster zou worden geïnstalleerd.
  • Omhoog schalen van knooppuntgroepen maakt gebruik van het model dat momenteel is gekoppeld aan de virtuele-machineschaalset. De kernels van het besturingssysteem worden bijgewerkt wanneer beveiligingspatches worden toegepast en de knooppunten opnieuw worden opgestart.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen