Delen via

Een Azure Operator Nexus Kubernetes-cluster upgraden

  • Artikel

Dit artikel bevat instructies voor het upgraden van een Operator Nexus Kubernetes-cluster om de nieuwste functies en beveiligingsupdates te verkrijgen. Een deel van de levenscyclus van het Kubernetes-cluster omvat het uitvoeren van periodieke upgrades naar de nieuwste Kubernetes-versie. Het is belangrijk dat u de nieuwste beveiligingsreleases toepast of een upgrade uitvoert om de nieuwste functies te verkrijgen. In dit artikel leest u hoe u upgrades kunt controleren, configureren en toepassen op uw Kubernetes-cluster.

Beperkingen

  • Het standaardupgradeproces van het cluster is een uitschaalbenadering, wat betekent dat er ten minste één extra knooppunt wordt toegevoegd (of zo veel knooppunten als geconfigureerd in maximale piek). Als er onvoldoende capaciteit beschikbaar is, mislukt de upgrade.
  • Wanneer er nieuwe Kubernetes-versies beschikbaar komen, worden tenantclusters niet automatisch bijgewerkt. Gebruikers moeten de upgrade initiëren wanneer alle netwerkfuncties in het cluster gereed zijn om de nieuwe Kubernetes-versie te ondersteunen. Zie Het cluster upgraden voor meer informatie.
  • Operator Nexus biedt upgrades voor het hele cluster en zorgt voor consistentie in alle knooppuntgroepen. Het upgraden van één knooppuntgroep wordt niet ondersteund. De knooppuntinstallatiekopieën worden ook bijgewerkt als onderdeel van de clusterupgrade wanneer er een nieuwe versie beschikbaar is.
  • Aanpassingen aan agentknooppunten gaan verloren tijdens clusterupgrades. Het is raadzaam om deze aanpassingen in DaemonSet te stellen in plaats van handmatige wijzigingen aan te brengen in de knooppuntconfiguratie om ze na de upgrade te behouden.
  • Wijzigingen die zijn aangebracht in kernconfiguraties voor invoegtoepassingen, worden hersteld naar de standaardconfiguratie van de invoegtoepassing als onderdeel van het upgradeproces van het cluster. Vermijd het aanpassen van de configuratie van invoegtoepassingen (bijvoorbeeld Calico, enzovoort) om mogelijke upgradefouten te voorkomen. Als het herstel van de configuratie van de invoegtoepassing problemen ondervindt, kan dit leiden tot upgradefouten.
  • Wanneer u het Operator Nexus Kubernetes-cluster bijwerken, kunnen secundaire versies van Kubernetes niet worden overgeslagen. U moet alle upgrades sequentieel uitvoeren op primaire versienummer. Upgrades tussen 1.14.x ->1.15.x of 1.15.x ->1.16.x zijn bijvoorbeeld toegestaan, maar 1.14.x ->1.16.x is niet toegestaan. Als uw versie zich achter meerdere primaire versies bevindt, moet u meerdere opeenvolgende upgrades uitvoeren.
  • De maximale piek- en/of max. niet-beschikbare waarden moeten worden ingesteld tijdens het maken van het cluster. U kunt deze waarden niet wijzigen nadat het cluster is gemaakt. Zie upgradeSettings een Azure Operator Nexus Kubernetes-cluster maken voor meer informatie.

Vereisten

  • Een Azure Operator Nexus Kubernetes-cluster dat is geïmplementeerd in een resourcegroep in uw Azure-abonnement.
  • Als u Azure CLI gebruikt, moet u voor dit artikel de nieuwste Versie van Azure CLI uitvoeren. Als u Azure CLI wilt installeren of upgraden, raadpleegt u Azure CLI installeren.
  • Minimaal vereiste networkcloud az-cli-extensieversie: 2.0.b3
  • Inzicht in het concept van de versiebundels. Zie Nexus Kubernetes-versiebundels voor meer informatie.

Controleren op beschikbare upgrades

Controleer met de volgende stappen welke Kubernetes-releases beschikbaar zijn voor uw cluster:

Azure CLI gebruiken

Met de volgende Azure CLI-opdracht worden de beschikbare upgrades voor uw cluster geretourneerd:

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

Voorbeelduitvoer:

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

De Azure-portal gebruiken

  1. Meld u aan bij het Azure-portaal.
  2. Navigeer naar uw Operator Nexus Kubernetes-cluster.
  3. Selecteer onder Overzicht het tabblad Beschikbare upgrades.

Schermopname van beschikbare upgrades.

Kies een versie om een upgrade naar uit te voeren

De beschikbare upgrade-uitvoer geeft aan dat er meerdere versies zijn waaruit u kunt kiezen voor een upgrade. In dit specifieke scenario werkt het huidige cluster op versie v1.25.4-3. als gevolg hiervan, de beschikbare upgradeopties omvatten v1.25.4-4 en de nieuwste patchrelease v1.25.6-1. Verder is er ook een nieuwe secundaire versie beschikbaar.

U hebt de flexibiliteit om een upgrade uit te voeren naar een van de beschikbare versies. De aanbevolen procedure is echter om de upgrade uit te voeren naar de meest recente beschikbare major-minor-patch-versionbundle versie.

Notitie

De invoerindeling voor de versie is major.minor.patch of major.minor.patch-versionbundle. De versie-invoer moet een van de beschikbare upgradeversies zijn. Als de huidige versie van het cluster bijvoorbeeld is1.1.1-1, zijn geldige versie-invoer of 1.1.1-x1.1.1-2 . Hoewel 1.1.1 het een geldige indeling is, wordt er geen update geactiveerd omdat de huidige versie al 1.1.1is. Als u een update wilt initiëren, kunt u de volledige versie opgeven met de versiebundel, zoals 1.1.1-2. 1.1.2 En 1.2.x zijn echter een geldige invoer en gebruiken de nieuwste versiebundel die beschikbaar is voor 1.1.2 of 1.2.x.

Het cluster upgraden

Tijdens het upgradeproces van het cluster voert Operator Nexus de volgende bewerkingen uit:

  • Voeg een nieuw besturingsvlakknooppunt toe met de opgegeven Kubernetes-versie aan het cluster.
  • Nadat het nieuwe knooppunt is toegevoegd, cordont en leegloopt u een van de oude besturingsvlakknooppunten, zodat de werkbelastingen die erop worden uitgevoerd, correct worden verplaatst naar andere gezonde besturingsvlakknooppunten.
  • Nadat het oude besturingsvlakknooppunt is leeggemaakt, wordt het verwijderd en wordt er een nieuw knooppunt voor het besturingsvlak toegevoegd aan het cluster.
  • Dit proces wordt herhaald totdat alle besturingsvlakknooppunten in het cluster zijn bijgewerkt.
  • Als u werkknooppunten bijwerkt via piek (standaard):
    • Voeg voor elke agentgroep in het cluster een nieuw werkknooppunt (of zo veel knooppunten toe als geconfigureerd in maximale piek) met de opgegeven Kubernetes-versie. Meerdere agentpools worden tegelijkertijd bijgewerkt.
    • Cordon en leeg een van de oude werkknooppunten om onderbreking van actieve toepassingen te minimaliseren. Als u een maximale piek gebruikt, worden er net zoveel werkknooppunten tegelijk leeggemaakt als het aantal bufferknooppunten dat is opgegeven.
    • Nadat het oude werkknooppunt is leeggemaakt, wordt het verwijderd en wordt er een nieuw werkknooppunt met de nieuwe Kubernetes-versie toegevoegd aan het cluster (of zo veel knooppunten als geconfigureerd in maximale piek)
  • Als u werkknooppunten bijwerkt zonder piek:
    • Voor elke agentgroep in het cluster wordt een oud werkknooppunt (of zo veel knooppunten als geconfigureerd door maximaal niet beschikbaar) cordoned, verwijderd en vervolgens verwijderd voordat een nieuw werkknooppunt wordt vervangen door de opgegeven Kubernetes-versie. Meerdere agentpools worden tegelijkertijd bijgewerkt.
    • Tijdens de upgrade is er een tijdelijke vermindering van de clustercapaciteit, omdat pods die van het oude werkknooppunt zijn verwijderd, niet onmiddellijk een nieuw knooppunt hebben waarnaar moet worden verplaatst. Dit kan ertoe leiden dat pods een status in behandeling hebben als er onvoldoende capaciteit is. Daarom is het van cruciaal belang om uw cluster te ontwerpen om te voldoen aan de capaciteitsvereisten van toepassingen, met name tijdens upgrades zonder piek.
  • Dit proces wordt herhaald totdat alle werkknooppunten in het cluster zijn bijgewerkt.

Notitie

De clusterupgrade maakt geen nieuwe knooppunten en vervangt de oude knooppunten als de versie van de installatiekopieën van het besturingssysteem en de Kubernetes-versie hetzelfde blijven tussen versiebundels. Dit is verwacht gedrag, omdat de upgrade mogelijk alleen updates bevat voor invoegtoepassingsversies in plaats van nieuwe versies van het besturingssysteem of de K8s. Omdat er geen rolling upgrade is betrokken, is er geen cordon en afvoer op de knooppunten, zodat podonderbrekingen niet optreden.

Belangrijk

Zorg ervoor dat elke PodDisruptionBudgets (PDB) ervoor zorgt dat ten minste één podreplica tegelijk kan worden verplaatst, anders mislukt de verwijderings-/verwijderingsbewerking. Als de afvoerbewerking mislukt, mislukt de upgradebewerking ook om ervoor te zorgen dat de toepassingen niet worden onderbroken. Corrigeer wat de bewerking heeft veroorzaakt om te stoppen (d.w.w.: onjuiste PDBS, gebrek aan quotum, enzovoort) en probeer de bewerking opnieuw uit te voeren. Het is ook mogelijk om een time-out voor afvoer per werkknooppuntgroep te configureren, waarna het knooppunt wordt verwijderd, zelfs als pods nog niet zijn leeggemaakt. Dit kan voorkomen dat upgrades worden geblokkeerd door onjuist geconfigureerde PDBs. De time-outinstelling voor afvoeren wordt in seconden geconfigureerd en wordt standaard ingesteld op 1800.

  1. Werk uw cluster bij met behulp van de networkcloud kubernetescluster update opdracht.
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. Controleer of de upgrade is geslaagd met behulp van de show opdracht.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

In de volgende voorbeelduitvoer ziet u dat het cluster nu v1.26.3 uitvoert:

"v1.26.3"
  1. Zorg ervoor dat het cluster in orde is.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

In de volgende voorbeelduitvoer ziet u dat het cluster in orde is:

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

Knooppuntpieken of upgrade voor niet-beschikbaarheid aanpassen

Operator Nexus configureert standaard upgrades voor pieken met één extra werkknooppunt. Een standaardwaarde van een voor de maximale piekinstellingen stelt Operator Nexus in staat om werkbelastingonderbreking te minimaliseren door een extra knooppunt te maken voordat de cordon/drain van bestaande toepassingen een oudere versie van een knooppunt vervangt. De maximale piekwaarde kan per knooppuntgroep worden aangepast om een afweging mogelijk te maken tussen upgradesnelheid en upgradeonderbreking. Wanneer u de maximale piekwaarde verhoogt, wordt het upgradeproces sneller voltooid. Als u een grote waarde instelt voor een maximale piek, kunnen er onderbrekingen optreden tijdens het upgradeproces.

Een maximale piekwaarde van 100% biedt bijvoorbeeld het snelst mogelijke upgradeproces (verdubbeling van het aantal knooppunten), maar zorgt er ook voor dat alle knooppunten in de knooppuntgroep tegelijkertijd worden leeggezogen. Mogelijk wilt u een hogere waarde gebruiken, zoals deze voor testomgevingen. Voor productieknooppuntgroepen raden we een max_surge instelling van 33% aan.

Het is niet altijd geschikt om een upgrade uit te voeren via piek, bijvoorbeeld in omgevingen met beperkte resources. Upgrades kunnen ook doorgaan zonder piek, waarbij een werkknooppunt eerst wordt verwijderd en vervolgens wordt vervangen. Dit betekent dat er geen extra resource nodig is, maar leidt tot perioden met verminderde capaciteit waarbij pods mogelijk niet naar een knooppunt kunnen worden gepland. Dit type upgrade wordt beheerd per knooppuntgroep door de maximaal beschikbare instelling. Standaard is max. niet beschikbaar ingesteld op 0. Dit geeft aan dat maximaal 0 knooppunten niet beschikbaar zijn, dus dit type upgrade wordt niet standaard uitgevoerd.

De API accepteert zowel gehele getallen als een percentagewaarde voor een maximale piek en maximaal niet beschikbaar. Een geheel getal, zoals 5, geeft aan dat vijf knooppunten kunnen worden overgesprongen/niet beschikbaar zijn. Een waarde van 50% geeft een piek-/niet-beschikbaarheidswaarde aan van de helft van het huidige aantal knooppunten in de pool.

Een van de maximale piek of maximale beschikbaarheid moet ten minste 1 (of 1%) zijn, anders zou er geen mechanisme zijn waarmee het cluster kan worden bijgewerkt. Een percentagewaarde wordt naar boven afgerond op het dichtstbijzijnde aantal knooppunten. Zowel de maximale piek als het maximum aantal niet-beschikbare gegevens kan worden ingesteld op maximaal 100%. Als de maximale piekwaarde hoger is dan het vereiste aantal knooppunten dat moet worden bijgewerkt, wordt het aantal knooppunten dat moet worden bijgewerkt, gebruikt voor de maximale piekwaarde.

Maximale piek en maximale beschikbaarheid kunnen tegelijkertijd worden geconfigureerd. In dat geval wordt de upgrade voortgezet via een combinatie van pieken en onbeschikbaarheid.

Belangrijk

De standaard Kubernetes-workloads worden systeemeigen naar de nieuwe knooppunten gecyclusd wanneer ze worden verwijderd van de knooppunten die worden uitgesplitst. Houd er rekening mee dat operator Nexus Kubernetes-service geen beloftes voor werkbelastingen kan doen voor niet-standaard Kubernetes-gedrag.

Volgende stappen