Share via

Plaatsing van resources in Azure Operator Nexus Kubernetes

  • Artikel

Operator Nexus-exemplaren worden geïmplementeerd op de locatie van de klant. Elk exemplaar bestaat uit een of meer rekken met bare-metalservers.

Wanneer een gebruiker een Nexus Kubernetes Cluster (NKS) maakt, geven ze een telling en een SKU (stock keeping unit ) op voor virtuele machines (VM) waaruit het Kubernetes-besturingsvlak en een of meer agentgroepen bestaat. Agentgroepen zijn de set Werkknooppunten waarop de containernetwerkfuncties van een klant worden uitgevoerd.

Het Nexus-platform is verantwoordelijk voor het bepalen van de bare-metalserver waarop elke NKS-VM wordt gestart.

Hoe het Nexus-platform een Nexus Kubernetes-cluster-VM plant

Nexus identificeert eerst de set potentiële bare-metalservers die voldoen aan alle resourcevereisten van de NKS VM-SKU. Als de gebruiker bijvoorbeeld een NC_G48_224_v1 VM-SKU heeft opgegeven voor de agentgroep, verzamelt Nexus de bare-metalservers met beschikbare capaciteit voor 48 vCPU, 224Gi ram-geheugen, enzovoort.

Nexus onderzoekt vervolgens het AvailabilityZones veld voor de agentgroep of het besturingsvlak dat wordt gepland. Als dit veld niet leeg is, filtert Nexus de lijst met potentiële bare-metalservers naar alleen die servers in de opgegeven beschikbaarheidszones (racks). Dit gedrag is een vaste planningsbeperking. Als er geen bare-metalservers in de gefilterde lijst staan, plant Nexus de NKS-VM niet en kan het cluster niet worden ingericht.

Zodra Nexus een lijst identificeert met mogelijke bare-metalservers waarop de NKS-VM moet worden geplaatst, kiest Nexus vervolgens een van de bare-metalservers na het toepassen van de volgende sorteerregels:

  1. Geef de voorkeur aan bare-metalservers in beschikbaarheidszones (racks) die geen NKS-VM's van dit NKS-cluster hebben. Met andere woorden, spreid de NKS-VM's voor een NKS-cluster over beschikbaarheidszones.

  2. Geef de voorkeur aan bare-metalservers binnen één beschikbaarheidszone (rack) die geen andere NKS-VM's van hetzelfde NKS-cluster hebben. Met andere woorden, spreid de NKS-VM's voor een NKS-cluster over bare-metalservers binnen een beschikbaarheidszone.

  3. Als de NKS VM-SKU is ofNC_P46_224_v1NC_G48_224_v1, geeft u de voorkeur aan bare-metalservers die al of NC_P46_224_v1 NKS-VM's van andere NKS-clusters bevattenNC_G48_224_v1. Met andere woorden, groepeer de extra grote VM's van verschillende NKS-clusters op dezelfde bare-metalservers. Met deze regel worden de extra grote VM's verpakt om de fragmentatie van de beschikbare rekenresources te verminderen.

Voorbeeldscenario's voor plaatsing

In de volgende secties wordt het gedrag gemarkeerd dat Nexus-gebruikers moeten verwachten bij het maken van NKS-clusters op basis van een Operator Nexus-omgeving.

Hint: U kunt zien op welke bare-metalserver uw NKS-VM's zijn gepland door de nodes.bareMetalMachineId eigenschap van de NKS KubernetesCluster-resource te bekijken of de kolom Host weer te geven in de weergave van Kubernetes-clusterknooppunten in De Azure-portal.

Een schermopname van de bare-metalserver voor NKS-VM's.

De voorbeeldomgeving Operator Nexus heeft de volgende specificaties:

Lege omgeving

Gezien een lege Operator Nexus-omgeving met de opgegeven capaciteit maken we drie verschillende grootte Nexus Kubernetes-clusters.

De NKS-clusters hebben deze specificaties en we gaan ervan uit dat de gebruiker in de volgende volgorde de drie clusters maakt:

Cluster A

  • Besturingsvlak, NC_G12_56_v1 SKU, drie aantallen
  • Agentpool 1, NC_P46_224_v1 SKU, 24 count
  • Agentgroep #2, NC_G6_28_v1 SKU, zes aantallen

Cluster B

  • Besturingsvlak, NC_G24_112_v1 SKU, vijf aantallen
  • Agentpool #1, NC_P46_224_v1 SKU, 48 count
  • Agentpool 2, NC_P22_112_v1 SKU, aantal 24

Cluster C

  • Besturingsvlak, NC_G12_56_v1 SKU, drie aantallen
  • Agentpool #1, NC_P46_224_v1 SKU, aantal 12, AvailabilityZones = [1,4]

Hier volgt een tabel met een samenvatting van wat de gebruiker moet zien na het starten van Clusters A, B en C in een lege Operator Nexus-omgeving.

Cluster Groep SKU Totaal aantal Verwachte #Racks Werkelijke # rekken Verwachte # VM's per rek Werkelijke aantal VM's per rack
A Besturingsvlak NC_G12_56_v1 3 3 3 1 1
A Agentgroep 1 NC_P46_224_v1 24 8 8 3 3
A Agentgroep 2 NC_G6_28_v1 6 6 6 1 1
B Besturingsvlak NC_G24_112_v1 5 5 5 1 1
B Agentgroep 1 NC_P46_224_v1 48 8 8 6 6
B Agentgroep 2 NC_P22_112_v1 24 8 8 3 3
E Besturingsvlak NC_G12_56_v1 3 3 3 1 1
E Agentgroep 1 NC_P46_224_v1 12 2 2 6 6

Er zijn acht racks, zodat de VM's voor elke pool worden verdeeld over maximaal acht racks. Voor pools met meer dan acht VM's zijn meerdere VM's per rek vereist, verspreid over verschillende bare-metalservers.

Cluster C Agent Pool #1 heeft 12 VM's beperkt tot AvailabilityZones [1, 4] zodat het 12 VM's op 12 bare-metalservers heeft, zes in elk van racks 1 en 4.

Extra grote VM's (de NC_P46_224_v1 SKU) van verschillende clusters worden op dezelfde bare-metalservers geplaatst (zie regel 3 in hoe het Nexus-platform een Nexus Kubernetes-cluster-VM plant).

Hier volgt een visualisatie van een indeling die de gebruiker kan zien na het implementeren van Clusters A, B en C in een lege omgeving.

Diagram met mogelijke indeling van VM's na de eerste implementatie.

Halve omgeving

We doorlopen nu een voorbeeld van het starten van een ander NKS-cluster wanneer de doelomgeving halfvol is. De doelomgeving is halfvol nadat clusters A, B en C zijn geïmplementeerd in de doelomgeving.

Cluster D heeft de volgende specificaties:

  • Besturingsvlak, NC_G24_112_v1 SKU, vijf aantallen
  • Agentpool #1, NC_P46_224_v1 SKU, 24 count, AvailabilityZones = [7,8]
  • Agentpool 2, NC_P22_112_v1 SKU, aantal 24

Hier volgt een tabel met een samenvatting van wat de gebruiker moet zien na het starten van Cluster D in de half volledige Operator Nexus-omgeving die bestaat na het starten van Clusters A, B en C.

Cluster Groep SKU Totaal aantal Verwachte #Racks Werkelijke # rekken Verwachte # VM's per rek Werkelijke aantal VM's per rack
D Besturingsvlak NC_G12_56_v1 5 5 5 1 1
D Agentgroep 1 NC_P46_224_v1 24 2 2 12 12
D Agentgroep 2 NC_P22_112_v1 24 8 8 3 3

Cluster D Agent Pool #1 heeft 12 VM's beperkt tot AvailabilityZones [7, 8] zodat het 12 VM's op 12 bare-metalservers heeft, zes in elk van racks 7 en 8. Deze VM's landen op bare-metalservers die ook extra grote VM's van andere clusters bevatten vanwege de sorteerregel die extra grote VM's van verschillende clusters op dezelfde bare-metalservers groeperen.

Als een cluster-D-besturingsvlak-VM op rack 7 of 8 terechtkomt, is het waarschijnlijk dat één cluster-D-agentgroep #1 op dezelfde bare-metalserver terechtkomt als die cluster-D-besturingsvlak-VM. Dit gedrag wordt veroorzaakt doordat agentgroep 1 wordt 'vastgemaakt' aan racks 7 en 8. Capaciteitsbeperkingen in deze racks zorgen ervoor dat de scheduler een vm met een besturingsvlak en een agentgroep #1 VM uit hetzelfde NKS-cluster op de hoogte heeft.

Cluster D's Agent Pool #2 heeft drie VM's op verschillende bare-metalservers op elk van de acht racks. Capaciteitsbeperkingen zijn het gevolg van de agentgroep van cluster D #1 die is vastgemaakt aan racks 7 en 8. Daarom worden VM's uit de agentgroep van cluster D #1 en agentgroep 2 op dezelfde bare-metalservers in racks 7 en 8 geplaatst.

Hier volgt een visualisatie van een indeling die de gebruiker kan zien na het implementeren van Cluster D in de doelomgeving.

Diagram met de mogelijke indeling van VM's na de tweede implementatie.

Bijna volledige omgeving

In onze voorbeelddoelomgeving liggen vier van de acht racks dicht bij de capaciteit. Laten we proberen een ander NKS-cluster te starten.

Cluster E heeft de volgende specificaties:

  • Besturingsvlak, NC_G24_112_v1 SKU, vijf aantallen
  • Agentpool #1, NC_P46_224_v1 SKU, aantal 32

Hier volgt een tabel met een samenvatting van wat de gebruiker moet zien na het starten van Cluster E in de doelomgeving.

Cluster Groep SKU Totaal aantal Verwachte #Racks Werkelijke # rekken Verwachte # VM's per rek Werkelijke aantal VM's per rack
E Besturingsvlak NC_G24_112_v1 5 5 5 1 1
E Agentgroep 1 NC_P46_224_v1 32 8 8 4 3, 4 of 5

De agentgroep #1 van cluster E verspreidt zich ongelijkmatig over alle acht rekken. Racks 7 en 8 hebben drie NKS-VM's uit agentgroep 1 in plaats van de verwachte vier NKS-VM's, omdat er geen capaciteit meer is voor de extra grote SKU-VM's in die racks na het plannen van clusters A tot en met D. Omdat racks 7 en 8 geen capaciteit hebben voor de vierde extra grote SKU in agentgroep #1, landen vijf NKS-VM's op de twee minst gebruikte racks. In ons voorbeeld waren die minst gebruikte racks rekken 3 en 6.

Hier volgt een visualisatie van een indeling die de gebruiker kan zien na het implementeren van Cluster E in de doelomgeving.

Diagram met mogelijke indeling van VM's na de derde implementatie.

Plaatsing tijdens een runtime-upgrade

Vanaf april 2024 (Network Cloud 2304.1 release) worden runtime-upgrades uitgevoerd met behulp van een rack-by-rack-strategie. Bare-metalservers in rack 1 worden allemaal in één keer hersteld. Het upgradeproces wordt onderbroken totdat alle bare-metalservers opnieuw zijn opgestart en nexus laten weten dat ze klaar zijn voor het ontvangen van workloads.

Notitie

Het is mogelijk om Operator Nexus te instrueren om slechts een deel van de bare-metalservers in een rek tegelijk te herstellen, maar de standaardinstelling is om alle bare-metalservers in een rek parallel opnieuw te maken.

Wanneer een afzonderlijke bare-metalserver wordt hersteld, gaan alle werkbelastingen die op die bare-metalserver worden uitgevoerd, inclusief alle NKS-VM's, stroom verloren en connectiviteit. Werkbelastingcontainers die op NKS-VM's worden uitgevoerd, verliezen op hun beurt stroom en connectiviteit. Na één minuut dat deze workloadcontainers niet kunnen worden bereikt, markeert het Kubernetes-besturingsvlak van het NKS-cluster de bijbehorende pods als beschadigd. Als de pods lid zijn van een Implementatie of StatefulSet, probeert het Kubernetes-besturingsvlak van het NKS-cluster vervangingspods te starten om het waargenomen aantal replica's van de implementatie of StatefulSet terug te brengen naar het gewenste aantal replica's.

Nieuwe pods worden alleen gestart als er capaciteit beschikbaar is voor de Pod in de resterende gezonde NKS-VM's. Vanaf april 2024 (Network Cloud 2304.1 release) worden er geen nieuwe NKS-VM's gemaakt ter vervanging van NKS-VM's die zich op de bare-metalserver bevinden.

Zodra de bare-metalserver is hersteld en nieuwe NKS-VM's kan accepteren, worden de NKS-VM's die oorspronkelijk op dezelfde bare-metalserver waren geïnstalleerd, opnieuw opgestart op de nieuw herstelde bare-metalserver. Workloadcontainers kunnen vervolgens worden gepland op die NKS-VM's, waardoor de implementaties of StatefulSets met pods op NKS-VM's die zich op de bare-metalserver bevonden, kunnen worden hersteld.

Notitie

Dit gedrag kan de gebruiker lijken alsof de NKS-VM's niet van de bare-metalserver zijn verplaatst, wanneer in feite een nieuw exemplaar van een identieke NKS-VM werd gestart op de nieuw herstelde bare-metalserver die dezelfde bare-metalservernaam behoudt als vóór het opnieuw maken van de installatiekopie.

Aanbevolen procedures

Houd bij het werken met Operator Nexus rekening met de volgende aanbevolen procedures.

  • Vermijd het AvailabilityZones opgeven van een agentgroep.
  • Start grotere NKS-clusters vóór kleinere clusters.
  • Verminder het aantal agentgroepen voordat u de VM-SKU-grootte verkleint.

Vermijd het opgeven van beschikbaarheidszones voor een agentgroep

Zoals u in de bovenstaande plaatsingsscenario's kunt zien, is het opgeven AvailabilityZones voor een agentgroep de primaire reden dat NKS-VM's uit hetzelfde NKS-cluster op dezelfde bare-metalserver terechtkomen. Door op te geven AvailabilityZones, maakt u de agentgroep vast aan een subset van racks en beperkt u daarom het aantal potentiële bare-metalservers in die set rekken voor andere NKS-clusters en andere agentgroep-VM's in hetzelfde NKS-cluster om op te komen.

Daarom is het de eerste best practice om te voorkomen dat een agentgroep wordt opgegeven AvailabilityZones . Als u een agentgroep wilt vastmaken aan een set Beschikbaarheidszones, moet u deze zo groot mogelijk maken om de onevenwichtigheid te minimaliseren die kan optreden.

De enige uitzondering op deze aanbevolen procedure is wanneer u een scenario hebt met slechts twee of drie VM's in een agentgroep. U kunt overwegen om deze agentgroep in te stellen AvailabilityZones voor [1,3,5,7] of [0,2,4,6] om de beschikbaarheid tijdens runtime-upgrades te verhogen.

Grotere NKS-clusters starten vóór kleinere clusters

Vanaf april 2024 en de release Network Cloud 2403.1 worden NKS-clusters gepland in de volgorde waarin ze worden gemaakt. Als u uw doelomgeving het meest efficiënt wilt inpakken, raden we u aan grotere NKS-clusters te maken vóór kleinere clusters. Op dezelfde manier raden we u aan grotere agentpools te plannen vóór kleinere pools.

Deze aanbeveling is belangrijk voor agentgroepen die gebruikmaken van de extra grote NC_G48_224_v1 of NC_P46_224_v1 SKU. Het plannen van de agentgroepen met het grootste aantal van deze extra grote SKU-VM's maakt een grotere set bare-metalservers waarop andere extra grote SKU-VM's uit agentgroepen in andere NKS-clusters kunnen worden gebruikt.

Verminder het aantal agentgroepen voordat u de VM-SKU-grootte verkleint

Als u capaciteitsbeperkingen krijgt bij het starten van een NKS-cluster of agentgroep, vermindert u het aantal agentgroepen voordat u de VM-SKU-grootte aanpast. Als u bijvoorbeeld probeert een NKS-cluster te maken met een agentgroep met vm-SKU-grootte van NC_P46_224_v1 en een telling van 24 en een fout bij het inrichten van het NKS-cluster vanwege onvoldoende resources, is het misschien verleidelijk om een VM-SKU-grootte te gebruiken van NC_P36_168_v1 en door te gaan met een telling van 24. Vanwege de vereisten voor workload-VM's die moeten worden afgestemd op één NUMA-cel op een bare-metalserver, is het waarschijnlijk dat dezelfde aanvraag resulteert in vergelijkbare onvoldoende resourcefouten. In plaats van de VM-SKU-grootte te verminderen, kunt u overwegen het aantal agentgroepen te verminderen tot 20. Er is een betere kans dat uw aanvraag binnen de resourcecapaciteit van de doelomgeving past en uw algehele implementatie meer CPU-kernen heeft dan als u de VM-SKU hebt verkleind.