Erste Schritte mit der Clusterregistrierung

Verbessern Sie die Resilienz für cloudnative Netzwerkfunktionen mit der Azure Operator Service Manager-Clusterregistrierung (AOSM, CR)

Dokumentverlauf

• Erstellt und zum ersten Mal veröffentlicht: 26. Juli 2024
• Aktualisiert für Hochverfügbarkeit: 16. Oktober 2024
• Aktualisiert für GC: 5. November 2024

Featureabhängigkeiten

Dieses Feature erfordert die folgende Mindestumgebung:

• Mindestversion der AOSM-ARM-API: 2023-09-01
• Erste Version, keine Hochverfügbarkeit (HA) für die Netzwerkfunktion-Kubernetes-Erweiterung (NF): 1.0.2711-7
• Erste Version mit HA für NF-Kubernetes-Erweiterung: 2.0.2810-144
• Erste Version mit HA für die NF-Kubernetes-Erweiterung: 2.0.2860-160

Übersicht über die Clusterregistrierung

Die Azure Operator Service Manager-Clusterregistrierung (AOSM) ermöglicht eine lokale Kopie von Containerimages im Nexus K8s-Cluster. Wenn die Containernetzwerkfunktion (CNF) mit aktivierter Clusterregistrierung (CR) installiert wird, werden die Containerimages aus dem AOSM-Remoteartefaktspeicher abgerufen und in dieser lokalen Containerregistrierung gespeichert. Mithilfe eines veränderlichen Webhooks fängt die Clusterregistrierung automatisch Imageanforderungen ab und ersetzt den lokalen Registrierungspfad, um Paketänderungen des Herausgebers zu vermeiden. Bei der Clusterregistrierung übersteht der CNF-Zugriff auf Containerimages den Verlust der Konnektivität zum Remoteartefaktspeicher.

Wichtige Anwendungsfälle und Vorteile

Cloudnative Netzwerkfunktionen (CNF) benötigen Zugriff auf Containerimages nicht nur während der Erstbereitstellung mithilfe des AOSM-Artefaktspeichers, sondern auch zur Aufrechterhaltung des Betriebs von Netzwerkfunktionen. Einige mögliche Szenarien:

• Pod-Neustarts: Das Beenden und Starten eines Pods kann dazu führen, dass Containerimages von einem Clusterknoten aus der Registrierung gepullt werden.
• Kubernetes-Planervorgänge: Wenn der neue Knoten die Containerimages nicht lokal zwischenspeichert, pullt der Knoten bei der Zuweisung von Pods zu Knoten gemäß des Planerprofils Containerimages aus der Registrierung.

Vorteile der Verwendung der AOSM-Clusterregistrierung:

• Stellt die erforderlichen lokalen Images bereit, um CNF-Unterbrechungen zu verhindern, wenn die Verbindung mit dem AOSM-Artefaktspeicher getrennt wird
• Verringert die Anzahl der Imagepulls im AOSM-Artefaktspeicher, da jeder Clusterknoten jetzt nur Images aus der lokalen Registrierung abruft
• Behebt Probleme mit falsch formatierten Registrierungs-URLs, indem ein veränderlicher Webhook verwendet wird, um den richtigen lokalen Registrierungs-URL-Pfad zu ersetzen

Funktionsweise der Clusterregistrierung

Die AOSM-Clusterregistrierung wird mithilfe der Arc-K8s-Erweiterung „Network Function Operator“ (NFO) aktiviert. Die folgende CLI zeigt, wie die Clusterregistrierung für einen Nexus K8s-Cluster aktiviert wird.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

Wenn das Clusterregistrierungsfeature in der Arc K8s-Erweiterung „Network Function Operator“ aktiviert ist, sind alle Containerimages, die über den AOSM-Artefaktspeicher bereitgestellt werden, lokal im Nexus K8s-Cluster zugänglich. Der Benutzer kann die Größe des beständigen Speichers für die Clusterregistrierung auswählen.

Hinweis

Wenn der Benutzer keine Angabe macht, wird ein standardmäßiges persistentes Volume von 100 GB verwendet.

Komponenten der Containerregistrierung

Das Clusterregistrierungsfeature stellt Hilfspods im Zieledgecluster bereit, um die NFO-Erweiterung zu unterstützen.

Komponentenabstimmung

• Dieser Hauptpod kümmert sich um die Abstimmung der CRO-Komponente (Custom Resource Object), die von K8sBridge mithilfe des Ressourcenanbieters „Microsoft.Kubernetes“, der Hybridweiterleitung und des Arc-Agents erstellt wurden, die im Cluster ausgeführt werden.

Webhook für die Podänderung

• Diese Pods implementieren veränderliche Eintrittswebhooks von Kubernetes für eine Instanz der Mutate-API. Die Mutate-API führt zwei Dinge aus:
  • Sie ändert den Registrierungspfad des Image in die IP-Adresse der lokalen Registrierung und ersetzt die Azure Container Registry (ACR) des AOSM Artefaktspeichers.
  • Sie erstellt eine Artefakt-CR im Edgecluster.

Artefaktabstimmung

• Dieser Pod stimmt Artefakt-CROs ab, die durch den veränderlichen Webhook erstellt wurden.

Registrierung

• Dieser Pod speichert Containerimages für CNF und ruft sie ab.

Clusterregistrierung: Garbage Collection

Die AOSM-Clustererweiterung führt einen GC-Auftrag (Garbage Collection) im HIntergrund aus, um Containerimages regelmäßig zu bereinigen. Dieser Auftrag wird gemäß Zeitplan ausgeführt und überprüft, ob der Clusterregistrierungsverbrauch den angegebenen Schwellenwert erreicht hat. Wenn ja, wird der Garbage Collection-Prozess initiiert. Der Auftragsplan und der Schwellenwert werden vom Endbenutzer konfiguriert, der Auftrag wird jedoch standardmäßig einmal pro Tag mit einem 0 %-Auslastungsschwellenwert ausgeführt.

Bereinigen von Garbage Image-Manifesten

AOSM verwaltet Verweise zwischen der Podbesitzerressource und dem Verbrauch von Images in der Clusterregistrierung. Beim Initiieren des Bereinigungsprozesses für Images werden Images identifiziert, die nicht mit Pods verknüpft sind, wodurch ein vorläufiges Löschen aus der Clusterregistrierung ausgelöst wird. Bei dieser Art von vorläufigem Löschen wird nicht sofort Speicherplatz für Clusterregistrierungen freigegeben. Die tatsächliche Entfernung von Image-Dateien hängt von der unten beschriebenen Garbage Collection der CNCF-Verteilungsregistrierung ab.

Hinweis

Durch den Verweis zwischen dem Besitzer und den Containerimages eines Pods wird sichergestellt, dass AOSM keine Images versehentlich löscht. Wenn beispielsweise ein Replikatset-Pod ausfällt, dereferenziert AOSM die Containerimages nicht. AOSM dereferenziert Containerimages nur, wenn das Replikatset gelöscht wird. Das gleiche Prinzip gilt für Pods, die von Kubernetes-Aufträgen und Daemonsets verwaltet werden.

CNCF Garbage Collection-Verteilung

AOSM richtet die Clusterregistrierung mithilfe der Open Source CNCF-Verteilungsregistrierung ein. Daher basiert AOSM auf Garbage Collection-Funktionen, die von Garbage Collection | CNCF Distribution bereitgestellt werden. Insgesamt folgt es der Standardphase 2 „Markieren und aufräumen“, um Imagedateien zum Freigeben von Registrierungsspeicherplatz zu löschen.

Hinweis

Für diesen Vorgang ist die Clusterregistrierung im schreibgeschützten Modus erforderlich. Wenn Images hochgeladen werden, wenn sich die Registrierung nicht im schreibgeschützten Modus befindet, besteht das Risiko, dass Imageebenen versehentlich gelöscht werden, was zu einem beschädigten Image führt. Die Registrierung erfordert eine Sperre im schreibgeschützten Modus für eine Dauer von bis zu 1 Minute. Daher wird AOSM andere NF-Bereitstellungen zurückstellen, wenn die Clusterregistrierung im schreibgeschützten Modus erfolgt.

Konfigurationsparameter für die Garbage Collection

Die folgenden Parameter konfigurieren den Zeitplan und den Schwellenwert für den Garbage Collection-Auftrag.

• global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
• global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
• Weitere Konfigurationsdetails finden Sie in den neusten Installationsanweisungen zur Netzwerkfunktionserweiterung

Überlegungen zu Hochverfügbarkeit und Resilienz

Die AOSM-NF-Erweiterung verwendet einen mutierenden Webhook und eine Edge-Registrierung, um wichtige Features zu unterstützen.

• Onboarding von Helm-Charts ohne Anpassen des Bildpfads
• Eine lokale Clusterregistrierung, um Pod-Vorgänge zu beschleunigen und die Unterstützung im getrennten Modus zu aktivieren Diese wesentlichen Komponenten müssen hochverfügbar und resilient sein.

Zusammenfassung der Änderungen für HA

Mit HA unterstützen die Clusterregistrierung und Webhook-Pods jetzt ein ReplicaSet mit mindestens drei und maximal fünf Replikaten. Die Schlüsselkonfiguration des ReplicaSets lautet wie folgt:

• Das Rolloutupgrade wird schrittweise durchgeführt.
• PodDisruptionBudgets (PDB) werden bei freiwilligen Unterbrechungen für die Verfügbarkeit verwendet.
• Pod-Antiaffinität wird verwendet, um Pods gleichmäßig auf Knoten zu verteilen.
• Bereitschaftstests werden verwendet, damit die Pods bereit sind, bevor Datenverkehr verarbeitet wird.
• AOSM-Workload-Pods werden nur dem Systemknotenpool zugewiesen.
• Pods skalieren unter CPU- und Speicherauslastung horizontal.

Replikate

• Ein Cluster mit mehreren Kopien oder Replikaten einer Anwendung stellt die erste Redundanzebene bereit. Sowohl die Clusterregistrierung als auch der Webhook werden als „kind:deployment“ mit mindestens drei Replikaten definiert.

DeploymentStrategy

• Eine rollingUpdate-Strategie wird verwendet, um Upgrades ohne Downtime durchzuführen und ein graduelles Anwendungsrollout zu unterstützen. Mit der maxUnavailable-Standardkonfiguration kann jeweils nur ein Pod zur selben Zeit heruntergefahren werden, bis genügend Pods erstellt werden, um die Redundanzrichtlinie zu erfüllen.

Pod-Unterbrechungsbudget

• Ein Richtlinienunterbrechungsbudget (Policy Disruption Budget, PDB) schützt Pods vor freiwilliger Unterbrechung und wird zusammen mit Deployment-, ReplicaSet- oder StatefulSet-Objekten bereitgestellt. Für AOSM-Operator-Pods wird ein PDB mit minAvailable-Parameter von 2 verwendet.

Pod-Antiaffinität

• Pod-Antiaffinität steuert die Verteilung von Anwendungs-Pods auf mehrere Knoten in Ihrem Cluster. Mit HA wird AOSM mithilfe der folgenden Parameter mit Pod-Antiaffinität verwendet:
  • Ein Planungsmodus wird verwendet, um zu definieren, wie streng die Regel umgesetzt wird.
    • requiredDuringSchedulingIgnoredDuringExecution(Hard): Pods müssen so geplant werden, dass die definierte Regel erfüllt ist. Wenn keine Topologien verfügbar sind, die den Anforderungen der Regel entsprechen, wird der Pod nicht geplant.
    • preferredDuringSchedulingIgnoredDuringExecution(Soft): Dieser Regeltyp bevorzugt das Planen von Pods, erzwingt dies jedoch nicht als unbedingt erforderlich. Wenn Topologien verfügbar sind, die den bevorzugten Kriterien entsprechen, plant Kubernetes den Pod. Wenn keine solchen Topologien verfügbar sind, kann der Pod weiterhin auf anderen Knoten geplant werden, die nicht der Präferenz entsprechen.
  • Eine Bezeichnungsauswahl wird zum Auswählen bestimmter Pods verwendet, auf die die Affinität angewendet wird.
  • Knotenanforderungen werden mit einem Topologieschlüssel definiert.
• Nexus-Knoten werden gleichmäßig auf die Zonen verteilt. Daher bietet das Verteilen von Pods auf Knoten auch Zonenredundanz.
• AOSM-Operator-Pods verwenden eine weiche Antiaffinität von 100 und einen auf Knotenhosts basierenden Topologieschlüssel.

Storage

• Da die AOSM-Edge-Registrierung über mehrere Replikate verfügt, die auf Knoten verteilt sind, muss das persistente Volume den ReadWriteMany-Zugriffsmodus (RWX) unterstützen. Ein „nexus-shared“-PVC-Volume ist auf Nexus-Clustern verfügbar und unterstützt den RWX-Zugriffsmodus.

Überwachen mit Bereitschaftstests

• AOSM verwendet http-Bereitschaftstests, um herauszufinden, wann ein Container zum Akzeptieren von Datenverkehr bereit ist. Ein Pod gilt als bereit, wenn alle Container bereit sind. Wenn ein Pod nicht bereit ist, wird er aus dem Dienstlastenausgleich entfernt.

Systemknotenpool

• Alle AOSM-Operator-Pods werden dem Systemknotenpool zugewiesen. Dieser Pool verhindert, dass falsch konfigurierte oder nicht autorisierte Anwendungs-Pods System-Pods beeinträchtigen.

Horizontale Skalierung

• In Kubernetes aktualisiert ein HorizontalPodAutoscaler (HPA) automatisch eine Workloadressource, um die Workload automatisch zu skalieren, damit sie dem Bedarf entspricht. AOSM-Operator-Pods verfügen über die folgenden konfigurierten HPA-Richtlinienparameter:
  • Mindestens drei Replikate
  • Höchstens fünf Replikate
  • 80 % targetAverageUtilization für CPU und Arbeitsspeicher

Ressourceneinschränkungen

• Ressourcengrenzwerte werden verwendet, um eine Ressourcenüberladung auf den Knoten zu verhindern, auf denen AOSM-Pods ausgeführt werden. AOSM verwendet zwei Ressourcenparameter, um sowohl den CPU- als auch den Speicherverbrauch zu begrenzen.
  • Ressourcenanforderung: Die Mindestmenge, die für einen Pod reserviert werden sollte. Dieser Wert sollte auf den Ressourceneinsatz unter normaler Anwendungslast festgelegt werden.
  • Ressourcenlimit: Die maximale Menge, die ein Pod verwenden sollte.Wenn der Verbrauch den Grenzwert erreicht, wird der Pod beendet. Alle AOSM-Operatorcontainer sind mit entsprechender Anforderung und entsprechendem Grenzwert für CPU und Arbeitsspeicher konfiguriert.

Bekannte HA-Einschränkungen

• Nexus AKS-Cluster (NAKS) mit einem einzigen aktiven Knoten im System-Agent-Pool eignen sich nicht für Hochverfügbarkeit. Die Nexus-Produktionstopologie muss mindestens drei aktive Knoten im System-Agent-Pool verwenden.
• Bei der „nexus-shared“-Speicherklasse handelt es sich um einen NFS-Speicherdienst (Network File System). Dieser NFS-Speicherdienst ist pro Clouddienstnetzwerk (Cloud Service Network, CSN) verfügbar. Jeder Nexus-Kubernetes-Cluster, der an das CSN angefügt ist, kann ein persistentes Volume aus diesem freigegebenen Speicherpool bereitstellen. Der Speicherpool ist derzeit auf eine maximale Größe von 1 TiB als Network Cloud 3.10 (NC) beschränkt, wobei NC 3.12 über eine Option mit 16 TiB verfügt.
• Pod-Antiaffinität bezieht sich nur auf die anfängliche Platzierung von Pods. Nachfolgende Pod-Skalierung und -Reparatur folgt K8-Standardplanungslogik.

Häufig gestellte Fragen

Kann ich die AOSM-Clusterregistrierung mit einer zuvor bereitgestellten CNF-Anwendung verwenden?

Wenn bereits eine CNF-Anwendung ohne Clusterregistrierung bereitgestellt wurde, sind die Containerimages nicht automatisch verfügbar. Die Clusterregistrierung muss aktiviert werden, bevor die Netzwerkfunktion mit AOSM bereitgestellt wird.

Kann ich die Speichergröße nach einer Bereitstellung ändern?

Die Speichergröße kann nach der Erstbereitstellung nicht geändert werden. Es wird empfohlen, die Größe des Volumes auf das 3- bis 4-Fache der Ausgangsgröße zu konfigurieren.

Kann ich die aktuell im Cluster-Repository gespeicherten Dateien auflisten?

Mit dem folgenden Befehl können Sie Dateien in einem lesbaren Format auflisten:

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Dieser Befehl sollte eine Ausgabe ähnlich wie die im Folgenden erzeugen:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0