Bewährte Methoden für Azure Operator Service Manager zum Onboarden und Bereitstellen von Netzwerkfunktionen

Artikel
10/07/2024

Microsoft hat viele bewährte Methoden für die Verwaltung von Netzwerkfunktionen (NFs) mithilfe von Azure Operator Service Manager entwickelt. Dieser Artikel enthält Leitfäden, die NF-Anbieter, Telekommunkationsbetreiber und deren Partner befolgen können, um das Design zu optimieren. Berücksichtigen Sie diese Methoden beim Onboarden und Bereitstellen Ihrer Netzwerkfunktionen.

Allgemeine Hinweise

Es wird empfohlen, zuerst das Onboarding für Ihre einfachsten Netzwerkfunktionen (ein oder zwei Charts) durchzuführen und diese bereitzustellen, indem Sie sich in den Schnellstarts mit dem allgemeinen Ablauf vertraut machen. Sie können in nachfolgenden Schritten Ihre erforderlichen Konfigurationsdetails hinzufügen. Beachten Sie beim Durcharbeiten der Schnellstarts die folgenden Punkte:

Strukturieren Sie Ihre Artefakte entsprechend der geplanten Verwendung. Erwägen Sie, globale Artefakte von den Artefakten zu trennen, die Sie je nach Standort oder Instanz variieren möchten.
Stellen Sie sicher, dass die Dienstzusammenstellung bei mehreren Netzwerkfunktionen mit Parametern übereinstimmt, die den Anforderungen Ihres Netzwerks entsprechen. Sie können beispielsweise über ein Chart mit 1.000 Werten verfügen, von denen Sie nur 100 anpassen. Stellen Sie auf der CGS-Ebene (Configuration Group Schema – in den folgenden Abschnitten ausführlicher behandelt) sicher, dass Sie nur 100 verfügbar machen.
Denken Sie insbesondere bei einem einzelnen Dienst frühzeitig darüber nach, wie Sie Infrastruktur (z. B. Cluster) oder Artefaktspeicher sowie den Zugriff zwischen Lieferanten trennen möchten. Passen Sie Ihre Herausgeberressourcen an dieses Modell an.
Eine Azure Operator Service Manager-Site ist ein logisches Konzept zur Darstellung eines Bereitstellungsziels. Beispiele sind ein Kubernetes-Cluster für containerisierte Netzwerkfunktionen (CNFs) oder ein erweiterter benutzerdefinierter Azure Operator Nexus-Standort für virtualisierte Netzwerkfunktionen (VNFs). Es handelt sich nicht um eine Darstellung eines physischen Edgestandorts, und es kann vorkommen, dass mehrere Sites denselben physischen Standort verwenden.
Azure Operator Service Manager bietet verschiedene APIs, die eine Kombination mit ADO oder anderen Pipelinetools vereinfachen.

Überlegungen zum Herausgeber

Es wird empfohlen, einen einzelnen Herausgeber pro Netzwerkfunktionsanbieter zu erstellen. Diese Vorgehensweise ermöglicht eine optimale Unterstützung, Wartung und Governance für alle Anbieter und vereinfacht den Entwurf Ihres Netzwerkdiensts, wenn sich dieser aus mehreren Netzwerkfunktionen verschiedener Anbieter zusammensetzt.
Nachdem die gewünschten Herausgeberressourcen und Artefakte von Azure Operator Service Manager getestet und für den Einsatz in der Produktion genehmigt wurden, sollten Sie alles als unveränderlich markieren, um versehentliche Änderungen zu verhindern und eine konsistente Bereitstellung zu gewährleisten. Erwägen Sie die Verwendung von Unveränderlichkeitsfunktionen, um zwischen Ressourcen und Artefakten in der Produktion und denen für Test- und Entwicklungszwecke zu unterscheiden. Sie können den Status der Herausgeberressourcen und der Artefaktmanifeste abfragen, um zu bestimmen, welche als unveränderlich gekennzeichnet sind. Weitere Informationen finden Sie unter Herausgebermandanten, Abonnements, Regionen und Vorschauverwaltung.

Beachten Sie folgende Logik:
- Wenn die Funktion in der Netzwerkdienst-Entwurfsversion (Network Service Design Version, NSDV) als unveränderlich markiert ist, muss auch das CGS als unveränderlich markiert sein. Andernfalls löst der Bereitstellungsaufruf einen Fehler aus.
- Wenn die Netzwerkfunktions-Entwurfsversion (Network Function Design Version, NFDV) als unveränderlich markiert ist, muss das Artefaktmanifest ebenfalls als unveränderlich markiert sein. Andernfalls löst der Bereitstellungsaufruf einen Fehler aus.
- Wenn nur das Artefaktmanifest oder das CGS als unveränderlich gekennzeichnet sind, wird der Bereitstellungsaufruf erfolgreich ausgeführt, unabhängig davon, ob die NFDV und NSDV als unveränderlich gekennzeichnet sind.
- Durch das Markieren eines Artefaktmanifests als unveränderlich wird sichergestellt, dass alle in diesem Manifest aufgeführten Artefakte (in der Regel Charts, Bilder und Azure Resource Manager-Vorlagen (ARM-Vorlagen)) unveränderlich sind, indem die erforderlichen Berechtigungen für den Artefaktspeicher erzwungen werden.
Erwägen Sie die Verwendung vereinbarter Benennungskonventionen und Governanceverfahren, um alle verbleibenden Lücken zu schließen.

Überlegungen zu Netzwerkfunktions-Definitionsgruppe und -version (NFDG/NFDV)

Die Netzwerkfunktions-Definitionsgruppe (Network Function Definition Group, NFDG) stellt die kleinste Komponente dar, die Sie unabhängig für mehrere Dienste wiederverwenden können. Sämtliche Teile einer NFDG werden immer zusammen bereitgestellt. Diese Teile werden als networkFunctionApplications bezeichnet. Beispielsweise ist es üblich, eine einzelne Netzwerkfunktion, die mehrere Helm-Charts und -Bilder umfasst, als einzelne NFDG zu integrieren, wenn Sie diese Komponenten immer gemeinsam bereitstellen. Wenn mehrere Netzwerkfunktionen immer zusammen bereitgestellt werden, ist es sinnvoll, alle in einer NFDG zusammenzufassen. Einzelne NFDGs können mehrere NFDVs enthalten.

Bei Definitionsversionen von containerisierten Netzwerkfunktionen (Containerized Network Function Definition Versions, CNF NFDVs) kann die networkFunctionApplications-Liste nur Helm-Pakete enthalten. Es ist sinnvoll, mehrere Helm-Pakete einzuschließen, wenn diese immer zusammen bereitgestellt und gelöscht werden.

Für Definitionsversionen virtualisierter Netzwerkfunktionen (Virtualized Network Function Definition Versions, VNF NFDVs) muss die networkFunctionApplications-Liste mindestens eine VhdImageFile und eine ARM-Vorlage enthalten. Die ARM-Vorlage sollte eine einzelne VM bereitstellen. Um mehrere VMs für eine einzelne VNF bereitzustellen, müssen Sie separate ARM-Vorlagen für jede VM verwenden.

Eine ARM-Vorlage kann nur Resource Manager-Ressourcen von den folgenden Ressourcenanbietern bereitstellen:

Microsoft.Compute
Microsoft.Network
Microsoft.NetworkCloud
Microsoft.Storage
Microsoft.NetworkFabric
Microsoft.Authorization
Microsoft.ManagedIdentity

Hinweis

Bei ARM-Vorlagen, die mehr als die vorherige Liste enthalten, führen alle PUT-Aufrufe und Re-PUT für die VNF zu einem Überprüfungsfehler.

Häufige Anwendungsfälle, die ein Update der Neben- oder Hauptversion einer Netzwerkfunktions-Entwurfsversion (NFDV) auslösen

Update von CGS oder CGVs (Configuration Group Values) für ein vorhandenes Release, das eine Änderung von deployParametersMappingRuleProfile auslöst
Änderung von Werten, die in der NFDV hartcodiert sind
Markieren von Komponenten als inaktiv, um deren Bereitstellung über applicationEnablement: Disabled zu verhindern
Neues NF-Release, z. B. Charts und Bilder

Hinweis

Minimale Anzahl von Änderungen, die bei jeder Änderung der Nutzdaten einer bestimmten Netzwerkfunktion erforderlich sind Bei Veröffentlichung einer Neben- oder Hauptversion einer Netzwerkfunktion, die keine neuen CGS-Parameter verfügbar macht, müssen nur das Artefaktmanifest aktualisiert, die neuen Bilder und Charts gepusht und die NFDV-Version ausgelöst werden.

Überlegungen zu Netzwerkdienst-Entwurfsgruppe und -version (NSDG/NSDV)

Die Netzwerkdienst-Entwurfsgruppe (Network Service Design Group, NSDG) ist eine Kombination aus mindestens einer NFDG und allen Infrastrukturkomponenten (z. B. Nexus Azure Kubernetes Service (NAKS), Azure Kubernetes Service (AKS), Azure Kubernetes Service-Cluster (AKS) und VMs), die gleichzeitig bereitgestellt werden. Ein Standortnetzwerkdienst (Site Network Service, SNS) bezieht sich auf eine einzelne NSDV. Dieses Design garantiert eine konsistente und wiederholbare Bereitstellung des Netzwerkdiensts an einem bestimmten Standort mit einem einzigen SNS PUT-Befehl.

Ein Beispiel für eine NSDG:

Authentifizierungsserverfunktion (AUSF): Netzwerkfunktion
Einheitliche Datenverwaltung (Unified Data Management, UDM): Netzwerkfunktion
Administrator-VM, die AUSF/UDM unterstützt
Unity Cloud (UC) Session Management Function (SMF): Netzwerkfunktion
NAKS-Cluster, für den AUSF, UDM und SMF bereitgestellt werden

Diese fünf Komponenten bilden eine einzelne NSDG. Eine einzelne NSDG kann mehrere NSDVs enthalten.

Häufige Anwendungsfälle, die ein Update der Neben- oder Hauptversion einer Netzwerkdienst-Entwurfsversion (NSDV) auslösen

Erstellung oder Löschung von CGSs
Änderungen an der ARM-Vorlage, die einer der bereitgestellten Netzwerkfunktionen zugeordnet ist
Änderungen in der Infrastruktur-ARM-Vorlage, z. B. AKS/NAKS oder VM

Hinweis

Änderungen an der NFDV sollten kein NSDV-Update auslösen. Der NFDV-Wert sollte als Parameter innerhalb im CGS verfügbar gemacht werden, sodass Operatoren steuern können, was mithilfe von CGVs bereitgestellt werden soll.

Überlegungen zum Konfigurationsgruppenschema (CGS)

Es wird empfohlen, immer mit einem einzigen CGS (Configuration Group Schema, Konfigurationsgruppenschema) für die gesamte Netzwerkfunktion zu beginnen. Wenn standort- oder instanzspezifische Parameter vorhanden sind, empfiehlt es sich außerdem, diese in ein einziges CGS einzuschließen. Eine Aufteilung in mehrere CGSs wird empfohlen, wenn mehrere Komponenten (selten Netzwerkfunktionen, häufiger die Infrastruktur) oder Konfigurationen vorhanden sind, die für mehrere Netzwerkfunktionen verwendet werden. Die Anzahl der CGSs definiert die Anzahl der CGVs.

Szenario

FluentD, Kibana und Splunk (gängige Drittanbieterkomponenten) werden immer für alle Netzwerkfunktionen innerhalb einer NSD bereitgestellt. Es wird empfohlen, diese Komponenten in einer einzelnen NFDG zusammenzufassen.
Die NSD enthält mehrere Netzwerkfunktionen, die alle einige Konfigurationen gemeinsam nutzen (Bereitstellungsort, Herausgebername und einige Chartkonfigurationen).

In diesem Szenario wird empfohlen, ein einzelnes globales CGS zu verwenden, um die gemeinsamen Konfigurationen für Netzwerkfunktionen und Drittanbieterkomponenten verfügbar zu machen. Sie können bei Bedarf ein für die Netzwerkfunktion spezifisches CGS definieren.

Auswählen von Parametern, die verfügbar gemacht werden sollen

Das CGS sollte nur Parameter enthalten, die von Netzwerkfunktionen (Tag 0/N-Konfiguration) oder freigegebenen Komponenten verwendet werden.
Für Parameter, die selten konfiguriert werden, sollten Standardwerte definiert werden.
Wenn mehrere CGSs verwendet werden, sollten Überlappungen zwischen den Parametern möglichst vermieden werden. Falls Überlappungen erforderlich sind, stellen Sie sicher, dass die Parameternamen zwischen den CGSs eindeutig unterschieden werden können.
Was über eine API (Azure Operator Nexus, Azure Operator Service Manager) definiert werden kann, sollte im CGS berücksichtigt werden. Im Gegensatz dazu, können Sie diese Konfigurationswerte z. B. über CloudInit-Dateien definieren.
Wenn Sie sich nicht sicher sind, besteht ein guter Ausgangspunkt darin, den Parameter verfügbar zu machen und im CGS einen geeigneten Standardwert anzugeben. Das folgende Beispiel zeigt ein Beispiel-CGS und die zugehörigen CGV-Nutzdaten.
Eine einzelne benutzerseitig zugewiesene verwaltete Identität sollte in allen ARM-Vorlagen für Netzwerkfunktionen verwendet und über das CGS verfügbar gemacht werden.

CGS-Nutzdaten:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

Zugehörige CGV-Nutzdaten, die vom Operator übergeben werden:

{
"qwe": 20
}

Resultierende CGV-Nutzdaten, die von Azure Operator Service Manager generiert werden:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Überlegungen zu Konfigurationsgruppenwerten (CGVs)

Bevor Sie die CGV-Ressourcenerstellung übermitteln, können Sie überprüfen, ob das Schema und die Werte der zugrunde liegenden YAML- oder JSON-Datei den Erwartungen des zugehörigen CGS entsprechen. Dafür können Sie die YAML-Erweiterung für Visual Studio Code verwenden.

Überlegungen zur Befehlszeilenschnittstelle (CLI)

Die CLI-Erweiterung von Azure Operator Service Manager unterstützt Sie bei der Veröffentlichung von NFDs und NSDs. Verwenden Sie dieses Tool als Ausgangspunkt zum Erstellen neuer NFDs und NSDs. Erwägen Sie die Verwendung der Befehlszeilenschnittstelle zum Erstellen der anfänglichen Dateien. Bearbeiten Sie diese dann, um vor der Veröffentlichung Infrastrukturkomponenten zu integrieren.

Überlegungen zum Standortnetzwerkdienst (SNS)

Es wird empfohlen, einen einzelnen SNS für den gesamten Standort zu nutzen, einschließlich der Infrastruktur. Der SNS sollte die gesamte erforderliche Infrastruktur bereitstellen (z. B. NAKS/AKS-Cluster und VMs), und dann zusätzlich die erforderlichen Netzwerkfunktionen bereitstellen. Dieses Design garantiert eine konsistente und wiederholbare Bereitstellung des Netzwerkdiensts an einem bestimmten Standort mit einem einzigen SNS PUT-Befehl.

Es wird empfohlen, jeden SNS mit einer benutzerseitig zugewiesenen verwalteten Identität und nicht mit einer systemseitig zugewiesenen verwalteten Identität bereitzustellen. Diese benutzerseitig zugewiesene verwaltete Identität muss über Berechtigungen für den Zugriff auf die NFDV und die Rolle „Operator für verwaltete Identität“ für sich selbst verfügen. Weitere Informationen finden Sie unter Erstellen und Zuweisen einer benutzerseitig zugewiesenen verwalteten Identität.

Ressourcenzuordnung durch Azure Operator Service Manager nach Anwendungsfall

Die folgenden beiden Szenarien veranschaulichen die Ressourcenzuordnung von Azure Operator Service Manager.

Szenario: Einzelne Netzwerkfunktion

Eine Netzwerkfunktion mit einer oder zwei Anwendungskomponenten wird in einem NAKS-Cluster bereitgestellt.

Ressourcenaufschlüsselung:

NFDG: Wenn Komponenten unabhängig verwendet werden können, zwei NFDGs – eine pro Komponente. Wenn Komponenten immer zusammen bereitgestellt werden, dann eine einzelne NFDG.
NFDV: Je nach Bedarf basierend auf den Anwendungsfällen, die in den vorherigen Abschnitten zu allgemeinen Anwendungsfällen genannt wurden und Updates der Neben- oder Hauptversion der NFDV auslösen.
NSDG: Einzeln. Kombiniert die Netzwerkfunktionen und die Kubernetes-Clusterdefinitionen.
NSDV: Je nach Bedarf basierend auf den Anwendungsfällen, die in den vorherigen Abschnitten zu allgemeinen Anwendungsfällen genannt wurden und Updates der Neben- oder Hauptversion der NSDV auslösen.
CGS: Einzeln. Es wird empfohlen, im CGS Unterabschnitte für jede bereitgestellte Komponente und Infrastruktur einzufügen, die auch die Versionen der NFDs enthalten, um die Verwaltung zu vereinfachen.
CGV: Einzeln basierend auf der Anzahl der CGSs.
SNS: Einzeln pro NSDV.

Szenario: Mehrere Netzwerkfunktionen

Mehrere Netzwerkfunktionen mit einigen freigegebenen und unabhängigen Komponenten werden in einem NAKS-Cluster bereitgestellt.

Ressourcenaufschlüsselung:

NFDG:
- NFDG für alle gemeinsam genutzten Komponenten.
- NFDG für jede unabhängige Komponente oder Netzwerkfunktion.
NFDV: Mehrere pro einzelner NFDG basierend auf den Anwendungsfällen, die in den vorherigen Abschnitten zu allgemeinen Anwendungsfällen genannt wurden und Updates der Neben- oder Hauptversion der NFDV auslösen.
NSDG: Einzeln. Kombiniert alle Netzwerkfunktionen, freigegebenen und unabhängigen Komponenten und die gesamte Infrastruktur (Kubernetes-Cluster oder alle unterstützenden VMs).
NSDV: Je nach Bedarf basierend auf den Anwendungsfällen, die in den vorherigen Abschnitten zu allgemeinen Anwendungsfällen genannt wurden und Updates der Neben- oder Hauptversion der NSDV auslösen.
CGS:
- Ledig. Global für alle Komponenten mit gemeinsam genutzten Konfigurationswerten.
- CGS pro Netzwerkfunktion, einschließlich der Version der NFD.
- Je nach Gesamtanzahl der Parameter sollten Sie alle CGSs in einem einzigen CGS kombinieren.
CGV: Gleich der Anzahl von CGSs.
SNS: Einzeln pro NSDV.

Überlegungen zu Softwareupgrades

Davon ausgehend, dass Netzwerkfunktionen direkte Dienstupgrades für CNFs unterstützen:

Wenn neue Charts und Bilder hinzugefügt werden, installiert Azure Operator Service Manager die neuen Charts.
Wenn einige Charts und Bilder entfernt werden, löscht Azure Operator Service Manager die Charts, die nicht mehr in der NFDV deklariert sind.
Azure Operator Service Manager überprüft, ob die NFDV/NSDV aus derselben NFDG/NSDG und damit vom selben Herausgeber stammt. Herausgeberübergreifende Upgrades werden nicht unterstützt.

Für VNFs:

Direkte Upgrades werden derzeit nicht unterstützt. Sie müssen eine neue VNF mit einem aktualisierten Bild nebeneinander instanziieren. Löschen Sie dann die ältere VNF, indem Sie den SNS löschen.
Wenn eine VNF für Hochverfügbarkeit als VM-Paar bereitgestellt wird, können Sie den Netzwerkdienst so entwerfen, dass Sie die VMs einzeln löschen und aktualisieren können. Der folgende Entwurf wird empfohlen, um das Löschen und Upgraden einzelner VMs zu ermöglichen:
- Jede VM wird mithilfe einer dedizierten ARM-Vorlage bereitgestellt.
- Aus der ARM-Vorlage müssen zwei Parameter über das CGS verfügbar gemacht werden: VM-Name, um anzugeben, welche Instanz primär bzw. sekundär ist, und Bereitstellungsrichtlinie, um zu steuern, ob die VM-Bereitstellung zulässig ist.
- In der NFDV müssen deployParameters und templateParameters so parametrisiert werden, dass Sie die eindeutigen Werte jeweils mithilfe von CGVs angeben können.

Überlegungen zu Hochverfügbarkeit und Notfallwiederherstellung

Azure Operator Service Manager ist ein regionaler Dienst, der über Verfügbarkeitszonen hinweg in Regionen bereitgestellt wird, die ihn unterstützen. Alle Regionen, in denen Azure Operator Service Manager verfügbar ist, finden Sie unter Azure-Produkte nach Region. Die Liste der Azure-Regionen mit Verfügbarkeitszonen finden Sie unter Auswählen der richtigen Azure-Region für Sie.

Berücksichtigen Sie die folgenden Anforderungen für Hochverfügbarkeit und Notfallwiederherstellung:

Um Georedundanz bereitzustellen, stellen Sie sicher, dass Sie in jeder Region, in der Sie Netzwerkfunktionen bereitstellen möchten, über einen Herausgeber verfügen. Erwägen Sie die Verwendung von Pipelines, um sicherzustellen, dass Herausgeberartefakte und -ressourcen regionenübergreifend synchronisiert werden.
Der Herausgebername muss für jede Kombination aus Region und Microsoft Entra-Mandant eindeutig sein.

Hinweis

Wenn eine Region nicht mehr verfügbar ist, können Sie eine Netzwerkfunktion mithilfe von Herausgeberressourcen in einer anderen Region bereitstellen (aber nicht aktualisieren). Falls die Artefakte und Ressourcen zwischen den Herausgebern identisch sind, müssen Sie nur den Wert von networkServiceDesignVersionOfferingLocation in den SNS-Ressourcennutzdaten ändern.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

Überlegungen zur Problembehandlung

Während Installation und Upgrade sind die atomischen und Warteoptionen standardmäßig auf true und das Timeout des Vorgangs auf 27 minutes festgelegt. Während des anfänglichen Onboardings sollten Sie das atomic-Flag nur während des Debuggens und Entwickelns von Artefakten auf false. festlegen. Dadurch wird ein Rollback bei Fehlern verhindert und alle Protokolle oder Fehler aufbewahrt, die andernfalls verloren gehen. Am besten können Sie dies in der ARM-Vorlage der Netzwerkfunktion festlegen.

Fügen Sie in der ARM-Vorlage den folgenden Abschnitt hinzu:

"roleOverrideValues": [
    "{\"name\":\"NF_component_name>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]

Der Komponentenname wird in der NFDV definiert:

     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'fed-crds'
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }

Wichtig

Stellen Sie sicher, dass „atomic“ und „wait“ auf true zurückgesetzt werden, nachdem das anfängliche Onboarding abgeschlossen ist.

Überlegungen zur Bereinigung

Löschen Sie Operatorressourcen in der folgenden Reihenfolge, um sicherzustellen, dass keine verwaisten Ressourcen zurückbleiben:

SNS
Website
CGV

Wichtig

Stellen Sie sicher, dass der SNS gelöscht wird, bevor Sie die NFDV löschen.

Löschen Sie Herausgeberressourcen in der folgenden Reihenfolge, um sicherzustellen, dass keine verwaisten Ressourcen zurückbleiben:

CGS
NSDV
NSDG
NFDV
NFDG
Artefaktmanifest
Artefaktspeicher
Herausgeber

Überlegungen, wenn Ihre Netzwerkfunktion cert-manager ausführt

Wichtig

Dieser Leitfaden gilt nur für bestimmte Versionen. Überprüfen Sie Ihre Version auf ordnungsgemäßes Verhalten.

Von Version 1.0.2728-50 bis zur Version 2.0.2777-132 verwendet AOSM den Zertifikat-Manager zum Speichern und Rotieren von Zertifikaten. Im Rahmen dieser Änderung stellt AOSM einen cert-manager-Operator bereit und ordnet CRDs im azurehybridnetwork-Namespace zu. Da mehrere cert-manager-Operatoren auch bei einer Bereitstellung in separaten Namespaces alle Namespaces überwachen, kann im Cluster nur ein cert-manager effektiv ausgeführt werden.

Benutzer, die versuchen, cert-manager als Teil einer Workloadbereitstellung im Cluster zu installieren, erhalten einen Bereitstellungsfehler, dass die CRD „vorhanden ist und nicht in das aktuelle Release importiert werden kann“. Um diesen Fehler zu vermeiden, empfiehlt es sich, die Installation von cert-manager zu überspringen und stattdessen die Abhängigkeiten von cert-manager-Operator und CRD zu nutzen, die bereits von AOSM installiert wurden.

Weitere wichtige Konfigurationsänderungen

Zusätzlich zur Deaktivierung der NfApp, die dem alten Benutzer-cert-manager zugeordnet war, sind möglicherweise weitere Änderungen nötig:

Wenn eine NfApp sowohl cert-manager als auch die CA-Installation enthält, müssen diese Features in zwei NfApps unterteilt sein, damit der Partner cert-manager deaktivieren und die Ca-Installation aktivieren kann.
Wenn andere NfApps über DependsOn-Verweise auf den alten Benutzer-cert-manager verweisen, müssen diese entfernt werden.
Wenn andere NfApps auf den alten Namespacewert des Benutzer-cert-manager verweisen, muss er in den neuen azurehybridnetwork-Namespacewert geändert werden.

Kompatibilität und Verwaltung der cert-manager-Version

Für den cert-manager-Operator lautet die aktuell bereitgestellte Version 1.14.5. Benutzer sollten die Kompatibilität mit dieser Version testen. Zukünftige Upgrades des cert-manager-Operators werden über den Upgradeprozess der NFO-Erweiterung unterstützt.

Für die CRD-Ressourcen lautet die aktuell bereitgestellte Version 1.14.5. Benutzer sollten die Kompatibilität mit dieser Version testen. Da die Verwaltung einer gemeinsamen Cluster-CRD in der Regel von einem Clusteradministrator durchgeführt wird, arbeiten wir daran, CRD-Ressourcenupgrades über den Standardprozess des Nexus-Add-Ons zu ermöglichen.

NfApp: Sequenzielles Sortierverhalten

Übersicht

Standardmäßig werden containerisierte Netzwerkfunktionsanwendungen (NfApps) basierend auf der sequenziellen Reihenfolge installiert oder aktualisiert, in der sie in der Netzwerkfunktions-Entwurfsversion (Network Function Design Version, NFDV) angezeigt werden. Die Löschung von NfApps erfolgt in umgekehrter Reihenfolge. Wenn ein Herausgeber eine bestimmte Reihenfolge von NfApps definieren muss, die sich von der Standardsortierung unterscheidet, wird mit dependsOnProfile eine eindeutige Sequenz für Installations-, Aktualisierungs- und Löschvorgänge definiert.

Verwenden von dependsOnProfile

Herausgeber können mit dependsOnProfile in der NFDV die Reihenfolge von Helm-Ausführungen für NfApps steuern. Im folgenden Beispiel wird der Installationsvorgang von NfApps in der folgenden Reihenfolge bereitgestellt: dummyApplication1, dummyApplication2, dann dummyApplication. Der Updatevorgang der NfApps wird in der folgenden Reihenfolge durchgeführt: dummyApplication2, dummyApplication1, dann dummyApplication. Die Löschung der NfApps erfolgt in der folgenden Reihenfolge: dummyApplication2, dummyApplication1, dann dummyApplication.

{
    "location": "eastus",
    "properties": {
        "networkFunctionTemplate": {
            "networkFunctionApplications": [
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                            "dummyApplication1",
                            "dummyApplication2"
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication1"
                        ],
                        "updateDependsOn": [
                            "dummyApplication1"
                        ]
                    },
                    "name": "dummyApplication"
                },
                {
                  "dependsOnProfile": {
                        "installDependsOn": [
                        ],
                        "uninstallDependsOn": [
                            "dummyApplication2"
                        ],
                        "updateDependsOn": [
                            "dummyApplication2"
                        ]
                    },
                    "name": "dummyApplication1"
                },
                {
                    "dependsOnProfile": null,
                    "name": "dummyApplication2"
                }
            ],
            "nfviType": "AzureArcKubernetes"
        },
        "networkFunctionType": "ContainerizedNetworkFunction"
    }
}

Häufige Fehler

Falls derzeit dependsOnProfile in der NFDV ungültig ist, löst der Netzwerkfunktionsvorgang einen Überprüfungsfehler aus. Die Überprüfungsfehlermeldung wird in der Vorgangsstatusressource angezeigt und ähnelt folgendem Beispiel.

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
  "status": "Failed",
  "startTime": "2023-07-17T20:48:01.4792943Z",
  "endTime": "2023-07-17T20:48:10.0191285Z",
  "error": {
    "code": "DependenciesValidationFailed",
    "message": "CyclicDependencies: Circular dependencies detected at hellotest."
  }
}

Teilen über

Bewährte Methoden für Azure Operator Service Manager zum Onboarden und Bereitstellen von Netzwerkfunktionen

Allgemeine Hinweise

Überlegungen zum Herausgeber

Überlegungen zu Netzwerkfunktions-Definitionsgruppe und -version (NFDG/NFDV)

Häufige Anwendungsfälle, die ein Update der Neben- oder Hauptversion einer Netzwerkfunktions-Entwurfsversion (NFDV) auslösen

Überlegungen zu Netzwerkdienst-Entwurfsgruppe und -version (NSDG/NSDV)

Häufige Anwendungsfälle, die ein Update der Neben- oder Hauptversion einer Netzwerkdienst-Entwurfsversion (NSDV) auslösen

Überlegungen zum Konfigurationsgruppenschema (CGS)

Szenario

Auswählen von Parametern, die verfügbar gemacht werden sollen

Überlegungen zu Konfigurationsgruppenwerten (CGVs)

Überlegungen zur Befehlszeilenschnittstelle (CLI)

Überlegungen zum Standortnetzwerkdienst (SNS)

Ressourcenzuordnung durch Azure Operator Service Manager nach Anwendungsfall

Szenario: Einzelne Netzwerkfunktion

Szenario: Mehrere Netzwerkfunktionen

Überlegungen zu Softwareupgrades

Überlegungen zu Hochverfügbarkeit und Notfallwiederherstellung

Überlegungen zur Problembehandlung

Überlegungen zur Bereinigung

Überlegungen, wenn Ihre Netzwerkfunktion cert-manager ausführt

Weitere wichtige Konfigurationsänderungen

Kompatibilität und Verwaltung der cert-manager-Version

NfApp: Sequenzielles Sortierverhalten

Übersicht

Verwenden von dependsOnProfile

Häufige Fehler

Feedback

Zusätzliche Ressourcen