Kubernetes-versioner som stöds i Azure Kubernetes Service (AKS)

Kubernetes-communityn släpper mindre versioner ungefär var fjärde månad.

Delversioner innehåller nya funktioner och förbättringar. Korrigeringsversioner är vanligare (ibland varje vecka) och är avsedda för kritiska felkorrigeringar i en delversion. Korrigeringsversioner omfattar korrigeringar för säkerhetsrisker eller större buggar.

Kubernetes-versioner

Kubernetes använder standardschemat för semantisk versionshantering för varje version:

[major].[minor].[patch]

Varje tal i versionen återspeglar kompatibilitet med tidigare versioner:

• Huvudversioner: Introducera inkompatibla API-ändringar eller bryta bakåtkompatibiliteten.
• Delversioner: Lägg till nya funktioner. Stabila API:er är vanligtvis kompatibla, men inaktuella API:er och funktioner kan tas bort enligt Kubernetes utfasningsprincip.
• Korrigeringsversioner: Inkludera bakåtkompatibla felkorrigeringar.

Använd alltid den senaste korrigeringsversionen för den aktuella delversionen. När en senare korrigering blir tillgänglig för din delversion uppgraderar du så snart som möjligt för att säkerställa att klustret är helt korrigerat och stöds.

AKS Kubernetes-versionskalender och kommande versioner

Kontrollera AKS Kubernetes-versionskalendern för kommande versioner. Om du vill se uppdateringar i realtid av regionens versionsstatus och versionsanteckningar går du till webbsidan för AKS-versionsstatus. Mer information om webbsidan för versionsstatus finns i AKS-versionsspåraren.

Tidigare versionshistorik finns i Kubernetes-historik.

LTS-versioner

Du måste aktivera långsiktig support (LTS) för att få utökad support. Mer information finns i Aktivera långsiktigt stöd.

Gantt-schema för AKS Kubernetes-versionsschema

Följande Gantt-schema visar de aktuella versionerna:

AKS-komponenternas förändringar per version

Observera följande viktiga ändringar innan du uppgraderar till någon av de tillgängliga delversionerna:

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Alias för delversion i AKS

Du kan skapa ett AKS-kluster utan att ange en korrigeringsversion. När du skapar ett kluster utan att ange en korrigering kör klustret delversionens senaste GA-korrigering. Om du vill uppgradera korrigeringsversionen i samma delversion använder du autoupgrade.

Kör az aks show --resource-group myResourceGroup --name myAKSCluster-kommandot för att se vilken patch du är på. I utdata currentKubernetesVersion visar egenskapen hela Kubernetes-versionen. Till exempel:

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "<major>.<minor>.<patch>",
}

Princip för versionsstöd av Kubernetes-versioner

AKS definierar en allmänt tillgänglig version (GA) som en version som är tillgänglig i alla regioner och aktiverad i alla SLO- eller SLA-mått. AKS stöder tre ga-delversioner av Kubernetes:

• Den senaste GA-versionen (N).
• De två tidigare delversionerna (N-1 och N-2).
  • Varje delversion som stöds kan ha stöd för valfritt antal korrigeringar vid en viss tidpunkt. AKS förbehåller sig rätten att avveckla korrigeringar om en kritisk CVE eller säkerhetsrisk upptäcks. För information om tillgänglighet för korrigeringar och eventuell ad hoc-baserad utfasning, se versionsanteckningarna och besök webbsidan för AKS-versionsstatus.

AKS kan också ha stöd för förhandsversioner som uttryckligen är märkta och omfattas av förhandsversionsvillkor.

AKS tillhandahåller plattformsstöd endast för en GA-minorversion av Kubernetes efter de ordinarie stödda versionerna. Plattformssupportfönstret för Kubernetes-versioner på AKS kallas N-3. Mer information finns i plattformssupportpolicy.

Fönstret som stöds i Kubernetes-delversioner på AKS kallas N-2, där N refererar till den senaste versionen, vilket innebär att två tidigare mindre versioner också stöds.

Den dag då AKS introducerar version 1.29 ges till exempel stöd för följande versioner:

När en ny delversion introduceras är den äldsta delversionen inaktuell och borttagen. Anta till exempel att den aktuella delversionslistan som stöds är 1.29, 1.28 och 1.27. När AKS släpper 1.30 upphör alla 1.27-versioner att ha support 30 dagar senare.

AKS kan ha stöd för valfritt antal korrigeringar baserat på tillgänglighet av community-utgåvor från uppströms för en specifik delversion. AKS förbehåller sig rätten att avskriva någon av dessa patchar när som helst på grund av en CVE eller ett potentiellt buggproblem. Vi rekommenderar att du använder den senaste patchen för en mindre version.

Plattformsstödprincip

Princip för plattformsstöd är en reducerad supportplan för vissa icke-stödda Kubernetes-versioner. Under plattformssupporten får kunderna endast support från Microsoft för AKS/Azure-plattformsrelaterade problem. Eventuella problem som rör Kubernetes-funktioner och komponenter stöds inte.

Plattformsstödprincipen gäller för kluster i en N-3-version (där N är den senaste versionen av AKS GA-delversionen som stöds) innan klustret sjunker till N-4. Kubernetes v1.26 betraktas till exempel som plattformsstöd när v1.29 är den senaste GA-versionen. Anta att du kör en N-2-version . I samma ögonblick som den versionen blir N-3 upphör även dess officiella support och du går in i plattformssupportpolicyn.

AKS förlitar sig på versioner och korrigeringar från Kubernetes, som är ett projekt med öppen källkod som endast stöder ett skjutfönster med tre delversioner. AKS kan bara garantera fullständigt stöd medan dessa versioner hanteras uppströms. Eftersom det inte längre produceras några korrigeringar uppströms kan AKS antingen lämna dessa versioner okorrigerade eller göra en avgrening. På grund av denna begränsning kan plattformssupporten inte stödja något som bygger på Kubernetes uppströms.

I följande tabell beskrivs riktlinjer för support för communitystöd jämfört med plattformsstöd:

Versioner som stöds kubectl

Du kan använda en kubectl version som är en delversion som är äldre eller nyare än kube-apiserver-versionen. För mer information, se Kubernetes-supportprincipen för kubectl.

Om kube-apiservern till exempel är på 1.28 kan du använda versionerna 1.27 till 1.29 av kubectl.

Om du vill installera eller uppdatera kubectl till den senaste versionen använder du kommandot baserat på önskat verktyg:

az aks install-cli

Install-AzAksKubectl -Version latest

Långsiktigt stöd (LTS)

AKS erbjuder ett års communitystöd och ett års långsiktig support (LTS), inklusive säkerhetskopierade säkerhetskorrigeringar från den överordnade communityn. Vår överordnade LTS-arbetsgrupp bidrar med insatser tillbaka till communityn för att ge våra kunder ett längre supportfönster.

Mer information om LTS finns i Långsiktigt stöd för Azure Kubernetes Service (AKS).

Process för lansering och avveckling

Kommande versioner och utfasningar finns i AKS Kubernetes-versionskalendern.

För nya delversioner av Kubernetes:

• AKS meddelar nya versionsdatum och gammal versionsutfasning i AKS-versionsanteckningarna minst 30 dagar före borttagningen.

• AKS använder Azure Advisor för att varna dig om en ny version kan orsaka problem i klustret på grund av inaktuella API:er. Azure Advisor varnar dig också om du inte har support.

• AKS publicerar ett meddelande om tjänstens hälsotillstånd som är tillgängligt för alla användare med ÅTKOMST till AKS och portalen och skickar ett e-postmeddelande till prenumerationsadministratörerna med de planerade datumen för versionsborttagning.

  Note

  Information om hur du visar eller ändrar dina prenumerationsadministratörer finns i Hantera Azure-prenumerationer.

• Du har 30 dagar på dig från versionsborttagningen för att uppgradera till en delversion som stöds för att fortsätta få support.

För nya korrigeringsversioner av Kubernetes:

• På grund av korrigeringsversionernas brådskande karaktär kan de introduceras i tjänsten när de blir tillgängliga. När de väl är tillgängliga har patchar en minimal livscykel på två månader.
• Generellt sprider AKS inte bred information om nya patch-versioner. AKS övervakar och validerar dock ständigt tillgängliga CVE-korrigeringar för att stödja dem i AKS i tid. Om en kritisk korrigering hittas eller om användaråtgärd krävs meddelar AKS dig att uppgradera till den nyligen tillgängliga korrigeringen.
• Du har 30 dagar på dig från att en korrigeringsversion har tagits bort från AKS för att uppgradera till en korrigering som stöds och fortsätta att få support. Du kommer dock inte längre att kunna skapa kluster eller nodpooler när versionen är inaktuell/borttagen.

Undantag för policy om stöd av versioner

AKS förbehåller sig rätten att lägga till eller ta bort nya/befintliga versioner med en eller flera kritiska produktionspåverkande buggar eller säkerhetsproblem utan förvarning.

Specifika patch-versioner kan hoppas över eller utrullningen kan påskyndas, beroende på hur allvarlig buggen eller säkerhetsproblemet är.

Azure Portal- och CLI-versioner

Om du distribuerar ett AKS-kluster via Azure-portalen, Azure CLI eller Azure PowerShell använder klustret som standard delversionen N-1 och den senaste patchversionen.

Om du vill ta reda på vilka versioner som är tillgängliga för din prenumeration och region använder du kommandot baserat på önskat verktyg:

# The following example lists the available Kubernetes versions for the EastUS region:

az aks get-versions --location eastus --output table

# The following example lists the available Kubernetes versions for the EastUS region:

Get-AzAksVersion -Location eastus

Vanliga frågor (FAQ)

Hur meddelar Microsoft mig om nya Kubernetes-versioner?

AKS-teamet meddelar nya lanseringsdatum för Kubernetes-versionen i vår dokumentation, på GitHub och via e-post till prenumerationsadministratörer med kluster som närmar sig slutet av supporten. AKS använder också Azure Advisor för att varna dig i Azure Portal om du inte har support och informera dig om inaktuella API:er som kan påverka din program- eller utvecklingsprocess.

Hur ofta ska jag förvänta mig att uppgradera Kubernetes-versioner för att behålla supporten?

Från och med Kubernetes 1.19 utökade det öppna källkodssamhället sitt stöd till ett år. AKS åtar sig att möjliggöra korrigeringar och stöd som motsvarar uppströmsåtagandena. För AKS-kluster på 1.19 och senare kan du uppgradera minst en gång om året för att behålla en version som stöds.

Vad händer när du uppgraderar ett Kubernetes-kluster med en delversion som inte stöds?

Om din version inte stöds enligt listan med Kubernetes-versioner som stöds måste du uppgradera. Du kan uppgradera från versioner som inte stöds till versioner som stöds. Till exempel:

• Om den lägsta versionen av AKS-delversionen som stöds är 1.33 och du är på 1,32 eller äldre är du utanför supporten.
• Om du uppgraderar från 1.32 till 1.33 eller senare är du tillbaka inom supportprinciperna.

Nedgradering eller återställning till en version som inte stöds stöds inte. Dessutom gäller att ju längre klusterversionen ligger från den lägsta version som stöds, desto högre är sannolikheten för problem vid uppgradering. I så fall skulle det vara en bättre metod att skapa ett nytt kluster och en migrering av arbetsbelastningar.

Vad innebär det att vara "utanför supporten"?

Utanför stödområdet innebär:

• Den version som du kör ligger utanför listan över versioner som stöds.
• Du uppmanas att uppgradera klustret till en version som stöds när du begär support, såvida du inte befinner dig inom respitperioden på 30 dagar efter versionsutfasningen.

Dessutom ger AKS inga körningsgarantier eller andra garantier för kluster utanför listan över versioner som stöds.

Kan du stanna på en Kubernetes-version för alltid?

Om ett kluster inte har stöd för fler än tre mindre versioner och medför säkerhetsrisker kontaktar Azure dig proaktivt. De rekommenderar att du uppgraderar klustret. Om du inte vidtar ytterligare åtgärder förbehåller sig Azure rätten att automatiskt uppgradera klustret åt dig.

Vad händer om du skalar ett Kubernetes-kluster med en delversion som inte stöds?

För mindre versioner som inte stöds av AKS bör in- eller utskalning fortsätta att fungera. Eftersom det inte finns några garantier för tjänstekvalitet rekommenderar vi att du uppgraderar för att återfå klusterstödet.

Vilken version stöder kontrollplanet om nodpoolen inte finns i någon av de AKS-versioner som stöds?

Kontrollplanet och alla nodpooler måste ligga inom det intervall för versionsavvikelse som stöds. Från och med Kubernetes 1.28 kan kontrollplanet ligga upp till tre mindre versionssteg före nodpoolerna. Mer information finns i uppgraderingsreglerna för Kubernetes-versionen.

Vad är den tillåtna skillnaden i versioner mellan kontrollplanet och nodpoolerna?

Principen för versionsförskjutning tillåter nu en skillnad på upp till tre versioner mellan kontrollplans- och agentpooler. AKS följer den här skeva versionsprincipändringen från och med version 1.28.

Kan jag hoppa över flera AKS-versioner under en klusteruppgradering?

Ja, du kan hoppa över mindre versioner i vissa fall. Men om du uppgraderar kontrollplanet oberoende av nodpoolerna måste du uppfylla Kubernetes versionsförskjutningsprinciper. Kubernetes versionsförskjutningsprincip stöder för närvarande endast N-3, så kontrollplanet och agentpoolerna måste ligga inom N-3 från varandra.

• LTS: En version med AKS Long-Term Support-planen aktiverad. Se LTS-versionerna.
• LTS som inte stöds: En LTS-aktiverad version som har passerat sitt LTS-slutdatum i tabellen LTS-versioner .
• Icke-LTS som stöds: En version som inte är LTS men fortfarande visas som stöds i AKS Kubernetes-versionskalendern.
• Ej stödd icke-LTS: En version som inte är LTS och inte längre visas som stöds i AKS Kubernetes-versionskalendern.

Examples:

• Om klustret är på 1.29 LTS och du vill flytta till 1.32 LTS kan du hoppa över flera mindre versioner så länge 1.32 LTS fortfarande erbjuds av AKS och uppgraderingen uppfyller versionsförskjutnings- och verifieringskontroller.
• Om klustret är på 1.28 icke-LTS kan du gå över till AKS LTS 1.30 LTS med hjälp av den återställningsväg som inte stöds, så länge målversionen finns angiven av AKS, uppfyller valideringskontrollerna och du kör en fullständig klusteruppgradering snarare än control-plane-only.
• Om klustret finns på icke-LTS 1.33 som stöds och du vill flytta till icke-LTS 1.35 som stöds kan du inte hoppa direkt från 1.33 till 1.35. Du måste uppgradera en delversion åt gången, till exempel 1.33 till 1.34 och sedan 1.34 till 1.35.

I föregående tabell anger Unsupported recovery path att uppgraderingsvägen utförs på ett sätt som inte kan garanteras vara säkert och därför inte stöds. MED AKS kan uppgraderingen fortsätta, men den stöds inte och kan medföra risker.

Om du vill välja rätt sökväg kontrollerar du tillgängliga mål genom att köra az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Granska föregående tabell och ta sedan hänsyn till risken för att uppgradera jämfört med att återskapa klustret och migrera arbetsbelastningar.

Kan jag skapa ett nytt 1.xx.x-kluster under plattformssupportfönstret?

Nej, det går inte att skapa nya kluster under plattformssupportperioden.

Jag använder en nyligen föråldrad version som inte längre har plattformsstöd. Kan jag fortfarande lägga till nya nodpooler eller ska jag uppgradera?

Ja, du kan lägga till agentpooler så länge de är kompatibla med kontrollplanets version.

Relaterat innehåll

Information om AKS-klusteruppgraderingar finns i:

• Uppgradera ett AKS-kluster (Azure Kubernetes Service)
• Uppgradera flera AKS-kluster via Azure Kubernetes Fleet Manager