Dela via

Uppgradera ett Azure Operator Nexus Kubernetes-kluster

  • Artikel

Den här artikeln innehåller instruktioner om hur du uppgraderar ett Operator Nexus Kubernetes-kluster för att hämta de senaste funktionerna och säkerhetsuppdateringarna. En del av Kubernetes-klusterlivscykeln omfattar periodiska uppgraderingar till den senaste Kubernetes-versionen. Det är viktigt att du tillämpar de senaste säkerhetsversionerna eller uppgraderar för att hämta de senaste funktionerna. Den här artikeln visar hur du söker efter, konfigurerar och tillämpar uppgraderingar på ditt Kubernetes-kluster.

Begränsningar

  • Standarduppgraderingsprocessen för klustret är en utskalningsmetod, vilket innebär att minst en extra nod läggs till (eller så många noder som konfigurerats i maximal ökning). Om det inte finns tillräckligt med tillgänglig kapacitet lyckas inte uppgraderingen.
  • När nya Kubernetes-versioner blir tillgängliga genomgår klientkluster inte automatiska uppgraderingar. Användarna bör initiera uppgraderingen när alla nätverksfunktioner i klustret är redo att stödja den nya Kubernetes-versionen. Mer information finns i Uppgradera klustret.
  • Operator Nexus erbjuder klusteromfattande uppgraderingar, vilket säkerställer konsekvens i alla nodpooler. Uppgradering av en enskild nodpool stöds inte. Nodavbildningen uppgraderas också som en del av klusteruppgradering när en ny version är tillgänglig.
  • Anpassningar som görs till agentnoder går förlorade under klusteruppgraderingar. Vi rekommenderar att du placerar anpassningarna i DaemonSet stället för att göra manuella ändringar i nodkonfigurationen för att bevara dem efter uppgraderingen.
  • Ändringar som görs i grundläggande tilläggskonfigurationer återställs till standardkonfigurationen för tillägg som en del av klusteruppgraderingsprocessen. Undvik att anpassa tilläggskonfigurationen (till exempel Calico osv.) för att förhindra potentiella uppgraderingsfel. Om återställningen av tilläggskonfigurationen stöter på problem kan det leda till uppgraderingsfel.
  • När du uppgraderar Operator Nexus Kubernetes-klustret kan kubernetes-delversioner inte hoppas över. Du måste utföra alla uppgraderingar sekventiellt efter huvudversionsnummer. Till exempel tillåts uppgraderingar mellan 1.14.x ->1.15.x eller 1.15.x ->1.16.x, men 1.14.x ->1.16.x tillåts inte. Om din version ligger efter med mer än en huvudversion bör du utföra flera sekventiella uppgraderingar.
  • Maximal ökning och/eller högsta otillgängliga värden måste anges när klustret skapas. Du kan inte ändra dessa värden när klustret har skapats. Mer information upgradeSettings finns i Skapa ett Azure Operator Nexus Kubernetes-kluster.

Förutsättningar

  • Ett Azure Operator Nexus Kubernetes-kluster som distribuerats i en resursgrupp i din Azure-prenumeration.
  • Om du använder Azure CLI kräver den här artikeln att du kör den senaste Azure CLI-versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI
  • Lägsta nödvändiga networkcloud az-cli-tilläggsversion: 2.0.b3
  • Förstå konceptet med versionspaket. Mer information finns i Nexus Kubernetes-versionspaket.

Sök efter tillgängliga uppgraderingar

Kontrollera vilka Kubernetes-versioner som är tillgängliga för klustret med hjälp av följande steg:

Använda Azure CLI

Följande Azure CLI-kommando returnerar de tillgängliga uppgraderingarna för klustret:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Exempel på utdata:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Använda Azure Portal

  1. Logga in på Azure-portalen.
  2. Gå till ditt Operator Nexus Kubernetes-kluster.
  3. Under Översikt väljer du fliken Tillgängliga uppgraderingar .

Skärmbild av tillgängliga uppgraderingar.

Välj en version att uppgradera till

De tillgängliga uppgraderingsutdata anger att det finns flera versioner att välja mellan för uppgradering. I det här specifika scenariot körs det aktuella klustret på version v1.25.4-3. Som ett resultat av detta är de tillgängliga uppgraderingsalternativen inklusive v1.25.4-4 och den senaste korrigeringsversionen v1.25.6-1. Dessutom är en ny delversion också tillgänglig.

Du har flexibiliteten att uppgradera till någon av de tillgängliga versionerna. Den rekommenderade åtgärden är dock att utföra uppgraderingen till den senaste tillgängliga major-minor-patch-versionbundle versionen.

Kommentar

Indataformatet för versionen är major.minor.patch eller major.minor.patch-versionbundle. Versionsindata måste vara en av de tillgängliga uppgraderingsversionerna. Om den aktuella versionen av klustret till exempel är 1.1.1-1är giltiga versionsindata 1.1.1-2 eller 1.1.1-x. Även om 1.1.1 det är ett giltigt format utlöser det ingen uppdatering eftersom den aktuella versionen redan 1.1.1är . Om du vill initiera en uppdatering kan du ange den fullständiga versionen med versionspaketet, till exempel 1.1.1-2. 1.1.2 Men och 1.2.x är ett giltigt indata och använder det senaste versionspaketet som är tillgängligt för 1.1.2 eller 1.2.x.

Uppgradera klustret

Under klusteruppgraderingsprocessen utför Operator Nexus följande åtgärder:

  • Lägg till en ny kontrollplansnod med den angivna Kubernetes-versionen i klustret.
  • När den nya noden har lagts till spärrar och tömmer du en av de gamla kontrollplansnoderna, vilket säkerställer att arbetsbelastningarna som körs på den flyttas korrekt till andra felfria kontrollplansnoder.
  • När den gamla kontrollplansnoden har tömts tas den bort och en ny kontrollplansnod läggs till i klustret.
  • Den här processen upprepas tills alla kontrollplansnoder i klustret har uppgraderats.
  • Om du uppgraderar arbetsnoder via överspänning (standard):
    • För varje agentpool i klustret lägger du till en ny arbetsnod (eller så många noder som konfigurerats i maximal ökning) med den angivna Kubernetes-versionen. Flera agentpooler uppgraderas samtidigt.
    • Spärra av och töm en av de gamla arbetsnoderna för att minimera avbrott i program som körs. Om du använder maximal ökning spärrar och tömmer den så många arbetsnoder samtidigt som antalet buffertnoder som angetts.
    • När den gamla arbetsnoden har tömts tas den bort och en ny arbetsnod med den nya Kubernetes-versionen läggs till i klustret (eller så många noder som konfigurerats i maximal ökning)
  • Om du uppgraderar arbetsnoder utan överspänning:
    • För varje agentpool i klustret spärras, töms och tas en gammal arbetsnod (eller så många noder som konfigurerats av maximalt otillgängligt) bort, innan den ersätts av en ny arbetsnod med den angivna Kubernetes-versionen. Flera agentpooler uppgraderas samtidigt.
    • Under uppgraderingen sker en tillfällig minskning av klusterkapaciteten eftersom poddar som tömts från den gamla arbetsnoden inte omedelbart har en ny nod att flytta till. Detta kan leda till att poddar går in i ett väntande tillstånd om det inte finns tillräckligt med kapacitet. Därför är det viktigt att utforma klustret så att det uppfyller kraven på programkapacitet, särskilt under uppgraderingar utan överbelastning.
  • Den här processen upprepas tills alla arbetsnoder i klustret har uppgraderats.

Kommentar

Klusteruppgradningen skapar inte nya noder och ersätter de gamla om operativsystemavbildningsversionen (OS) och Kubernetes-versionen förblir desamma mellan versionspaketen. Detta är ett förväntat beteende eftersom uppgraderingen endast kan innehålla uppdateringar av Addon-versioner i stället för nya versioner av operativsystemet eller K8s. Eftersom det inte finns någon löpande uppgradering finns det ingen avspärrning och dränering på noderna, så poddavbrott kommer inte att inträffa.

Viktigt!

Se till att alla PodDisruptionBudgets (PDB) tillåter att minst en poddreplik flyttas åt gången, annars misslyckas avlopps-/vräkningsåtgärden. Om dräneringsåtgärden misslyckas misslyckas även uppgraderingsåtgärden för att säkerställa att programmen inte störs. Korrigera vad som orsakade att åtgärden stoppas (dvs. felaktiga PDF-filer, brist på kvot osv.) och försök igen. Det går också att konfigurera en timeout för avlopp per arbetsnodpool, varefter noden tas bort även om poddarna ännu inte har slutfört tömningen. Detta kan förhindra att uppgraderingar blockeras av felkonfigurerade PDF-filer. Timeout-inställningen för avlopp konfigureras i sekunder och är som standard 1800.

  1. Uppgradera klustret med hjälp av networkcloud kubernetescluster update kommandot .
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. Bekräfta att uppgraderingen lyckades med kommandot show .
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

Följande exempelutdata visar att klustret nu kör v1.26.3:

"v1.26.3"
  1. Kontrollera att klustret är felfritt.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

Följande exempelutdata visar att klustret är felfritt:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Anpassa nodökning eller otillgänglighetsuppgradering

Som standard konfigurerar Operator Nexus uppgraderingar till överspänning med en extra arbetsnod. Ett standardvärde på ett för inställningarna för maximal överbelastning gör att Operator Nexus kan minimera arbetsbelastningsavbrott genom att skapa en extra nod före avspärrning/tömning av befintliga program för att ersätta en äldre version av noden. Det maximala överspänningsvärdet kan anpassas per nodpool för att möjliggöra en kompromiss mellan uppgraderingshastighet och uppgraderingsstörningar. När du ökar det maximala överspänningsvärdet slutförs uppgraderingsprocessen snabbare. Om du anger ett stort värde för maximal ökning kan det uppstå störningar under uppgraderingsprocessen.

Ett maximalt överspänningsvärde på 100 % ger till exempel den snabbaste möjliga uppgraderingsprocessen (fördubbling av antalet noder) men gör också att alla noder i nodpoolen töms samtidigt. Du kanske vill använda ett högre värde som det här för att testa miljöer. För produktionsnodpooler rekommenderar vi en max_surge inställning på 33 %.

Det är inte alltid lämpligt att uppgradera via överspänning, till exempel i resursbegränsade miljöer. Uppgraderingar kan också fortsätta utan överspänning, där en arbetsnod först tas bort och sedan ersätts. Det innebär att ingen extra resurs behövs, men leder till perioder med minskad kapacitet där poddar kanske inte kan schemaläggas till en nod. Den här typen av uppgradering styrs per nodpool av inställningen maximalt otillgänglig. Som standard är max otillgängligt inställt på 0. Detta anger att högst 0 noder kan vara otillgängliga, dvs. den här typen av uppgradering sker inte som standard.

API:et accepterar både heltalsvärden och ett procentvärde för maximal ökning och maximalt otillgängligt. Ett heltal som 5 anger att fem noder kan ökas/göras otillgängliga. Ett värde på 50 % anger ett öknings-/otillgänglighetsvärde på hälften av det aktuella antalet noder i poolen.

En maximal ökning eller maximalt otillgänglig måste vara minst 1 (eller 1 %), annars skulle det inte finnas någon mekanism med vilken klustret kunde uppgraderas. Ett procentvärde avrundas upp till närmaste nodantal. Både maximal överspänning och maximalt otillgängligt kan anges till högst 100 %. Om det maximala överspänningsvärdet är högre än det antal noder som krävs för att uppgraderas används antalet noder som ska uppgraderas för det maximala överspänningsvärdet.

Maximal ökning och maximalt otillgängligt kan konfigureras samtidigt, i vilket fall uppgraderingen fortsätter via en blandning av överspänning och otillgänglighet.

Viktigt!

Kubernetes-standardarbetsbelastningarna cyklar internt till de nya noderna när de töms från noderna som rivs. Tänk på att operatören Nexus Kubernetes-tjänsten inte kan ge arbetsbelastningslöften för kubernetes-beteenden som inte är standard.

Nästa steg