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]

Examples:
  1.29.2
  1.29.1

Varje tal i versionen anger allmän kompatibilitet med den tidigare versionen:

• Större versioner ändras när inkompatibla API-uppdateringar eller bakåtkompatibilitet kan brytas.
• Mindre versioner ändras när funktionsuppdateringar görs som är bakåtkompatibla med de andra mindre versionerna.
• Korrigeringsversioner ändras när bakåtkompatibla felkorrigeringar görs.

Sikta på att köra den senaste korrigeringsversionen av den delversion som du kör. Om ditt produktionskluster till exempel är på 1.29.1 och 1.29.2 är den senaste tillgängliga korrigeringsversionen som är tillgänglig för 1.29-delversionen bör du uppgradera till 1.29.2 så snart som möjligt för att säkerställa att klustret är helt korrigerat och stöds.

AKS Kubernetes-versionskalender

Visa kommande versioner i AKS Kubernetes-versionskalendern. Om du vill se uppdateringar i realtid av regionens versionsstatus och viktig information om versioner 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

Gantt-schema för AKS Kubernetes-versionsschema

Om du föredrar att se den här informationen visuellt, här är ett Gantt-schema med alla aktuella versioner som visas:

AKS-komponenter som bryter ändringar efter version

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

Kubernetes 1.30

Kubernetes 1.29

Kubernetes 1.28

Kubernetes 1.27

Alias-delversion

Med AKS kan du skapa ett kluster utan att ange den exakta korrigeringsversionen. När du skapar ett kluster utan att ange en korrigering kör klustret delversionens senaste GA-korrigering. Om du till exempel skapar ett kluster med 1.29 och 1.29.2 är den senaste tillgängliga ga'd-korrigeringen skapas klustret med 1.29.2. Om du vill uppgradera korrigeringsversionen i samma delversion använder du automatisk uppgradering.

Kör kommandot för att se vilken korrigering du är på az aks show --resource-group myResourceGroup --name myAKSCluster . Egenskapen currentKubernetesVersion visar hela Kubernetes-versionen.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "1.29.2",
}

Stödprincip för Kubernetes-version

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-delversionen som släpptes i AKS (som vi kallar N).
• Två tidigare delversioner.
  • 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 inaktuella korrigeringar om en kritisk CVE eller säkerhetsrisk identifieras. Information om korrigeringstillgänglighet och eventuell ad hoc-utfasning finns i versionsanteckningar 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-delversion av Kubernetes efter de vanliga versioner som stöds. Plattformssupportfönstret för Kubernetes-versioner på AKS kallas "N-3". Mer information finns i plattformssupportprincip.

Det fönster 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
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å uppströms tillgänglighet för community-versioner för en viss delversion. AKS förbehåller sig rätten att förskriva någon av dessa korrigeringar vid en viss tidpunkt på grund av en CVE eller potentiellt buggproblem. Du uppmanas alltid att använda den senaste korrigeringen för en delversion.

Plattformsstödprincip

Plattformsstödprincip är en reducerad supportplan för vissa Kubernetes-versioner som inte stöds. 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ödprincip 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. Men under v1.30 GA-versionen uppgraderas v1.26 automatiskt till v1.27. Om du kör en n-2-version blir den även inaktuell när den blir n-3 och du anger plattformssupportprincipen.

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 mindre versioner. AKS kan bara garantera fullständigt stöd medan dessa versioner hanteras uppströms. Eftersom det inte finns några fler korrigeringar som skapas uppströms kan AKS antingen lämna dessa versioner okopplade eller förgrena sig. På grund av den här begränsningen stöder plattformssupport inte något från att förlita sig på Kubernetes uppströms.

Den här tabellen beskriver riktlinjer för support för communitystöd jämfört med plattformsstöd.

Versioner som stöds kubectl

Du kan använda en lägre version som är äldre eller nyare kubectl i förhållande till kube-apiserver-versionen, i överensstämmelse med Kubernetes-supportprincipen för kubectl.

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

Om du vill installera eller uppdatera kubectl till den senaste versionen kör du:

az aks install-cli

Install-AzAksKubectl -Version latest

Långsiktigt stöd (LTS)

AKS tillhandahåller ett års communitystöd och ett års långsiktig support (LTS) för att säkerhetskopiera portsäkerhetskorrigeringar från communityn uppströms i vår offentliga lagringsplats. 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).

Lanserings- och utfasningsprocess

Du kan referera till kommande versioner och utfasningar i AKS Kubernetes-versionskalendern.

För nya delversioner av Kubernetes:

• AKS publicerar ett meddelande med planerat datum för en ny version och respektive gammal versionsutfasning på 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.

  Kommentar

  Om du vill ta reda på vem som är dina prenumerationsadministratörer eller ändra den kan du läsa 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 det är tillgängligt har korrigeringar en livscykel på minst två månader.
• I allmänhet kommunicerar AKS inte i stort sett versionen av nya korrigeringsversioner. 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.

Principfel för versioner som stöds

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 korrigeringsversioner kan hoppas över eller distributionen påskyndas, beroende på hur allvarligt felet eller säkerhetsproblemet är.

Azure Portal- och CLI-versioner

När du distribuerar ett AKS-kluster med Azure Portal, Azure CLI, Azure PowerShell, standardvärdet för klustret till N-1-delversionen och den senaste korrigeringen. Om AKS till exempel stöder 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11 och 1.27.10 är standardversionen 1.28.7.

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

Get-AzAksVersion -Location eastus

Vanliga frågor

Hur meddelar Microsoft mig om nya Kubernetes-versioner?

AKS-teamet publicerar meddelanden med planerade datum för de nya Kubernetes-versionerna i vår dokumentation, GitHub, och i e-postmeddelanden till prenumerationsadministratörer som äger kluster som kommer att falla ur 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 har öppen källkod community utökat stödet till ett år. AKS åtar sig att aktivera korrigeringar och stöd för matchning av uppströmsåtaganden. 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 du har n-3-versionen eller äldre innebär det att du inte har support och uppmanas att uppgradera. När uppgraderingen från version n-3 till n-2 lyckas är du tillbaka i våra supportprinciper. Till exempel:

• Om den äldsta aks-delversionen som stöds är 1.27 och du är på 1,26 år eller äldre är du utanför supporten.
• När du uppgraderar från 1.26 till 1.27 eller senare är du tillbaka i våra supportprinciper.

Nedgraderingar stöds inte.

Vad betyder "Utanför supporten"?

"Utanför supporten" innebär att:

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

Vad händer när 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 med tjänstkvalitet rekommenderar vi att du uppgraderar för att få tillbaka klustret till support.

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

Om ett kluster inte har stöd för fler än tre (3) mindre versioner och har visat sig medföra säkerhetsrisker kontaktar Azure dig proaktivt för att uppgradera 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 med tjänstkvalitet rekommenderar vi att du uppgraderar för att få tillbaka klustret till support.

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

Kontrollplanet måste finnas i ett fönster med versioner från alla nodpooler. Mer information om hur du uppgraderar kontrollplanet eller nodpoolerna finns i dokumentationen om hur du uppgraderar nodpooler.

Vad är den tillåtna skillnaden i versioner mellan kontrollplan och nodpool?

Versionsförskjutningsprincipen tillåter nu en skillnad på upp till 3 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 klusteruppgradering?

När du uppgraderar ett AKS-kluster som stöds går det inte att hoppa över Kubernetes-delversioner. Kubernetes-kontrollplans versionsförskjutningsprincip stöder inte delversionshopp. Till exempel uppgraderingar mellan:

• 1.28.x ->1.29.x: tillåten.
• 1.27.x ->1.28.x: tillåten.
• 1.27.x ->1.29.x: tillåts inte.

Observera att för uppgraderingar av kontrollplanets version kan du gå upp till 3 delversioner för versioner som stöds av communityn på sekventiellt sätt.

Uppgradera från 1.27.x ->1.29.x:

1. Uppgradera från 1.27.x ->1.28.x.
2. Uppgradera från 1.28.x ->1.29.x.

Observera att från och med 1.28 version och senare kan agentpoolversioner vara upp till 3 versioner äldre för att styra planversioner per versionsförskjutningsprincip. När din version ligger mycket efter den lägsta versionen som stöds kan du behöva utföra mer än en uppgraderingsåtgärd för kontrollplanet för att komma till den lägsta version som stöds. Om din aktuella kontrollplansversion till exempel är 1.23.x och du tänker uppgradera till en lägsta version av 1.27.x som ett exempel. Du kan behöva uppgradera sekventiellt 4 gånger från 1.23.x för att komma till 1.27.x. Observera också att agentpoolversioner kan uppgraderas till kontrollplanets delversion. Det innebär att du i exemplet ovan kan uppgradera agentpoolversionen två gånger, dvs en gång från 1.23.x till 1.25.x, när kontrollplanets version är på 1.25.x. Och därefter från 1.25.x till 1.27.x , när kontrollplanets version är på 1.27.x. När du uppgraderar på plats, dvs kontrollplan och agentpool, gäller samma regler som gäller för kontrollplansuppgradering som skrivits ovan.

När du utför en uppgradering från en version som inte stöds – uppgraderingen utförs utan någon garanti för funktionalitet och undantas från serviceavtalen och den begränsade garantin. Kluster som kör version som inte stöds har flexibiliteten att koppla från uppgraderingar av kontrollplan med nodpoolsuppgraderingar. Men om din version är betydligt inaktuell rekommenderar vi att du återskapar klustret.

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

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

Jag har en nyligen inaktuell version som inte har plattformsstöd, kan jag fortfarande lägga till nya nodpooler? Eller måste jag uppgradera?

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

Nästa steg

Information om hur du uppgraderar klustret finns i:

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