Dela via

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

  • Artikel

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, var och en bygger på nästa:

Uppdateringstyp Uppgraderingsfrekvens Planerat underhåll stöds Åtgärdsmetoder som stöds Mål Länk till dokumentationen
Säkerhetskorrigeringar för Node OS Nattlig Ja Automatisk (varje vecka), manuell/ohanterad (nattetid) Nod Automatisk uppgradering av nodbilder
Versionsuppgraderingar för nodbild Linux: Varje vecka
Windows: Varje månad		 Ja Automatisk, manuell Nodpool AKS-nodbilduppgradering
Uppgraderingar av Kubernetes-version (kluster) Varje kvartal Ja Automatisk, manuell Kluster- och nodpool AKS-klusteruppgradering

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 per dag. 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. Med de här uppdateringarna kan AKS-användare dra nytta av de senaste Funktionerna och förbättringarna i Kubernetes. De innehåller säkerhetskorrigeringar och uppdateringar av nodbild. Mer information finns i Kubernetes-versioner som stöds i AKS.

Överväganden före uppgradering

Övergripande klusterpåverkan

  • Uppgraderingar på plats (både nod och kluster) påverkar prestanda 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.
  • Att använda en blå/grön uppdateringsstrategi i stället för att uppgradera på plats eliminerar all påverkan på klusterprestanda, men ökar kostnaden 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 poddstörningar 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. PDB-konfigurationen 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, och 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-utrymme 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 ske. Olika Kubernetes-nätverkskonfigurationer har olika IP-krav. Som utgångspunkt bör du gå igenom 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 CNI tilldelar IP-adresser till enskilda poddar, så det måste finnas tillräckligt med IP-utrymme för poddförflyttning.
    • Klustret fortsätter att fungera under uppgraderingarna. Se till att det finns tillräckligt med IP-utrymme kvar för att tillåta nodskalning (om den är aktiverad).
  • Konfigurera flera miljöer. Vi rekommenderar att du konfigurerar separata miljöer, till exempel utveckling, mellanlagring och produktion, så att du kan testa och verifiera ändringar innan du distribuerar dem till produktion.
  • 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. 33 % ökning är det rekommenderade maximala värdet för arbetsbelastningar som är känsliga för störningar. Mer information finns i Anpassa uppgradering av nodtoppar.
  • Justera tidsgränsen för noddränering. Tidsgränsen för noddränering anger den maximala tiden som ett kluster väntar vid försök att schemalägga om poddar på en nod som uppdateras. Standardvärdet för detta är 30 minuter. För arbetsbelastningar som har svårt att schemalägga om poddar kan det vara bra att justera det här standardvärdet.
  • 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.
  • 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.

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:

  • En nod med den uppdaterade avbildningen läggs till i nodpoolen. Antalet noder som läggs till samtidigt styrs av överspänningsvärdet.
  • Beroende på överspänningsvärdet är en batch med befintliga noder avspärrade och tömda. Avspärrning säkerställer att noden inte schemalägger poddar. Tömning tar bort poddar och schemalägger dem till andra noder.
  • När noderna är helt tömda tas de bort från nodpoolen. De uppdaterade noderna som lagts till av överspänningen ersätter dem.
  • 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

Generellt sett bör de flesta kluster använda uppdateringskanalen NodeImage . Den här kanalen tillhandahåller en uppdaterad VHD för nodavbildning varje vecka och uppdateras enligt klustrets underhållsperiod.

Tillgängliga kanaler omfattar följande:

  • None. Inga uppdateringar tillämpas automatiskt.
  • Unmanaged. Ubuntu- och Azure Linux-uppdateringar tillämpas av operativsystemet varje natt. Omstarter måste hanteras separat. AKS kan varken testa detta eller kontrollera kadensen av detta.
  • SecurityPatch. Säkerhetskorrigeringar för operativsystem som är AKS-testade, fullständigt hanterade och tillämpade med säkra distributionsmetoder. Den innehåller inte några felkorrigeringar för operativsystem bara säkerhetsuppdateringar.
  • NodeImage. AKS uppdaterar noderna med en nyligen korrigerad virtuell hårddisk som innehåller säkerhetskorrigeringar och buggkorrigeringar varje vecka. Detta testas fullständigt och distribueras med säkra distributionsmetoder. Information i realtid om för närvarande distribuerade nodbilder finns i AKS-nodbilduppdateringar.

Information om standardtakterna utan att ett underhållsperiod har upprättats finns i Uppdatera ägarskap och takt.

Om du väljer uppdateringskanalen Unmanaged måste du hantera omstartsprocessen med hjälp av ett verktyg som kured. Unmanaged följer inte aks-tillhandahållna säkra distributionsmetoder och fungerar inte under underhållsperioder. Om du väljer uppdateringskanal SecurityPatch kan uppdateringar tillämpas 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. Kontrollera när SecurityPatch används genom att ange en lämplig inställning aksManagedNodeOSUpgradeSchedule som justeras efter en takt som fungerar bäst för din arbetsbelastning. Mer information finns i Skapa en underhållsperiod. Om du också behöver felkorrigeringar som vanligtvis kommer med nya nodbilder (VHD) måste du välja NodeImage kanalen i stället för SecurityPatch.

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. Se Skapa ett underhållsperiod för attribut som du kan använda för att konfigurera klusterunderhållsfönstret. 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 det här exemplet 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

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

Den här konfigurationen skulle helst distribueras som en del av distributionen av klustret med infrastruktur som kod.

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. Så mycket som möjligt sker AKS-underhåll inom det konfigurerade fönstret, men underhållstiden är inte garanterad.

Viktigt!

Om du har en nodpool med ett stort antal noder, men den inte har konfigurerats med nodökning, kanske den automatiska uppgraderingshändelsen inte utlöses. Nodbilder i en nodpool uppgraderas bara medan den uppskattade totala uppgraderingstiden är inom 24 timmar.

I den här situationen kan du överväga något av följande:

  • dela upp noder i olika nodpooler om din vCPU-kvot är nästan full och du inte kan öka vCPU-kvoten
  • konfigurera nodökning för att minska den uppskattade uppgraderingstiden om din vCPU-kvot räcker

Du kan kontrollera statusen för uppgraderingshändelser via dina Azure-aktivitetsloggar eller genom att granska resursloggarna i klustret.

Du kan prenumerera på Azure Kubernetes Service-händelser (AKS) med Azure Event Grid som innehåller AKS-uppgraderingshändelser. Dessa händelser kan varna dig när den nya versionen av Kubernetes är tillgänglig och hjälpa till 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.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

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 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>

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

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 två tidigare delversioner. Begränsad plattformssupport erbjuds för den tredje tidigare delversionen. Mer information finns i AKS-supportprincip.

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 kan upprätthålla förutsägbarhet i uppgraderingsprocessen och minimera störningar i program. Mer information finns i Uppgradera ett 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 liknande avspärrnings- och avtappningsprocess.

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 Portal kan du välja Diagnostisera och lösa problem, gå till kategorin Skapa, Uppgradera, Ta bort och Skala och sedan välja Kubernetes API-utfasningar. På så sätt körs en arbetsbok som söker efter inaktuella API-versioner som används i klustret. Mer information finns i Ta bort användning av inaktuella API:er.
  • SIDAN FÖR AKS-viktig information. Den här sidan innehåller omfattande information om nya AKS-versioner och -versioner. 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 som belyser viktig information som kan påverka ditt AKS-kluster.
  • AKS-komponenter som bryter ändringar efter 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 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.26.6         1.27.1, 1.27.3

Kontrollera Kubernetes-versionerna av noderna i nodpoolerna för att fastställa vilka 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.26.6
usernodepool  1.26.6

Uppgradera manuellt

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

  1. Uppgradera AKS-kontrollplanet. Börja med att uppgradera AKS-kontrollplanet. Det här steget omfattar uppgradering av de kontrollplanskomponenter som ansvarar för att hantera och orkestrera klustret. Att uppgradera kontrollplanet först hjälper till 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. Det här är de detaljerade stegen:

  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 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 överspänningsnod, avspärrningar och tömmer poddar i noden som uppgraderas, återskapar noden och avmarkerar sedan poddarna. Den här processen upprepas sedan för andra noder 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 versionskanaler för automatisk uppgradering

AKS erbjuder 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.

Den automatiska uppgraderingen av klustret erbjuder olika alternativ för versionskanaler. Här är en rekommenderad miljö och versionskanalkonfiguration:

Environment Uppgradera kanal beskrivning
Produktion stable För stabilitet och versionsmognad använder du den stabila eller vanliga kanalen för produktionsarbetsbelastningar.
Mellanlagring, testning, utveckling Samma som produktion Använd samma versionskanal som produktion för att säkerställa att dina tester är vägledande för den version som du ska uppgradera produktionsmiljön till.
Kontrollvärde rapid Om du vill testa de senaste Kubernetes-versionerna och nya AKS-funktioner eller API:er använder du rapid kanalen. Du kan förbättra din tid till marknaden när versionen i rapid befordras till den kanal som du använder för produktion.

Att tänka på

I följande tabell beskrivs egenskaperna för olika scenarier för AKS-uppgradering och korrigering:

Scenario Användarinitierad Kubernetes-uppgradering Uppgradering av OS-kernel Uppgradering av nodavbildning
Säkerhetskorrigering Nej Nej Ja, efter omstart Ja
Skapa kluster Ja Kanske Ja, om en uppdaterad nodavbildning använder en uppdaterad kernel Ja, i förhållande till ett befintligt kluster om en ny version är tillgänglig
Kubernetes-uppgradering av kontrollplan Ja Ja Nej Nej
Kubernetes-uppgradering av nodpool Ja Ja Ja, om en uppdaterad nodavbildning använder en uppdaterad kernel Ja, om en ny version är tillgänglig
Skalning av nodpool Ja Nej Nej Nej
Uppgradering av nodavbildning Ja Nej Ja, om en uppdaterad nodavbildning använder en uppdaterad kernel Ja
Automatisk uppgradering av kluster Nej Ja Ja, om en uppdaterad nodavbildning använder en uppdaterad kernel Ja, om en ny version är tillgänglig
  • En säkerhetskorrigering för operativsystem 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

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

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

Nästa steg