Ressourcenplatzierung in Azure Operator Nexus Kubernetes

Operator Nexus-Instanzen werden beim Kunden vor Ort bereitgestellt. Jede Instanz besteht aus einem oder mehreren Racks von Bare-Metal-Servern.

Wenn ein Benutzer einen Nexus Kubernetes-Cluster (NKS) erstellt, gibt er eine Anzahl und eine Stock Keeping Unit (SKU) für virtuelle Computer (VMs) an, aus denen die Kubernetes-Steuerungsebene und mindestens ein Agentpool bestehen. Agentpools sind der Satz von Workerknoten, auf denen die containerisierten Netzwerkfunktionen eines Kunden ausgeführt werden.

Die Nexus-Plattform ist dafür verantwortlich, den Bare-Metal-Server zu bestimmen, auf dem jede NKS-VM gestartet wird.

Planen einer Nexus Kubernetes-Cluster-VM mit der Nexus-Plattform

Nexus identifiziert zunächst die Menge der potenziellen Bare-Metal-Server, die alle Ressourcenanforderungen der NKS-VM-SKU erfüllen. Wenn der Benutzer beispielsweise eine VM-SKU NC_G48_224_v1 für seinen Agentpool angegeben hat, sammelt Nexus die Bare-Metal-Server mit verfügbarer Kapazität für 48 vCPU, 224Gi RAM usw.

Nexus untersucht dann das AvailabilityZones-Feld für den Agentpool oder die Steuerungsebene, die geplant werden. Wenn dieses Feld nicht leer ist, filtert Nexus die Liste potenzieller Bare-Metal-Server auf nur die Server in den angegebenen Verfügbarkeitszonen (Racks). Dieses Verhalten ist eine harte Planungseinschränkung. Wenn in der gefilterten Liste keine Bare-Metal-Server vorhanden sind, plant Nexus die NKS-VM nicht, und der Cluster kann nicht bereitgestellt werden.

Sobald Nexus eine Liste potenzieller Bare-Metal-Server identifiziert, auf denen die NKS-VM platziert werden soll, wählt Nexus einen der Bare-Metal-Server aus, nachdem die folgenden Sortierregeln angewendet wurden:

1. Bevorzugen von Bare-Metal-Servern in Verfügbarkeitszonen (Racks), die keine NKS-VMs von diesem NKS-Cluster haben. Mit anderen Worten: Verteilen der NKS-VMs für einen NKS-Cluster über Verfügbarkeitszonen hinweg

2. Bevorzugen von Bare-Metal-Servern in einer einzelnen Verfügbarkeitszone (Rack), die keine anderen NKS-VMs aus demselben NKS-Cluster haben. Mit anderen Worten: Verteilen der NKS-VMs für einen NKS-Cluster über Bare-Metal-Server innerhalb einer Verfügbarkeitszone

3. Wenn die NKS-VM-SKU entweder NC_G48_224_v1 oder NC_P46_224_v1 ist: Bevorzugen von Bare-Metal-Servern, die bereits NKS-VMs vom Typ NC_G48_224_v1 oder NC_P46_224_v1 von anderen NKS-Clustern beherbergen. Mit anderen Worten: Gruppieren der extragroßen VMs aus verschiedenen NKS-Clustern auf denselben Bare-Metal-Servern. Diese Regel „bin packs“ die extragroßen VMs, um die Fragmentierung der verfügbaren Computeressourcen zu verringern.

Beispiel für Platzierungsszenarien

Die folgenden Abschnitte heben das Verhalten hervor, das Nexus-Benutzer beim Erstellen von NKS-Clustern für eine Operator Nexus-Umgebung erwarten sollten.

Hinweis: Sie können sehen, auf welchem Bare-Metal-Server Ihre NKS-VMs geplant wurden, indem Sie die nodes.bareMetalMachineId-Eigenschaft der NKS-KubernetesCluster-Ressource untersuchen oder die Spalte „Host“ in der Anzeige von Kubernetes-Clusterknoten im Azure-Portal anzeigen.

Die Operator Nexus-Beispielumgebung weist diese Spezifikationen auf:

• Acht Racks mit je 16 Bare-Metal-Servern
• Jeder Bare-Metal-Server enthält zwei Non Uniform Memory Access (NUMA)-Zellen
• Jede NUMA-Zelle bietet 48 CPU und 224Gi RAM

Leere Umgebung

Ausgehend von einer leeren Operator Nexus-Umgebung mit der gegebenen Kapazität erstellen wir drei unterschiedlich große Nexus Kubernetes-Cluster.

Die NKS-Cluster haben diese Spezifikationen, und wir gehen für die Zwecke dieser Übung davon aus, dass der Benutzer die drei Cluster in der folgenden Reihenfolge erstellt:

Cluster A

• Steuerungsebene, NC_G12_56_v1-SKU, Anzahl drei
• Agentpool Nr. 1, NC_P46_224_v1-SKU, Anzahl 24
• Agentpool Nr. 2, NC_G6_28_v1-SKU, Anzahl sechs

Cluster B

• Steuerungsebene, NC_G24_112_v1-SKU, Anzahl fünf
• Agentpool Nr. 1, NC_P46_224_v1-SKU, Anzahl 48
• Agentpool Nr. 2, NC_P22_112_v1-SKU, Anzahl 24

Cluster C

• Steuerungsebene, NC_G12_56_v1-SKU, Anzahl drei
• Agentpool Nr. 1, NC_P46_224_v1-SKU, Anzahl 12, AvailabilityZones = [1,4]

Hier ist eine Tabelle, die zusammenfasst, was der Benutzer nach dem Starten der Cluster A, B und C in einer leeren Operator Nexus-Umgebung sehen sollte.

Cluster	Pool	SKU	Gesamtanzahl	Erwartete Anzahl Racks	Aktuelle Anzahl Racks	Erwartete Anzahl VMs pro Rack	Aktuelle Anzahl VMs pro Rack
A	Steuerungsebene	NC_G12_56_v1	3	3	3	1	1
Ein	Agentpool Nr. 1	NC_P46_224_v1	24	8	8	3	3
Ein	Agentpool Nr. 2	NC_G6_28_v1	6	6	6	1	1
B	Steuerungsebene	NC_G24_112_v1	5	5	5	1	1
B	Agentpool Nr. 1	NC_P46_224_v1	48	8	8	6	6
b	Agentpool Nr. 2	NC_P22_112_v1	24	8	8	3	3
K	Steuerungsebene	NC_G12_56_v1	3	3	3	1	1
C	Agentpool Nr. 1	NC_P46_224_v1	12	2	2	6	6

Es gibt acht Racks, sodass die VMs für jeden Pool auf bis zu acht Racks verteilt sind. Pools mit mehr als acht VMs erfordern mehrere VMs pro Rack, die sich auf verschiedene Bare-Metal-Server verteilen.

Der Agentpool Nr. 1 in Cluster C verfügt über 12 VMs, die auf AvailabilityZones [1, 4] beschränkt sind, sodass er über 12 VMs auf 12 Bare-Metal-Servern verfügt, sechs in jedem der Racks 1 und 4.

Extragroße VMs (die NC_P46_224_v1-SKU) aus verschiedenen Clustern werden auf denselben Bare-Metal-Servern platziert (siehe Regel Nr. 3 unter Planen einer Nexus Kubernetes-Cluster-VM mit der Nexus-Plattform).

Hier ist eine Visualisierung eines Layouts, das der Benutzer nach der Bereitstellung der Cluster A, B und C in einer leeren Umgebung sehen könnte.

Halbvolle Umgebung

Wir durchlaufen nun ein Beispiel zum Starten eines anderen NKS-Clusters, wenn die Zielumgebung halb voll ist. Die Zielumgebung ist halb voll, nachdem Cluster A, B und C in der Zielumgebung bereitgestellt wurden.

Cluster D weist die folgenden Spezifikationen auf:

• Steuerungsebene, NC_G24_112_v1-SKU, Anzahl fünf
• Agentpool Nr. 1, NC_P46_224_v1-SKU, Anzahl 24, AvailabilityZones = [7,8]
• Agentpool Nr. 2, NC_P22_112_v1-SKU, Anzahl 24

Hier ist eine Tabelle, die zusammenfasst, was der Benutzer nach dem Starten von Cluster D in der halbvollen Operator Nexus-Umgebung sehen sollte, die nach dem Starten der Cluster A, B und C vorhanden ist.

Cluster	Pool	SKU	Gesamtanzahl	Erwartete Anzahl Racks	Aktuelle Anzahl Racks	Erwartete Anzahl VMs pro Rack	Aktuelle Anzahl VMs pro Rack
D	Steuerungsebene	NC_G12_56_v1	5	5	5	1	1
D	Agentpool Nr. 1	NC_P46_224_v1	24	2	2	12	12
D	Agentpool Nr. 2	NC_P22_112_v1	24	8	8	3	3

Der Agentpool Nr. 1 in Cluster D verfügt über 12 VMs, die auf AvailabilityZones [7, 8] beschränkt sind, sodass er über 12 VMs auf 12 Bare-Metal-Servern verfügt, sechs in jedem der Racks 7 und 8. Diese VMs landen auf Bare-Metal-Servern, die auch große VMs aus anderen Clustern beinhalten, da die Sortierregel extragroße VMs aus verschiedenen Clustern auf denselben Bare-Metal-Servern gruppiert.

Wenn eine VM der Cluster D-Steuerungsebene auf Rack 7 oder 8 landet, liegt es wahrscheinlich daran, dass der Agentpool Nr. 1 in Cluster D auf demselben Bare-Metal-Server wie diese VM der Cluster D-Steuerungsebene landet. Dieses Verhalten liegt daran, dass der Agentpool Nr. 1 an die Racks 7 und 8 „angeheftet“ wird. Kapazitätseinschränkungen in diesen Racks führen dazu, dass der Scheduler eine VM der Steuerungsebene und eine VM im Agentpool Nr. 1 aus demselben NKS-Cluster anordnet.

Der Agentpool Nr. 2 im Cluster D verfügt über drei VMs auf verschiedenen Bare-Metal-Servern auf jedem der acht Racks. Die Kapazitätsbeschränkungen resultierten daraus, dass der Agentpool Nr. 1 im Cluster D an die Racks 7 und 8 angeheftet war. Daher werden VMs aus dem Agentpool Nr. 1 und dem Agentpool Nr. 2 im Cluster D auf denselben Bare-Metal-Servern in Racks 7 und 8 angeordnet.

Hier ist eine Visualisierung eines Layouts, das der Benutzer nach der Bereitstellung von Cluster D in der Zielumgebung sehen könnte.

Nahezu volle Umgebung

In unserer Beispielzielumgebung sind vier der acht Racks nahe an der Kapazität. Versuchen wir, einen anderen NKS-Cluster zu starten.

Der Cluster E weist die folgenden Spezifikationen auf:

• Steuerungsebene, NC_G24_112_v1-SKU, Anzahl fünf
• Agentpool Nr. 1, NC_P46_224_v1-SKU, Anzahl 32

Hier ist eine Tabelle, die zusammenfasst, was der Benutzer nach dem Starten von Cluster E in der Zielumgebung sehen sollte.

Cluster	Pool	SKU	Gesamtanzahl	Erwartete Anzahl Racks	Aktuelle Anzahl Racks	Erwartete Anzahl VMs pro Rack	Aktuelle Anzahl VMs pro Rack
E	Steuerungsebene	NC_G24_112_v1	5	5	5	1	1
E	Agentpool Nr. 1	NC_P46_224_v1	32	8	8	4	3, 4 oder 5

Der Agentpool Nr. 1 von Cluster E verteilt sich ungleichmäßig über alle acht Racks. Die Racks 7 und 8 werden über drei NKS-VMs aus dem Agentpool Nr. 1 verfügen anstelle der erwarteten vier NKS-VMs, da es nach der Planung der Cluster A bis D keine Kapazität mehr für die extragroßen SKU-VMs in diesen Racks gibt. Da Rack 7 und 8 keine Kapazität für die vierte extra große SKU im Agentpool Nr. 1 haben, landen fünf NKS-VMs auf den beiden am wenigsten ausgelasteten Racks. In unserem Beispiel waren diese am wenigsten ausgelasteten Racks die Racks 3 und 6.

Hier ist eine Visualisierung eines Layouts, das der Benutzer nach der Bereitstellung von Cluster E in der Zielumgebung sehen könnte.

Platzierung während eines Runtimeupgrades

Ab April 2024 (Network Cloud-Release 2304.1) werden Runtimeupgrades mit einer Rack-nach-Rack-Strategie durchgeführt. Für Bare-Metal-Server in Rack 1 wird das Reimaging für alle gleichzeitig durchgeführt. Der Upgradeprozess wird angehalten, bis alle Bare-Metal-Server erfolgreich neu starten und Nexus mitteilen, dass sie bereit sind, Workloads zu empfangen.

Hinweis

Es ist möglich, Operator Nexus anzuweisen, das Reimaging nur für einen Teil der Bare-Metal-Server in einem Rack gleichzeitig durchzuführen, aber der Standard ist, das Reimaging für alle Bare-Metal-Server in einem Rack parallel durchzuführen.

Wenn für einen einzelnen Bare-Metal-Server ein Reimaging durchgeführt wird, verlieren alle Workloads, die auf diesem Bare-Metal-Server ausgeführt werden, einschließlich aller NKS-VMs, sowohl Strom als auch Konnektivität. Workloadcontainer, die auf NKS-VMs ausgeführt werden, verlieren ihrerseits Strom und Konnektivität. Wenn diese Workloadcontainer eine Minute lang nicht erreicht werden können, markiert die Kubernetes-Steuerungsebene des NKS-Clusters die entsprechenden Pods als fehlerhaft. Wenn die Pods Mitglieder einer Bereitstellung oder eines StatefulSet sind, versucht die Kubernetes-Steuerungsebene des NKS-Clusters, Ersatzpods zu starten, um die beobachtete Replikatanzahl der Bereitstellung oder des StatefulSet wieder auf die gewünschte Replikatanzahl festzulegen.

Neue Pods werden nur gestartet, wenn auf den verbleibenden fehlerfreien NKS-VMs Kapazität für den Pod verfügbar ist. Ab April 2024 (Network Cloud-Release 2304.1) werden keine neuen NKS-VMs erstellt, um NKS-VMs zu ersetzen, die sich auf dem Bare-Metal-Server befanden, für den ein Reimaging durchgeführt wurde.

Sobald für den Bare-Metal-Server erfolgreich ein Reimaging durchgeführt wurde und er in der Lage ist, neue NKS-VMs zu akzeptieren, werden die NKS-VMs, die ursprünglich auf demselben Bare-Metal-Server waren, auf dem Bare-Metal-Server neu gestartet, für den ein Reimaging durchgeführt wurde. Workloadcontainer können dann für diese NKS-VMs geplant werden, wodurch möglicherweise die Bereitstellungen oder StatefulSets wiederhergestellt werden, die Pods auf NKS-VMs hatten, die sich auf dem Bare-Metal-Server befanden.

Hinweis

Dieses Verhalten kann dem Benutzer so erscheinen, als ob die NKS-VMs nicht vom Bare-Metal-Server „verschoben“ wurden, wenn tatsächlich eine neue Instanz einer identischen NKS-VM auf dem Bare-Metal-Server mit neuem Reimaging gestartet wurde, die den gleichen Namen des Bare-Metal-Servers wie vor dem Reimaging beibehalten hat.

Bewährte Methoden

Beachten Sie beim Arbeiten mit Operator Nexus die folgenden bewährten Methoden.

• Vermeiden Sie die Angabe von AvailabilityZones für einen Agentpool.
• Starten größerer NKS-Cluster vor kleineren Clustern
• Reduzieren Sie die Anzahl des Agentpools, bevor Sie die Größe der VM-SKU verringern.

Vermeiden Sie die Angabe von AvailabilityZones für einen Agentpool

Wie Sie anhand der obigen Platzierungsszenarien feststellen können, ist die Angabe von AvailabilityZones für einen Agentpool der Hauptgrund, warum NKS-VMs aus demselben NKS-Cluster auf demselben Bare-Metal-Server enden würden. Indem Sie AvailabilityZones angeben, „heften“ Sie den Agentpool an eine Teilmenge von Racks an und beschränken daher die Anzahl potenzieller Bare-Metal-Server in dieser Gruppe von Racks, auf denen andere NKS-Cluster und andere Agentpool-VMs im selben NKS-Cluster landen können.

Daher besteht unsere erste bewährte Methode darin, die Angabe von AvailabilityZones für einen Agentpool zu vermeiden. Wenn Sie einen Agentpool an eine Menge von Verfügbarkeitszonen anheften müssen, sollten Sie diese Menge so groß wie möglich festlegen, um das Ungleichgewicht zu minimieren, das auftreten kann.

Die einzige Ausnahme zu dieser bewährten Methode ist, wenn Sie ein Szenario mit nur zwei oder drei VMs in einem Agentpool haben. Sie können erwägen, AvailabilityZones für diesen Agentpool auf [1,3,5,7] oder [0,2,4,6] festzulegen, um die Verfügbarkeit während Runtimeupgrades erhöhen.

Starten größerer NKS-Cluster vor kleineren Clustern

Ab April 2024 und dem Network Cloud-Release 2403.1 werden NKS-Cluster in der Reihenfolge geplant, in der sie erstellt werden. Um Ihre Zielumgebung am effizientesten zu packen, empfehlen wir Ihnen, größere NKS-Cluster vor kleineren zu erstellen. Ebenso empfehlen wir Ihnen, größere Agentpools vor kleineren zu planen.

Diese Empfehlung ist für Agentpools wichtig, welche die extragroße NC_G48_224_v1- oder NC_P46_224_v1-SKU verwenden. Bei der Planung der Agentpools mit der größten Anzahl dieser extragroßen SKU-VMs wird eine größere Menge von Bare-Metal-Servern erstellt, auf denen andere extragroße SKU-VMs aus Agentpools in anderen NKS-Clustern angeordnet werden können.

Verringern der Anzahl des Agentpools vor der Verringerung der VM-SKU-Größe

Wenn beim Starten eines NKS-Clusters oder Agentpools Kapazitätseinschränkungen auftreten, verringern Sie die Anzahl des Agentpools, bevor Sie die Größe der VM-SKU anpassen. Wenn Sie beispielsweise versuchen, einen NKS-Cluster mit einem Agentpool mit VM-SKU-Größe NC_P46_224_v1 und einer Anzahl von 24 zu erstellen und einen Fehler bei der Bereitstellung des NKS-Cluster aufgrund unzureichender Ressourcen erhalten, könnten Sie versucht sein, eine VM-SKU-Größe von NC_P36_168_v1 zu verwenden und mit der Anzahl 24 fortzufahren. Aufgrund der Anforderungen, dass Workload-VMs an eine einzelne NUMA-Zelle auf einem Bare-Metal-Server ausgerichtet sein müssen, ist es wahrscheinlich, dass dieselbe Anforderung zu ähnlichen Fehlern mit unzureichenden Ressourcen führt. Anstatt die Größe der VM-SKU zu verringern, sollten Sie die Anzahl des Agentpools auf 20 reduzieren. Die Wahrscheinlichkeit ist größer, dass Ihre Anforderung in die Ressourcenkapazität der Zielumgebung passt und Ihre Gesamtbereitstellung über mehr CPU-Kerne verfügt, als wenn Sie die VM-SKU verkleinern.