Uppdaterings- och uppgraderingsvägledning för Azure Kubernetes Service

I det här avsnittet av åtgärdsguiden för Azure Kubernetes Service (AKS) dag-2 beskrivs korrigerings- och uppgraderingsstrategier för AKS-arbetsnoder och Kubernetes-versioner. Som klusteroperator måste du ha en plan för att hålla dina kluster uppdaterade och övervaka Kubernetes API-ändringar och utfasningar över tid.

Bakgrund och typer av uppdateringar

Det finns tre typer av uppdateringar för AKS och var och en bygger på den tidigare uppdateringen:

Uppdateringstyper

• Säkerhetskorrigeringar för Nodoperativsystem (endast Linux): För Linux-noder gör både Canonical Ubuntu och Azure Linux säkerhetskorrigeringar för operativsystem tillgängliga en gång om dagen. Microsoft testar och paketar dessa korrigeringar i veckouppdateringarna till nodbilder.

• Veckovisa uppdateringar av nodbilder: AKS tillhandahåller veckovisa uppdateringar av nodbilder. De här uppdateringarna omfattar de senaste säkerhetskorrigeringarna för operativsystem och AKS, felkorrigeringar och förbättringar. Noduppdateringar ändrar inte Kubernetes-versionen. Versioner formateras efter datum (till exempel 202311.07.0) för Linux och av Windows Server OS build and date (till exempel 20348.2113.231115) för Windows. Mer information finns i AKS-versionsstatus.

• Kvartalsvisa Kubernetes-versioner: AKS tillhandahåller kvartalsuppdateringar för Kubernetes-versioner. Dessa uppdateringar gör det möjligt för AKS-användare att använda de senaste Kubernetes-funktionerna och förbättringarna, till exempel säkerhetskorrigeringar och uppdateringar av nodbilder. Mer information finns i Kubernetes-versioner som stöds i AKS.

Överväganden före uppgradering

Innan du uppgraderar dina AKS-arbetsnoder och Kubernetes-versioner bör du överväga följande effekter och metodtips.

Övergripande klusterpåverkan

• Uppgraderingar på plats för noder och kluster påverkar prestandan för Kubernetes-miljön medan de pågår. Du kan minimera den här effekten genom korrekt konfiguration av budgetar för poddstörningar, konfiguration av nodtoppar och korrekt planering.

• Blågröna uppdateringsstrategier påverkar inte klusterprestanda, men de ökar kostnaderna och komplexiteten.

• Oavsett din uppgraderings- och korrigeringsstrategi måste du ha en robust test- och valideringsprocess för klustret. Korrigera och uppgradera lägre miljöer först och utför en validering efter underhåll för att kontrollera kluster, nod, distribution och programhälsa.

Metodtips för AKS-arbetsbelastning

Följ dessa metodtips för att säkerställa att AKS-klustret fungerar smidigt under underhåll:

• Definiera budgetar för poddstörningar (PDB). Det är viktigt att du konfigurerar PBD:er för dina distributioner. PDB:er framtvingar ett minsta antal tillgängliga programrepliker för att säkerställa kontinuerliga funktioner under avbrottshändelser. PDB:er hjälper till att upprätthålla stabiliteten i klustret vid underhåll eller nodfel.

  Varning

  Felkonfigurerade PDF-filer kan blockera uppgraderingsprocessen eftersom Kubernetes-API:et förhindrar nödvändig avspärrning och dränering som inträffar med en löpande nodavbildningsuppgradering. Om för många poddar flyttas samtidigt kan dessutom ett programfel inträffa. Korrekt PDB-konfiguration minskar den här risken.

• Kontrollera tillgängliga beräknings- och nätverksgränser. Kontrollera tillgängliga beräknings- och nätverksgränser i din Azure-prenumeration via kvotsidan i Azure Portal eller med kommandot az quota. Kontrollera beräknings- och nätverksresurser, särskilt virtuella dator-vCPU:er för dina noder, samt antalet virtuella datorer och vm-skalningsuppsättningar. Om du är nära en gräns begär du en kvotökning innan du uppgraderar.

• Kontrollera tillgängligt IP-adressutrymme i nodundernät. Under uppdateringar skapas extra överbelastningsnoder i klustret och poddar flyttas till dessa noder. Det är viktigt att du övervakar IP-adressutrymmet i nodundernäten för att säkerställa att det finns tillräckligt med adressutrymme för att ändringarna ska kunna ske. Olika Kubernetes-nätverkskonfigurationer har olika IP-adresskrav. Börja med att läsa följande överväganden:

  • Under en uppgradering ökar antalet nod-IP-adresser enligt ditt överspänningsvärde. Det minsta överspänningsvärdet är 1.
  • Kluster som baseras på Azure Container Network Interface tilldelar IP-adresser till enskilda poddar, så det måste finnas tillräckligt med adressutrymme för poddförflyttning.
  • Klustret fortsätter att fungera under uppgraderingarna. Se till att tillräckligt med IP-adressutrymme finns kvar för att tillåta nodskalning.

• Konfigurera flera miljöer. Konfigurera flera Kubernetes-miljöer, till exempel utvecklings-, mellanlagrings- och produktionsmiljöer. Med den här separationen kan du testa och verifiera ändringar helt innan du flyttar dem till produktion. Validering är särskilt viktigt när du flyttar mellan flera versioner av AKS, till exempel från 1.28 till 1.31.

• Planera och schemalägg underhållsperioder. Uppgraderingsprocesser kan påverka den övergripande prestandan för ditt Kubernetes-kluster. Schemalägg uppgraderingsprocesser på plats utanför användningstoppar och övervaka klusterprestanda för att säkerställa lämplig storleksändring, särskilt under uppdateringsprocesser.

• Optimera kluster för odränerbart nodbeteende. Som standard, om en nod inte kan tömmas, misslyckas även uppdateringen på klustret. För att lösa det här problemet bör du konfigurera avspärrning av nodavlopp. Den här processen placerar oanvändbara noder i karantän och gör att klustret kan uppgraderas. Sedan kan du åtgärda de noder som inte kunde uppdateras manuellt genom att korrigera eller ta bort dem.

• Justera överspänningsuppgraderingsvärden. AKS har som standard ett överspänningsvärde på 1, vilket innebär att en extra nod skapas i taget som en del av uppgraderingsprocessen. Du kan öka hastigheten för en AKS-uppgradering genom att öka det här värdet. Det rekommenderade högsta överbelastningsvärdet för arbetsbelastningar som är känsliga för störningar är 33%. Mer information finns i Anpassa uppgradering av nodtoppar.

• Justera tidsgränsen för noddränering.Tidsgränsen för noddränering anger den maximala tid som ett kluster väntar medan en arbetsbelastning försöker schemalägga om poddar på en nod som uppdateras. Standardvärdet är 30 minuter. För arbetsbelastningar som har svårt att schemalägga om poddar kan det vara till hjälp att öka det här värdet.

• Tidsgränsen för att justera noden är slut. Som standard flyttas nodens genomblötningskonfiguration till att återskapa nästa nod när en nod har slutfört uppdateringsprocessen. För vissa äldre eller känsliga arbetsbelastningar kan det vara fördelaktigt att lägga till en fördröjning innan du går vidare till nästa nod. Lägg till en fördröjning genom att konfigurera en nodens fördröjningstid.

• Kontrollera andra beroenden i klustret. Kubernetes-operatorer distribuerar ofta andra verktyg till Kubernetes-klustret som en del av åtgärder, till exempel KEDA-skalare, DAPR och tjänstnät. När du planerar dina uppgraderingsprocesser kontrollerar du viktig information för alla komponenter som du använder för att säkerställa kompatibilitet med målversionen.

• Justera efter AKS-zonindelningskonfigurationer. För zonindelade AKS-kluster kan överbelastningsuppgradningen tillfälligt resultera i en obalanserad fördelning av arbetsbelastningar mellan zoner. För att förhindra det här scenariot anger du överspänningsvärdet till en multipel av tre, till exempel 33% ökning.

Hantera veckovisa uppdateringar av nodbilder

Microsoft skapar en ny nodbild för AKS-noder ungefär en gång i veckan. En nodavbildning innehåller uppdaterade säkerhetskorrigeringar för operativsystemet, uppdateringar av operativsystemkärnor, Kubernetes-säkerhetsuppdateringar, uppdaterade versioner av binärfiler som kubelet och komponentversionsuppdateringar som visas i viktig information.

När en nodavbildning uppdateras utlöses en avspärrnings- och avloppsåtgärd på målnodpoolens noder:

1. En nod med den uppdaterade avbildningen läggs till i nodpoolen. Överspänningsvärdet styr hur många noder som läggs till samtidigt.
2. Beroende på överspänningsvärdet är en batch med befintliga noder avspärrad och tömd. Avspärrning säkerställer att noden inte schemalägger poddar. Tömning tar bort poddar och schemalägger dem till andra noder.
3. När dessa noder är helt tömda tas de bort från nodpoolen. De uppdaterade noderna som lagts till av överspänningen ersätter dem.
4. Den här processen upprepas för varje återstående batch med noder som måste uppdateras i nodpoolen.

En liknande process inträffar under en klusteruppgradering.

Automatiska nodbilduppgraderingar

I allmänhet bör de flesta kluster använda uppdateringskanalen NodeImage . Den här kanalen tillhandahåller en uppdaterad virtuell hårddisk för nodavbildningar (VHD) varje vecka och uppdateras enligt klustrets underhållsperiod.

De tillgängliga kanalerna är:

• None. Inga uppdateringar tillämpas automatiskt.

• Unmanaged. Operativsystemet tillämpar Ubuntu- och Azure Linux-uppdateringar varje natt. Omstarter måste hanteras separat. AKS kan inte testa eller kontrollera de här uppdateringarnas takt.

• SecurityPatch. Operativsystemet distribuerar säkerhetskorrigeringar som är AKS-testade, fullständigt hanterade och använder säkra distributionsmetoder. Den här korrigeringen innehåller inga felkorrigeringar för operativsystemet. Den innehåller bara säkerhetsuppdateringar.

• NodeImage. AKS uppdaterar noderna med en nyligen korrigerad virtuell hårddisk som innehåller säkerhetskorrigeringar och buggkorrigeringar vid en veckovis takt. Dessa uppdateringar testas och distribueras fullständigt med hjälp av säkra distributionsmetoder. Information i realtid om för närvarande distribuerade nodbilder finns i AKS-nodbilduppdateringar.

Information om standardtendenser utan ett etablerat underhållsfönster finns i Uppdatera ägarskap och schema.

Om du väljer uppdateringskanalen Unmanaged måste du hantera omstartsprocessen med hjälp av ett verktyg som kured. Kanalen Unmanaged levereras inte med säkra distributionsmetoder som tillhandahålls av AKS och fungerar inte under underhållsperioder.

Om du väljer uppdateringskanal SecurityPatch kan du tillämpa uppdateringar så ofta som varje vecka. Den här korrigeringsnivån kräver att de virtuella hårddiskarna lagras i resursgruppen, vilket medför en nominell avgift. Om du vill styra när SecurityPatch används anger du en aksManagedNodeOSUpgradeSchedule takt som fungerar bäst för din arbetsbelastning. Om du också behöver felkorrigeringar som vanligtvis levereras med nya nodbilder (VHD) måste du välja NodeImage-kanalen istället för SecurityPatch.

Mer information finns i Använda planerat underhåll för att schemalägga och kontrollera uppgraderingar för ditt AKS-kluster.

Vi rekommenderar att du använder uppdateringskanalen NodeImage och konfigurerar ett aksManagedNodeOSUpgradeSchedule underhållsperiod till en tidpunkt då klustret ligger utanför användningsperioder med hög belastning. Attribut som du kan använda för att konfigurera klusterunderhållsfönstret finns i Skapa ett underhållsfönster. Nyckelattributen är:

• name. Används aksManagedNodeOSUpgradeSchedule för uppdateringar av nodoperativsystem.

• utcOffset. Konfigurera tidszonen.

• startTime. Ange starttiden för underhållsperioden.

• dayofWeek. Ange veckodagarna för fönstret. Exempel: Saturday

• schedule. Ange frekvensen för fönstret. För NodeImage uppdateringar rekommenderar weeklyvi .

• durationHours. Ange det här attributet till minst fyra timmar.

I följande exempel anges en veckovis underhållsperiod till 20:00 eastern time på lördagar:

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

Den här konfigurationen är bäst implementerad som en del av infrastruktur-som-kod-distributionen av klustret.

Fler exempel finns i Lägga till en underhållsfönsterkonfiguration.

Du kan söka efter konfigurerade underhållsperioder med hjälp av Azure CLI:

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

Du kan också kontrollera information om ett visst underhållsperiod med hjälp av CLI:

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

Om ett klusterunderhållsfönster inte har konfigurerats sker uppdateringar av nodavbildningen varannan vecka. AKS-underhåll sker i det konfigurerade fönstret så mycket som möjligt, men underhållstiden är inte garanterad.

Om du vill övervaka status för uppdateringar automatiskt kan du använda AKS-kommunikationshanteraren för att tillhandahålla automatiska aviseringar för planerade underhållsaktiviteter. Du kan också övervaka direkt via Azure Monitor-aktivitetsloggar eller genom att granska resursloggarna i klustret via kubectl get events.

Prenumerera på AKS-händelser med Azure Event Grid för att hämta AKS-uppgraderingshändelser. Dessa händelser kan varna dig när en ny version av Kubernetes är tillgänglig och hjälpa dig att spåra nodstatusändringar under uppgraderingsprocesser.

Du kan också hantera uppdateringsprocessen varje vecka med hjälp av GitHub Actions. Den här metoden ger mer detaljerad kontroll över uppdateringsprocessen.

Manuell noduppdateringsprocess

Du kan använda kommandot kubectl describe nodes för att fastställa operativsystemkärnversionen och operativsystemavbildningsversionen av noderna i klustret:

kubectl describe nodes <NodeName>

Exempelutdata (trunkerade):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.173.1-1.cm2
  OS Image:                   CBL-Mariner/Linux
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.6.26
  Kubelet Version:            v1.31.3
  Kube-Proxy Version:         v1.31.3

Använd kommandot Azure CLI az aks nodepool list för att fastställa nodavbildningsversionerna av noderna i ett kluster:

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

Exempel på utdata>

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

Använd kommandot az aks nodepool get-upgrades för att fastställa den senaste tillgängliga nodbildversionen för en specifik nodpool:

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

Exempel på utdata>

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V2gen2-202501.12.0
user    AKSAzureLinux-V2gen2arm64-202501.12.0

Klusteruppgraderingar

Kubernetes-communityn släpper mindre versioner av Kubernetes ungefär var tredje månad. För att hålla dig informerad om nya AKS-versioner och -versioner uppdateras sidan med AKS-viktig information regelbundet. Du kan också prenumerera på GitHub AKS RSS-flödet, som innehåller realtidsuppdateringar om ändringar och förbättringar.

AKS följer en N-2-supportprincip , vilket innebär att fullständigt stöd ges för den senaste versionen (N) och de två tidigare delversionerna. Begränsad plattformssupport erbjuds för den tredje tidigare delversionen. Mer information finns i Supportprinciper för AKS.

För att säkerställa att dina AKS-kluster fortfarande stöds måste du upprätta en kontinuerlig klusteruppgraderingsprocess. Den här processen omfattar testning av nya versioner i lägre miljöer och planering av uppgraderingen till produktion innan den nya versionen blir standard. Den här metoden hjälper till att upprätthålla förutsägbarhet i uppgraderingsprocessen och minimerar avbrott i program. Mer information finns i Uppgraderingsalternativ för AKS-kluster.

Om klustret kräver en längre uppgraderingscykel använder du AKS-versioner som stöder alternativet Långsiktig support (LTS). Om du aktiverar LTS-alternativet ger Microsoft utökat stöd för Kubernetes-versioner i två år, vilket möjliggör en mer långvarig och kontrollerad uppgraderingscykel. Mer information finns i Kubernetes-versioner som stöds i AKS.

En klusteruppgradering innehåller en noduppgradering och använder en avspärrnings- och avrinningsprocess.

Innan du uppgraderar

Som bästa praxis bör du alltid uppgradera och testa i lägre miljöer för att minimera risken för avbrott i produktionen. Klusteruppgraderingar kräver extra testning eftersom de omfattar API-ändringar, vilket kan påverka Kubernetes-distributioner. Följande resurser kan hjälpa dig i uppgraderingsprocessen.

• AKS-arbetsbok för inaktuella API:er: På klusteröversiktssidan i Azure-portalen väljer du Diagnostisera och lösa problem, går till kategorin Skapa, Uppgradera, Ta bort och Skala och väljer sedan Kubernetes API-utfasningar. Den här proceduren kör en arbetsbok som söker efter inaktuella API-versioner som klustret fortfarande använder. Mer information finns i Ta bort användning av inaktuella API:er.

• AKS release-noteringar sidan: Den här sidan innehåller omfattande information om nya AKS-versioner och -utgåvor. Granska dessa anteckningar för att hålla dig informerad om de senaste uppdateringarna och ändringarna.

• Kubernetes versionsanmärkningssida: Den här sidan innehåller detaljerade insikter om de senaste Kubernetes-versionerna. Var särskilt uppmärksam på brådskande uppgraderingsanteckningar. De belyser viktig information som kan påverka ditt AKS-kluster.

• IKS-komponenter: icke-bakåtkompatibla ändringar per version: Den här tabellen innehåller en omfattande översikt över icke-bakåtkompatibla ändringar i AKS-komponenter efter version. Genom att referera till den här guiden kan du proaktivt åtgärda eventuella kompatibilitetsproblem före uppgraderingsprocessen.

Utöver dessa Microsoft-resurser bör du överväga att använda verktyg med öppen källkod för att optimera klusteruppgraderingsprocessen. Ett sådant verktyg är Fairwinds pluto, som kan skanna dina distributioner och Helm-diagram efter inaktuella Kubernetes-API:er. Dessa verktyg kan hjälpa dig att se till att dina program förblir kompatibla med de senaste Kubernetes-versionerna.

Uppgraderingsprocess

Om du vill kontrollera när klustret kräver en uppgradering använder du kommandot az aks get-upgrades för att hämta en lista över tillgängliga uppgraderingsversioner för ditt AKS-kluster. Fastställa målversionen för klustret från resultaten.

Här är ett exempel:

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

Exempel på utdata>

MasterVersion  Upgrades
-------------  ---------------------------------
1.30.7         1.31.1, 1.31.2, 1.31.3

Kontrollera Kubernetes-versionerna av noderna i nodpoolerna för att hitta de pooler som behöver uppgraderas:

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

Exempel på utdata>

Name          K8version
------------  ------------
systempool    1.30.7
usernodepool  1.30.7

Manuella uppgraderingar

Utför den här uppgraderingsmetoden för att minimera störningar och säkerställa en smidig uppgradering av AKS-klustret:

1. Uppgradera AKS-kontrollplanet. Uppgradera de kontrollplanskomponenter som ansvarar för att hantera och samordna klustret. Uppgradera kontrollplanet först för att säkerställa kompatibilitet och stabilitet innan du uppgraderar de enskilda nodpoolerna.

2. Uppgradera systemnodpoolen. När du har uppgraderat kontrollplanet uppgraderar du systemnodpoolen i AKS-klustret. Nodpooler består av de virtuella datorinstanser som kör dina programarbetsbelastningar. Att uppgradera nodpoolerna separat möjliggör en kontrollerad och systematisk uppgradering av den underliggande infrastrukturen som stöder dina program.

3. Uppgradera användarnodpooler. När du har uppgraderat systemnodpoolen uppgraderar du alla användarnodpooler i AKS-klustret.

Genom att följa den här metoden kan du minimera störningar under uppgraderingsprocessen och upprätthålla tillgängligheten för dina program. Utför följande steg:

1. Kör kommandot az aks upgrade med --control-plane-only flaggan för att endast uppgradera klusterkontrollplanet och inte klustrets nodpooler:

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

2. Kör kommandot az aks nodepool upgrade för att uppgradera nodpooler till målversionen:

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

   Under uppgraderingen av nodpoolen skapar AKS en tillfällig nod, spärrar av och tömmer poddar i noden som uppgraderas, återbildar noden och tar sedan bort avspärrningen för noden. Den här processen upprepas för de andra noderna i nodpoolen.

Du kan kontrollera status för uppgraderingsprocessen genom att köra kubectl get events. Information om hur du felsöker problem med klusteruppgradering finns i dokumentationen för AKS-felsökning.

Registrera kluster i lanseringskanaler för automatisk uppgradering

AKS tillhandahåller också en automatisk klusteruppgraderingslösning för att hålla klustret uppdaterat. Om du använder den här lösningen bör du para ihop den med ett underhållsfönster för att styra tidpunkten för uppgraderingar. Uppgraderingsfönstret måste vara fyra timmar eller mer. När du registrerar ett kluster i en versionskanal hanterar Microsoft automatiskt version och uppgraderingstakt för klustret och dess nodpooler.

Klustrets automatiska uppgradering innehåller olika alternativ för releaserkanaler. Här är en rekommenderad miljö och versionskanalkonfiguration:

Att tänka på

I följande tabell beskrivs egenskaperna för olika AKS-uppgraderings- och korrigeringsscenarier.

• En os-säkerhetskorrigering som tillämpas som en del av en nodavbildningsuppgradering kan installera en senare version av kerneln än när ett nytt kluster skapas.

• Uppskalning av nodpooler använder den modell som för närvarande är associerad med vm-skalningsuppsättningen. OS-kernels uppgraderas när säkerhetskorrigeringar tillämpas och noderna startas om.

Deltagare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Anthony Nevico | Huvudarkitekt för molnlösning

Övriga medarbetare:

• Rishabh Saha | Huvudlösningsarkitekt
• Paolo Salvatori | Huvudkundtekniker, FastTrack för Azure
• Ali Yousefi | Molnlösningsarkitekt

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• DOKUMENTATION om AKS-produkter
• AKS-versionsspårare
• AKS-översikt
• Felsöka AKS-problem
• Optimera AKS-uppgraderingar
• Vanliga frågor och svar om Node OS-uppgradering
• Definiera dag-2-åtgärder
• En praktisk guide för zonredundanta AKS-kluster
• Vägledning för Cloud Adoption Framework för att införa AKS i en Azure-landningszon

Relaterade resurser

• Aks dag-2-driftguide
• AKS-sorteringsmetoder