Ondersteunde Kubernetes-versies in AKS (Azure Kubernetes Service)

De Kubernetes-community brengt ongeveer elke vier maanden kleine versies uit.

Secundaire versiereleases bevatten nieuwe functies en verbeteringen. Patch releases komen vaker voor (soms wekelijks) en zijn bedoeld voor kritieke bugfixes binnen een kleine versie. Patchreleases bevatten oplossingen voor beveiligingsproblemen of belangrijke bugs.

Kubernetes-versies

Kubernetes maakt gebruik van het standaard versiebeheerschema voor Semantic Versioning voor elke versie:

[major].[minor].[patch]

Elk nummer in de versie weerspiegelt de compatibiliteit met eerdere versies:

• Primaire versies: Introduceer incompatibele API-wijzigingen of breek achterwaartse compatibiliteit.
• Secundaire versies: nieuwe functies toevoegen. Stabiele API's blijven over het algemeen compatibel, maar afgeschafte API's en functies kunnen worden verwijderd volgens het Kubernetes-afschaffingsbeleid.
• Patchversies: Bevatten achterwaarts compatibele bugfixes.

Gebruik altijd de nieuwste patchrelease voor uw huidige secundaire versie. Wanneer er een latere patch beschikbaar komt voor uw secundaire versie, voert u een upgrade uit om ervoor te zorgen dat uw cluster volledig is gepatcht en ondersteund.

AKS Kubernetes-releasekalender en toekomstige versies

Controleer de AKS Kubernetes-releasekalender voor toekomstige versiereleases. Als u realtime-updates van de status van de regio-release en releaseopmerkingen van de versie wilt bekijken, gaat u naar de AKS-releasestatuswebpagina. Zie AKS Release Tracker voor meer informatie over de webpagina met de releasestatus.

Zie de Kubernetes-geschiedenis voor de vorige releasegeschiedenis.

LTS-versies

U moet langetermijnondersteuning (LTS) inschakelen om uitgebreide ondersteuning te krijgen. Zie Langetermijnondersteuning inschakelen voor meer informatie.

Gantt-diagram voor de AKS Kubernetes release planning

In het volgende Gantt-diagram worden de huidige releases weergegeven:

AKS-componenten met ingrijpende wijzigingen per versie

Let op de volgende belangrijke wijzigingen voordat u een upgrade uitvoert naar een van de beschikbare secundaire versies:

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Alias voor minor-versie in AKS

U kunt een AKS-cluster maken zonder een patchversie op te geven. Wanneer u een cluster maakt zonder een patch aan te wijzen, voert het cluster de nieuwste GA-patch van de secundaire versie uit. Als u uw patchversie binnen dezelfde kleine versie wilt upgraden, gebruikt u autoupgrade.

Voer de az aks show --resource-group myResourceGroup --name myAKSCluster opdracht uit om te zien welke patch u gebruikt. In de uitvoer toont de currentKubernetesVersion eigenschap de volledige Kubernetes-versie. Voorbeeld:

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

Beleid voor ondersteuning van Kubernetes-versies

AKS definieert een algemeen beschikbare (GA)-versie als een versie die beschikbaar is in alle regio's en is ingeschakeld in alle SLO- of SLA-metingen. AKS ondersteunt drie ga-secundaire versies van Kubernetes:

• De nieuwste GA-versie (N).
• De twee vorige secundaire versies (N-1 en N-2).
  • Elke ondersteunde secundaire versie kan elk willekeurig aantal patches op een bepaald moment ondersteunen. AKS behoudt zich het recht voor om patches te verwijderen als er een kritiek CVE- of beveiligingsprobleem wordt gedetecteerd. Raadpleeg voor informatie over de beschikbaarheid van patches en eventuele ad-hoc afstoting de releaseopmerkingen van de versie en bezoek de webpagina met de status van de AKS-release.

AKS biedt mogelijk ook ondersteuning voor preview-versies, die expliciet zijn gelabeld en onderhevig aan de voorwaarden voor preview.

AKS biedt platformondersteuning voor slechts één secundaire GA-versie van Kubernetes na de reguliere ondersteunde versies. Het platformondersteuningsvenster van Kubernetes-versies op AKS wordt N-3 genoemd. Zie platformondersteuningsbeleid voor meer informatie.

Het ondersteunde venster van Secundaire versies van Kubernetes op AKS wordt N-2 genoemd, waarbij N verwijst naar de nieuwste release, wat betekent dat twee eerdere secundaire releases ook worden ondersteund.

Op de dag dat AKS bijvoorbeeld versie 1.29 introduceert, wordt ondersteuning geboden voor de volgende versies:

Wanneer een nieuwe secundaire versie wordt geïntroduceerd, wordt de oudste secundaire versie afgeschaft en verwijderd. Stel dat de huidige lijst met ondersteunde secundaire versies 1.29, 1.28 en 1.27 is. Wanneer AKS 1.30 vrijgeeft, gaan alle 1.27-versies 30 dagen later uit de ondersteuning.

AKS biedt mogelijk ondersteuning voor een aantal patches op basis van de beschikbaarheid van upstream-communityversies voor een bepaalde minor versie. AKS behoudt zich het recht voor om een van deze patches op elk gewenst moment te verwijderen vanwege een CVE of mogelijk probleem met fouten. We raden u aan de nieuwste patch te gebruiken voor een kleine versie.

Platformondersteuningsbeleid

Platformondersteuningsbeleid is een verminderd ondersteuningsplan voor bepaalde niet-ondersteunde Kubernetes-versies. Tijdens platformondersteuning ontvangen klanten alleen ondersteuning van Microsoft voor AKS/Azure-platformgerelateerde problemen. Eventuele problemen met betrekking tot Kubernetes-functionaliteit en -onderdelen worden niet ondersteund.

Platformondersteuningsbeleid is van toepassing op clusters in een N-3-versie (waarbij N de meest recente ondersteunde AKS GA secundaire versie is) voordat het cluster wordt verwijderd naar N-4. Kubernetes v1.26 wordt bijvoorbeeld beschouwd als platformondersteuning wanneer v1.29 de nieuwste GA-versie is. Stel dat u een N-2-versie gebruikt. Op het moment dat de versie N-3 wordt, wordt de officiële ondersteuning ook beëindigd en voert u het platformondersteuningsbeleid in.

AKS is afhankelijk van de releases en patches van Kubernetes, een opensource-project dat alleen een schuifvenster van drie secundaire versies ondersteunt. AKS kan alleen volledige ondersteuning garanderen terwijl deze versies upstream worden onderhouden. Aangezien er upstream geen patches meer worden geproduceerd, kan AKS deze versies ongepatcht laten of een fork maken. Vanwege deze beperking biedt platformondersteuning geen ondersteuning voor het gebruik van Kubernetes upstream.

De volgende tabel bevat ondersteuningsrichtlijnen voor communityondersteuning vergeleken met platformondersteuning:

Ondersteunde kubectl versies

U kunt een kubectl versie gebruiken die een subversie is die ouder of nieuwer is dan uw kube-apiserver-versie. Zie het Kubernetes-ondersteuningsbeleid voor kubectl voor meer informatie.

Als uw kube-apiserver bijvoorbeeld 1.28 is, kunt u versies 1.27 tot 1.29 van kubectl gebruiken.

Als u de nieuwste versie wilt installeren of bijwerken kubectl , gebruikt u de opdracht op basis van het hulpprogramma van uw voorkeur:

az aks install-cli

Install-AzAksKubectl -Version latest

Langetermijnondersteuning (LTS)

AKS biedt één jaar community-ondersteuning en één jaar langetermijnondersteuning (LTS), inclusief backported beveiligingsoplossingen van de upstream-community. Onze upstream LTS-werkgroep draagt bij aan de community om onze klanten een langer ondersteuningsvenster te bieden.

Zie Langetermijnondersteuning voor Azure Kubernetes Service (AKS) voor meer informatie over LTS.

Release- en uitfaseringsproces

Zie de AKS Kubernetes-releaseagenda voor toekomstige versies en afschaffingen.

Voor nieuwe secundaire versies van Kubernetes:

• AKS kondigt de releasedatums van nieuwe versies en afschaffing van oude versies aan in de opmerkingen bij de AKS-release ten minste 30 dagen voordat ze worden verwijderd.

• AKS gebruikt Azure Advisor om u te waarschuwen als een nieuwe versie problemen in uw cluster kan veroorzaken vanwege afgeschafte API's. Azure Advisor waarschuwt u ook als u niet meer wordt ondersteund.

• AKS publiceert een servicestatusmelding die beschikbaar is voor alle gebruikers met AKS- en portaltoegang en stuurt een e-mail naar de abonnementsbeheerders met de geplande datums voor het verwijderen van versies.

  Note

  Zie Azure-abonnementen beheren om uw abonnementsbeheerders weer te geven of te wijzigen.

• U hebt 30 dagen na het verwijderen van de versie om een upgrade uit te voeren naar een ondersteunde secundaire versieversie om ondersteuning te blijven ontvangen.

Voor nieuwe patchversies van Kubernetes:

• Vanwege de urgente aard van patchversies kunnen ze in de service worden geïntroduceerd zodra ze beschikbaar komen. Zodra deze beschikbaar zijn, hebben patches een minimale levenscyclus van twee maanden.
• Over het algemeen communiceert AKS niet breed over de release van nieuwe patchversies. AKS controleert en valideert echter voortdurend beschikbare CVE-patches om ze tijdig te ondersteunen in AKS. Als er een kritieke patch wordt gevonden of als er een gebruikersactie is vereist, wordt u door AKS op de hoogte gesteld van een upgrade naar de nieuw beschikbare patch.
• U hebt 30 dagen na het verwijderen van een patchrelease van AKS om een upgrade uit te voeren naar een ondersteunde patch en ondersteuning te blijven ontvangen. U kunt echter geen clusters of knooppuntgroepen meer maken zodra de versie is afgeschaft/verwijderd.

Uitzonderingen op het beleid voor ondersteunde versies

AKS behoudt zich het recht voor om nieuwe/bestaande versies toe te voegen of te verwijderen met een of meer kritieke fouten of beveiligingsproblemen die van invloed zijn op de productie, zonder voorafgaande kennisgeving.

Specifieke patchreleases kunnen worden overgeslagen of versneld worden geïmplementeerd, afhankelijk van de ernst van de fout of het beveiligingsprobleem.

Versies van Azure Portal en CLI

Als u een AKS-cluster implementeert met behulp van Azure portal, Azure CLI of Azure PowerShell, wordt het cluster standaard ingesteld op de secundaire N-1-versie en de meest recente patch.

Als u wilt achterhalen welke versies momenteel beschikbaar zijn voor uw abonnement en regio, gebruikt u de opdracht op basis van het hulpprogramma van uw voorkeur:

# 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

Veelgestelde vragen (FAQ)

Hoe informeert Microsoft mij over nieuwe Kubernetes-versies?

Het AKS-team kondigt nieuwe releasedatums voor Kubernetes-versies aan in onze documentatie, op GitHub en via e-mail naar abonnementsbeheerders met clusters die bijna aan het einde van de ondersteuning komen. AKS maakt ook gebruik van Azure Advisor om u in Azure Portal te waarschuwen als u niet meer wordt ondersteund en u informeert over afgeschafte API's die van invloed kunnen zijn op uw toepassing of ontwikkelingsproces.

Hoe vaak moet ik verwachten dat ik Kubernetes-versies moet upgraden om ondersteuning te blijven bieden?

Vanaf Kubernetes 1.19 heeft de opensource-community de ondersteuning voor één jaar uitgebreid. AKS zet zich in om patches en ondersteuning mogelijk te maken die overeenkomt met de upstream-toezeggingen. Voor AKS-clusters op 1.19 en hoger kunt u minimaal één keer per jaar upgraden om op een ondersteunde versie te blijven.

Wat gebeurt er wanneer u een Kubernetes-cluster upgradet met een secundaire versie die niet wordt ondersteund?

Als uw versie niet meer wordt ondersteund volgens de lijst met ondersteunde Kubernetes-versies, moet u een upgrade uitvoeren. U kunt upgraden van niet-ondersteunde versies naar ondersteunde versies. Voorbeeld:

• Als de laagste ondersteunde secundaire AKS-versie 1.33 is en u zich op 1.32 of ouder bevindt, bent u buiten ondersteuning.
• Als u een upgrade hebt uitgevoerd van 1.32 naar 1.33 of hoger, bent u terug in het ondersteuningsbeleid.

Downgraden of terugdraaien naar een niet-ondersteunde versie worden niet ondersteund. Bovendien is de clusterversie hoger dan de laagst ondersteunde versie, hoe groter de kans op upgradeproblemen. In dat geval is het aanmaken van een nieuw cluster en het migreren van workloads een betere aanpak.

Wat betekent het om 'buiten ondersteuning' te zijn?

"Buiten ondersteuning" betekent:

• De versie die u uitvoert, valt buiten de lijst met ondersteunde versies.
• U wordt gevraagd om het cluster bij te werken naar een ondersteunde versie wanneer u ondersteuning aanvraagt, tenzij u zich binnen de respijtperiode van 30 dagen na de afschaffing van de versie bevindt.

Daarnaast maakt AKS geen runtime- of andere garanties voor clusters buiten de lijst met ondersteunde versies.

Kun je voor altijd op een Kubernetes-versie blijven?

Als een cluster niet meer dan drie secundaire versies ondersteunt en beveiligingsrisico's met zich meebrengt, neemt Azure proactief contact met u op. Ze adviseren u om uw cluster te upgraden. Als u geen verdere actie onderneemt, behoudt Azure zich het recht voor om uw cluster namens u automatisch te upgraden.

Wat gebeurt er als u een Kubernetes-cluster schaalt met een secundaire versie die niet wordt ondersteund?

Voor kleinere versies die niet door AKS worden ondersteund, moet het in- of uitschalen blijven werken. Omdat er geen garanties zijn met de kwaliteit van de service, raden we u aan een upgrade uit te voeren om uw cluster weer te ondersteunen.

Welke versie ondersteunt het besturingsvlak als de knooppuntgroep zich niet in een van de ondersteunde AKS-versies bevindt?

Het besturingsvlak en alle knooppuntgroepen moeten binnen het ondersteunde versieverschilvenster blijven. Vanaf Kubernetes 1.28 mag de control plane maximaal drie minorversies voorlopen op de nodepools. Zie de kubernetes-versie-upgraderegels voor meer informatie.

Wat is het toegestane verschil in versies tussen het besturingsvlak en knooppuntgroepen?

Het versieverschilbeleid maakt nu een verschil van maximaal drie versies mogelijk tussen besturingsvlak en agentpools. AKS volgt deze scheve versiebeleidswijziging vanaf versie 1.28.

Kan ik meerdere AKS-versies overslaan tijdens een clusterupgrade?

Ja, in sommige gevallen kunt u secundaire versies overslaan. Als u het control plane echter onafhankelijk van de nodepools upgradet, moet u voldoen aan het beleid voor versieverschillen van Kubernetes. Het kubernetes-versieverschilbeleid ondersteunt momenteel alleen N-3, dus de besturingsvlak- en agentpools moeten zich binnen N-3 van elkaar bevinden.

• LTS: Een versie waarvoor het AKS-Long-Term-ondersteuningsplan is ingeschakeld. Zie LTS-versies.
• Niet-ondersteunde LTS: een versie met LTS-ondersteuning waarvan de LTS-eindedatum is verstreken in de tabel LTS-versies.
• Ondersteunde niet-LTS: een versie die niet LTS is, maar die nog steeds wordt vermeld als ondersteund in de AKS Kubernetes-releasekalender.
• Niet-ondersteunde niet-LTS: een versie die niet LTS is en die niet meer wordt vermeld als ondersteund in de AKS Kubernetes-releasekalender.

Examples:

• Als uw cluster zich op 1.29 LTS bevindt en u wilt overstappen op 1.32 LTS, kunt u meerdere secundaire versies overslaan zolang 1.32 LTS nog steeds wordt aangeboden door AKS en de upgrade voldoet aan versieverschil- en validatiecontroles.
• Als uw cluster zich op 1.28 niet-LTS bevindt, kunt u overstappen op AKS LTS 1.30 LTS met behulp van het niet-ondersteunde herstelpad, zolang de doelversie wordt vermeld door AKS, aan validatiecontroles voldoet en u een volledige clusterupgrade uitvoert in plaats control-plane-onlyvan .
• Als uw cluster is ingeschakeld voor niet-LTS 1.33 en u wilt overstappen op ondersteunde niet-LTS 1.35, kunt u niet rechtstreeks van 1.33 tot 1.35 overslaan. U moet één secundaire versie tegelijk upgraden, zoals 1.33 naar 1.34 en vervolgens 1.34 naar 1.35.

In de voorgaande tabel geeft Unsupported recovery path aan dat het upgradepad wordt uitgevoerd op een manier waarvan niet kan worden gegarandeerd dat die veilig is en daarom als niet-ondersteund wordt beschouwd. Met AKS kan de upgrade worden voortgezet, maar deze wordt niet ondersteund en kan risico's met zich meebrengen.

Als u het juiste pad wilt kiezen, controleert u de beschikbare doelen door uit te voeren az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Bekijk de voorgaande tabel en overweeg vervolgens het risico om het cluster te upgraden of opnieuw te maken en workloads te migreren.

Kan ik een nieuw 1.xx.x-cluster maken tijdens het ondersteuningsvenster van het platform?

Nee, het maken van nieuwe clusters is niet mogelijk tijdens de platformondersteuningsperiode.

Ik heb een nieuw afgeschafte versie die geen platformondersteuning meer biedt. Kan ik nog steeds nieuwe knooppuntgroepen toevoegen of moet ik upgraden?

Ja, u kunt agentpools toevoegen zolang ze compatibel zijn met de control plane versie.

Verwante inhoud

Zie voor meer informatie over AKS-clusterupgrades:

• Een AKS-cluster (Azure Kubernetes Service) upgraden
• Meerdere AKS-clusters upgraden via Azure Kubernetes Fleet Manager