Najlepsze rozwiązania dotyczące dołączania i wdrażania funkcji sieciowych za pomocą programu Azure Operator Service Manager

Firma Microsoft opracowała wiele sprawdzonych rozwiązań dotyczących zarządzania funkcjami sieciowymi przy użyciu programu Azure Operator Service Manager. Ten artykuł zawiera wytyczne, które dostawcy NF, operatorzy telco i ich partnerzy mogą stosować w celu optymalizacji projektu. Pamiętaj o tych rozwiązaniach podczas dołączania i wdrażania NFs.

Zagadnienia ogólne

Zalecamy, aby najpierw dołączyć i wdrożyć najprostsze NFs (jeden lub dwa wykresy), korzystając z przewodników Szybki start, aby zapoznać się z ogólnym przepływem. Niezbędne szczegóły konfiguracji można dodać w kolejnych iteracji. Podczas pracy z przewodnikami Szybki start weź pod uwagę następujące kwestie:

• Utwórz strukturę artefaktów w celu dostosowania ich do planowanego użycia. Rozważ oddzielenie artefaktów globalnych od artefaktów, które chcesz różnić w zależności od lokacji lub wystąpienia.
• Upewnij się, że skład usługi wielu NFs z zestawem parametrów odpowiadających potrzebom sieci. Możesz na przykład mieć wykres zawierający 1000 wartości i dostosować tylko 100 z nich. Upewnij się, że w warstwie Schemat grupy konfiguracji (CGS) (omówionej bardziej szczegółowo w kolejnych sekcjach), które uwidaczniasz tylko 100.
• Na początku zastanów się, jak chcesz oddzielić infrastrukturę (na przykład klastry) lub magazyny artefaktów oraz dostęp między dostawcami, w szczególności w ramach jednej usługi. Ustaw zestaw zasobów wydawcy na ten model.
• Lokacja menedżera usług operatora platformy Azure to logiczne pojęcie, reprezentacja miejsca docelowego wdrożenia. Przykłady to klaster Kubernetes dla konteneryzowanych funkcji sieciowych (CNFs) lub rozszerzonej lokalizacji niestandardowej operatora platformy Azure dla funkcji sieci zwirtualizowanej (VNFs). Nie jest to reprezentacja fizycznej lokacji brzegowej, dlatego istnieją przypadki użycia, w których wiele lokacji ma tę samą lokalizację fizyczną.
• Program Azure Operator Service Manager udostępnia różne interfejsy API, dzięki czemu można łatwo łączyć się z narzędziami ADO lub innymi narzędziami potoku.

Zagadnienia dotyczące wydawcy

• Zalecamy utworzenie jednego wydawcy dla dostawcy NF. Ta praktyka zapewnia optymalną obsługę, konserwację i ład we wszystkich dostawcach oraz upraszcza projektowanie usług sieciowych, jeśli składa się z wielu NFs od wielu dostawców.

• Po przetestowaniu i zatwierdzeniu żądanego zestawu zasobów i artefaktów wydawcy programu Azure Operator Service Manager do użytku produkcyjnego zalecamy oznaczenie całego zestawu jako niezmiennego, aby zapobiec przypadkowym zmianom i zapewnić spójne środowisko wdrażania. Rozważ poleganie na możliwościach niezmienności, aby odróżnić zasoby i artefakty używane w środowisku produkcyjnym w porównaniu z tymi używanymi do celów testowania i programowania. Możesz wykonać zapytanie dotyczące stanu zasobów wydawcy i manifestów artefaktów, aby określić, które z nich są oznaczone jako niezmienne. Aby uzyskać więcej informacji, zobacz Dzierżawy wydawcy, subskrypcje, regiony i zarządzanie w wersji zapoznawczej.

  Pamiętaj o następującej logice:

  • Jeśli wersja projektu usługi sieciowej (NSDV) jest oznaczona jako niezmienna, usługa CGS również musi być oznaczona jako niezmienna. W przeciwnym razie wywołanie wdrożenia kończy się niepowodzeniem.
  • Jeśli wersja projektu funkcji sieciowej (NFDV) jest oznaczona jako niezmienna, manifest artefaktu musi być również oznaczony jako niezmienny. W przeciwnym razie wywołanie wdrożenia kończy się niepowodzeniem.
  • Jeśli tylko manifest artefaktu lub usługa CGS jest oznaczona jako niezmienne, wywołanie wdrożenia powiedzie się niezależnie od tego, czy NFDV i NSDV są oznaczone jako niezmienne.
  • Oznaczanie manifestu artefaktu jako niezmiennego zapewnia, że wszystkie artefakty wymienione w tym manifeście (zazwyczaj wykresy, obrazy i szablony usługi Azure Resource Manager [szablony usługi ARM]) są oznaczone jako niezmienne, wymuszając niezbędne uprawnienia do magazynu artefaktów.

• Rozważ użycie uzgodnionych konwencji nazewnictwa i technik zapewniania ładu, aby pomóc w rozwiązaniu wszelkich pozostałych luk.

Zagadnienia dotyczące grupy definicji funkcji sieci i wersji

Network Function Definition Group (NFDG) reprezentuje najmniejszy składnik, który ma być używany niezależnie w wielu usługach. Wszystkie części grupy NFDG są zawsze wdrażane razem. Te części są nazywane .networkFunctionApplications Na przykład naturalne jest dołączanie pojedynczego systemu plików NF składającego się z wielu wykresów i obrazów programu Helm jako pojedynczej grupy plików NFDG, jeśli zawsze wdrażasz te składniki razem. W przypadkach, gdy wiele NFs są zawsze wdrażane razem, uzasadnione jest posiadanie pojedynczej grupy plików NFDG dla wszystkich z nich. Pojedyncze grupy plików NFDG mogą mieć wiele NFDVs.

W przypadku konteneryzowanych wersji definicji funkcji sieciowych (CNF NFDVs) networkFunctionApplications lista może zawierać tylko pakiety helm. Warto uwzględnić wiele pakietów helm, jeśli są one zawsze wdrażane i usuwane razem.

W przypadku zwirtualizowanych wersji definicji funkcji sieci (VNF NFDVs) networkFunctionApplications lista musi zawierać co najmniej jeden VhdImageFile i jeden szablon usługi ARM. Szablon usługi ARM powinien wdrożyć jedną maszynę wirtualną. Aby wdrożyć wiele maszyn wirtualnych dla pojedynczego systemu plików VNF, należy użyć oddzielnych szablonów usługi ARM dla każdej maszyny wirtualnej.

Szablon usługi ARM może wdrażać tylko zasoby usługi Resource Manager od następujących dostawców zasobów:

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

Uwaga

W przypadku szablonów usługi ARM zawierających wszystkie elementy poza poprzednią listą wszystkie wywołania PUT i Funkcja Re-PUT w systemie plików VNF powodują błąd weryfikacji.

Typowe przypadki użycia wyzwalające aktualizację wersji pomocniczej lub głównej wersji projektu funkcji sieciowej

• Aktualizowanie wartości grupy CGS/konfiguracji (CGV) dla istniejącej wersji, która wyzwala zmianę .deployParametersMappingRuleProfile
• Aktualizowanie wartości zakodowanych w systemie plików NFDV.
• Oznaczanie składników nieaktywnych, aby uniemożliwić ich wdrażanie za pośrednictwem programu applicationEnablement: Disabled.
• Nowa wersja NF, taka jak wykresy i obrazy.

Uwaga

Minimalna liczba zmian wymaganych za każdym razem, gdy ładunek danego systemu plików NF zmienia się. Wersja pomocnicza lub główna NF bez uwidaczniania nowych parametrów usługi CGS wymaga tylko aktualizacji manifestu artefaktu, wypychania nowych obrazów i wykresów oraz podbijania wersji NFDV.

Zagadnienia dotyczące grupy projektowej i wersji usług sieciowych

Network Service Design Group (NSDG) jest złożonym z co najmniej jednego systemu plików NFDG i wszystkich składników infrastruktury (takich jak Nexus Azure Kubernetes Service [NAKS]/Azure Kubernetes Service [AKS] klastry i maszyny wirtualne) wdrożone w tym samym czasie. Usługa sieci lokacji (SNS) odnosi się do pojedynczego wirtualnego wirtualnego typu NSDV. Taki projekt gwarantuje spójne i powtarzalne wdrożenie usługi sieciowej w danej lokacji z pojedynczego polecenia SNS PUT.

Przykładem sieciowej grupy zabezpieczeń jest:

• NF funkcji serwera uwierzytelniania (AUSF)
• Ujednolicona Zarządzanie danymi (UDM) NF
• Maszyna wirtualna administratora obsługująca usługę AUSF/UDM
• Unity Cloud (UC) Session Management, funkcja (SMF) NF
• Klaster NAKS, do którego wdrażane są usługi AUSF, UDM i SMF

Te pięć składników stanowi pojedynczą sieciową grupę zabezpieczeń. Jedna sieciowa grupa zabezpieczeń może mieć wiele NSDV.

Typowe przypadki użycia wyzwalające aktualizację wersji pomocniczej lub wersji głównej wersji projektu usługi sieciowej

• Tworzenie lub usuwanie zestawów CGS.
• Zmiany w szablonie usługi ARM systemu plików NF skojarzonych z jednym z wdrażanych plików NFs.
• Zmiany w szablonie infrastruktury usługi ARM, na przykład AKS/NAKS lub maszyny wirtualnej.

Uwaga

Zmiany w systemie plików NFDV nie powinny wyzwalać aktualizacji NSDV. Wartość NFDV powinna być uwidoczniona jako parametr w usłudze CGS, aby operatorzy mogli kontrolować, co należy wdrożyć za pomocą CGV.

Zagadnienia dotyczące schematu grupy konfiguracji

Zalecamy, aby zawsze zaczynać się od jednej usługi konfiguracji dla całego systemu plików NF. Jeśli istnieją parametry specyficzne dla lokacji lub wystąpienia, nadal zalecamy ich przechowywanie w jednej usłudze CGS. Zalecamy podzielenie na wiele pakietów CGS, gdy istnieje wiele składników (rzadko NFs, częściej, infrastruktury) lub konfiguracji, które są współużytkowane przez wiele NFs. Liczba zestawów CGS definiuje liczbę CGV.

Scenariusz

• FluentD, Kibana i Splunk (typowe składniki innych firm) są zawsze wdrażane dla wszystkich NFs w NSD. Zalecamy grupowanie tych składników w pojedynczą grupę plików NFDG.
• NSD ma wiele NFS, które współużytkuje kilka konfiguracji (lokalizacja wdrożenia, nazwa wydawcy i kilka konfiguracji wykresu).

W tym scenariuszu zalecamy użycie pojedynczej globalnej grupy zabezpieczeń w celu uwidocznienia typowych konfiguracji składników NF i innych firm. W razie potrzeby można zdefiniować usługę CGS specyficzną dla systemu plików NF.

Wybieranie parametrów do uwidocznienia

• Usługa CGS powinna mieć tylko parametry, które są używane przez NFs (konfiguracja dnia 0/N) lub składniki udostępnione.
• Parametry rzadko konfigurowane powinny mieć zdefiniowane wartości domyślne.
• Jeśli jest używanych wiele zestawów CGS, zalecamy niewielkie nakładanie się między parametrami. Jeśli wymagane jest nakładanie się, upewnij się, że nazwy parametrów są wyraźnie rozróżnialne między zestawami CGS.
• To, co można zdefiniować za pośrednictwem interfejsu API (Azure Operator Nexus, Azure Operator Service Manager) należy wziąć pod uwagę w przypadku usługi CGS. W przeciwieństwie do definiowania tych wartości konfiguracji za pośrednictwem plików CloudInit.
• Jeśli nie masz pewności, dobrym punktem wyjścia jest uwidocznienie parametru i posiadanie rozsądnej wartości domyślnej określonej w usłudze CGS. W poniższym przykładzie przedstawiono przykładową usługę CGS i odpowiadające im ładunki CGV.
• Jedna tożsamość zarządzana przypisana przez użytkownika powinna być używana we wszystkich szablonach usługi ARM NF i powinna być uwidoczniona za pośrednictwem usługi CGS.

Ładunek CGS:

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

Odpowiadający ładunek CGV przekazany przez operatora:

{
"qwe": 20
}

Wynikowy ładunek CGV wygenerowany przez program Azure Operator Service Manager:

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

Zagadnienia dotyczące wartości grupy konfiguracji

Przed przesłaniem utworzenia zasobu CGV można sprawdzić, czy schemat i wartości bazowego pliku YAML lub JSON są zgodne z oczekiwanymi odpowiednimi usługami CGS. W tym celu jedną z opcji jest użycie rozszerzenia YAML dla programu Visual Studio Code.

Zagadnienia dotyczące interfejsu wiersza polecenia

Rozszerzenie interfejsu wiersza polecenia programu Azure Operator Service Manager pomaga w publikowaniu identyfikatorów NFD i NSD. Użyj tego narzędzia jako punktu wyjścia do tworzenia nowych identyfikatorów NFD i NSD. Rozważ użycie interfejsu wiersza polecenia do utworzenia plików początkowych. Następnie zmodyfikuj je, aby uwzględnić składniki infrastruktury przed opublikowaniem.

Zagadnienia dotyczące usługi sieci lokacji

Zalecamy posiadanie pojedynczego snsa dla całej lokacji, w tym infrastruktury. Usługa SNS powinna wdrożyć dowolną wymaganą infrastrukturę (na przykład klastry NAKS/AKS i maszyny wirtualne), a następnie wdrożyć wymagane sieciowe elementy sieciowe. Taki projekt gwarantuje spójne i powtarzalne wdrożenie usługi sieciowej w danej lokacji z pojedynczego polecenia SNS PUT.

Zalecamy wdrożenie każdego sns z tożsamością zarządzaną przypisaną przez użytkownika, a nie tożsamością zarządzaną przypisaną przez system. Ta tożsamość zarządzana przypisana przez użytkownika musi mieć uprawnienia dostępu do systemu plików NFDV i musi mieć rolę operatora tożsamości zarządzanej. Aby uzyskać więcej informacji, zobacz Tworzenie i przypisywanie tożsamości zarządzanej przypisanej przez użytkownika.

Mapowanie zasobów programu Azure Operator Service Manager na przypadek użycia

W poniższych dwóch scenariuszach przedstawiono mapowanie zasobów programu Azure Operator Service Manager.

Scenariusz: Pojedyncza funkcja sieciowa

System plików NF z jednym lub dwoma składnikami aplikacji jest wdrażany w klastrze NAKS.

Podział zasobów:

• NFDG: Jeśli składniki mogą być używane niezależnie, dwa NFDGs, jeden na składnik. Jeśli składniki są zawsze wdrażane razem, wówczas pojedyncza grupa plików NFDG.
• NFDV: zgodnie z potrzebami na podstawie przypadków użycia wymienionych w poprzednich sekcjach "Typowe przypadki użycia", które wyzwalają aktualizacje wersji pomocniczej lub głównej systemu plików NFDV.
• Sieciowa grupa zabezpieczeń: pojedyncza. Łączy definicje NFs i klastra Kubernetes.
• NSDV: zgodnie z potrzebami na podstawie przypadków użycia wymienionych w poprzednich sekcjach "Typowe przypadki użycia", które wyzwalają aktualizacje wersji pomocniczej lub głównej NSDV.
• CGS: pojedynczy. Zalecamy, aby usługa CGS zawierała podsekcje dla każdego składnika i infrastruktury wdrażanej w celu łatwiejszego zarządzania oraz zawiera wersje NFD.
• CGV: Pojedynczy na podstawie liczby CGSs.
• SNS: pojedyncza na NSDV.

Scenariusz: wiele funkcji sieciowych

Wiele NFs z niektórymi udostępnionymi i niezależnymi składnikami są wdrażane w klastrze NAKS.

Podział zasobów:

• NFDG:
  • NFDG dla wszystkich składników udostępnionych.
  • NFDG dla każdego niezależnego składnika lub NF.
• NFDV: wiele na każdy przypadek użycia systemu plików NFDG wymienionych w poprzednich sekcjach "Typowe przypadki użycia", które wyzwalają aktualizacje wersji pomocniczej lub głównej systemu plików NFDV.
• Sieciowa grupa zabezpieczeń: pojedyncza. Łączy wszystkie sieciowe, współużytkowane i niezależne składniki oraz infrastrukturę (klaster Kubernetes lub wszystkie pomocnicze maszyny wirtualne).
• NSDV: zgodnie z potrzebami na podstawie przypadków użycia wymienionych w poprzednich sekcjach "Typowe przypadki użycia", które wyzwalają aktualizacje wersji pomocniczej lub głównej NSDV.
• CGS:
  • Niebędący/niebędąca w związku. Globalne dla wszystkich składników, które mają współużytkowane wartości konfiguracji.
  • NF CGS na NF, w tym wersję NFD.
  • W zależności od łącznej liczby parametrów rozważ połączenie wszystkich zestawów CGS w jedną grupę CGS.
• CGV: Równa się liczbie CGSs.
• SNS: pojedyncza na NSDV.

Zagadnienia dotyczące uaktualniania oprogramowania

Przy założeniu, że funkcje NFs obsługują uaktualnienia w miejscu/w usłudze, w przypadku plików CNFs:

• Jeśli zostaną dodane nowe wykresy i obrazy, program Azure Operator Service Manager zainstaluje nowe wykresy.
• Jeśli niektóre wykresy i obrazy zostaną usunięte, program Azure Operator Service Manager usunie wykresy, które nie są już deklarowane w systemie plików NFDV.
• Menedżer usług operatora platformy Azure sprawdza, czy NFDV/NSDV pochodzi z tej samej grupy NFDG/sieciowej grupy zabezpieczeń, a tym samym wydawcy. Uaktualnienia między wydawcami nie są obsługiwane.

W przypadku plików VNFs:

• Uaktualnienia w miejscu nie są obecnie obsługiwane. Należy utworzyć wystąpienie nowego systemu plików VNF ze zaktualizowanym obrazem obok siebie. Następnie usuń starszy serwer VNF, usuwając sns.
• Jeśli system plików VNF jest wdrażany jako para maszyn wirtualnych w celu zapewnienia wysokiej dostępności, możesz zaprojektować usługę sieciową w taki sposób, aby można było usunąć i uaktualnić maszyny wirtualne pojedynczo. Zalecamy następujący projekt, aby umożliwić usunięcie i uaktualnienie poszczególnych maszyn wirtualnych:
  • Każda maszyna wirtualna jest wdrażana przy użyciu dedykowanego szablonu usługi ARM.
  • Z szablonu usługi ARM należy uwidocznić dwa parametry za pośrednictwem usługi CGS: nazwa maszyny wirtualnej, aby umożliwić wskazanie, które wystąpienie jest podstawowe/pomocnicze, oraz zasady wdrażania, kontrolując, czy wdrożenie maszyny wirtualnej jest dozwolone, czy nie.
  • W systemie plików NFDV i templateParameters należy je parametryzować w taki sposób, deployParameters aby można było podać unikatowe wartości przy użyciu zestawów CGV dla każdego z nich.

Zagadnienia dotyczące wysokiej dostępności i odzyskiwania po awarii

Azure Operator Service Manager to usługa regionalna wdrożona w różnych strefach dostępności w regionach, które je obsługują. Aby uzyskać informacje o wszystkich regionach, w których jest dostępny program Azure Operator Service Manager, zobacz Produkty platformy Azure według regionów. Aby uzyskać listę regionów świadczenia usługi Azure, w których znajdują się strefy dostępności, zobacz Wybieranie odpowiedniego regionu świadczenia usługi Azure.

Weź pod uwagę następujące wymagania dotyczące wysokiej dostępności i odzyskiwania po awarii:

• Aby zapewnić nadmiarowość geograficzną, upewnij się, że masz wydawcę w każdym regionie, w którym planujesz wdrożyć sieciowe elementy sieciowe. Rozważ użycie potoków, aby upewnić się, że artefakty wydawcy i zasoby są synchronizowane w różnych regionach.
• Nazwa wydawcy musi być unikatowa dla każdego regionu dla dzierżawy firmy Microsoft Entra.

Uwaga

Jeśli region stanie się niedostępny, możesz wdrożyć (ale nie uaktualnić) NF przy użyciu zasobów wydawcy w innym regionie. Zakładając, że artefakty i zasoby są identyczne między wydawcami, wystarczy zmienić networkServiceDesignVersionOfferingLocation wartość ładunku zasobu SNS.

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

Uwagi dotyczące rozwiązywania problemów

Podczas instalacji i uaktualniania domyślnie opcje niepodzielne i oczekiwania są ustawione na true, a limit czasu operacji jest ustawiony na 27 minuteswartość . Podczas początkowego dołączania zaleca się ustawienie flagi niepodzielnej tylko podczas debugowania i opracowywania artefaktów. W przeciwnym razie zalecamy ustawienie flagi false. niepodzielnej. Zapobiega to wycofywaniu narzędzia Helm po awarii i zachowuje wszelkie dzienniki lub błędy, które w przeciwnym razie mogą zostać utracone. Optymalny sposób osiągnięcia tego celu znajduje się w szablonie usługi ARM systemu plików NF.

W szablonie usługi ARM dodaj następującą sekcję:

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

Nazwa składnika jest zdefiniowana w systemie plików NFDV:

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

Ważne

Upewnij się, że niepodzielne i oczekujące są ustawione z powrotem na true po zakończeniu początkowego dołączania.

Zagadnienia dotyczące oczyszczania

Usuń zasoby operatora w następującej kolejności, aby upewnić się, że żadne zasoby oddzielone nie są pozostawione w tyle:

• SNS
• Witryna
• CGV

Ważne

Przed usunięciem systemu plików NFDV upewnij się, że protokół SNS został usunięty.

Usuń zasoby wydawcy w następującej kolejności, aby upewnić się, że żadne zasoby oddzielone nie są pozostawione w tyle:

• CGS
• NSDV
• Sieciowa grupa zabezpieczeń
• NFDV
• NFDG
• Manifest artefaktu
• Magazyn artefaktów
• Publisher

Zagadnienia dotyczące uruchamiania menedżera certyfikatów przez system plików NF

Ważne

Te wskazówki dotyczą tylko niektórych wersji. Sprawdź wersję pod kątem odpowiedniego zachowania.

Od wersji 1.0.2728-50 do wydania wersji 2.0.2777-132 usługa AOSM używa menedżera certyfikatów do przechowywania i rotacji certyfikatów. W ramach tej zmiany usługa AOSM wdraża operator cert-manager i kojarzy elementy CRD w przestrzeni nazw azurehybridnetwork. Ponieważ posiadanie wielu operatorów menedżera certyfikatów, nawet wdrożonych w oddzielnych przestrzeniach nazw, będzie obserwowane we wszystkich przestrzeniach nazw, w klastrze można skutecznie uruchomić tylko jeden menedżer certyfikatów.

Każdy użytkownik próbujący zainstalować menedżera certyfikatów w klastrze w ramach wdrożenia obciążenia otrzyma błąd wdrożenia z powodu błędu, że crD "istnieje i nie można go zaimportować do bieżącej wersji". Aby uniknąć tego błędu, zaleca się pominięcie instalowania menedżera certyfikatów, zamiast tego podjąć zależność od operatora cert-manager i CRD już zainstalowanego przez usługę AOSM.

Inne zmiany konfiguracji do rozważenia

Oprócz wyłączenia aplikacji NfApp skojarzonej ze starym menedżerem certyfikatów użytkownika, mogą być potrzebne inne zmiany;

1. Jeśli jedna aplikacja NfApp zawiera zarówno menedżera certyfikatów, jak i instalację urzędu certyfikacji, muszą one zostać podzielone na dwa aplikacje NfApps, aby partner mógł wyłączyć menedżera certyfikatów, ale włączyć instalację urzędu certyfikacji.
2. Jeśli jakiekolwiek inne NfApps mają odwołania DependsOn do starego użytkownika cert-manager NfApp, należy je usunąć.
3. Jeśli jakakolwiek inna aplikacja NfApps odwołuje się do starej wartości przestrzeni nazw cert-manager użytkownika, należy zmienić tę wartość na nową wartość przestrzeni nazw azurehybridnetwork.

Zgodność wersji programu Cert-Manager i zarządzanie

W przypadku operatora cert-manager bieżąca wdrożona wersja to 1.14.5. Użytkownicy powinni przetestować zgodność z tą wersją. Przyszłe uaktualnienia operatora cert-manager będą obsługiwane za pośrednictwem procesu uaktualniania rozszerzenia NFO.

W przypadku zasobów CRD bieżąca wdrożona wersja to 1.14.5. Użytkownicy powinni przetestować zgodność z tą wersją. Ponieważ zarządzanie typowym klastrem CRD jest zwykle obsługiwane przez administratora klastra, pracujemy nad włączeniem uaktualnień zasobów CRD za pośrednictwem standardowego procesu dodatku Nexus.

Zachowanie sekwencyjne porządkowania aplikacji NfApp

Omówienie

Domyślnie konteneryzowane aplikacje funkcji sieciowych (NfApps) są instalowane lub aktualizowane na podstawie kolejności sekwencyjnej, w której są wyświetlane w wersji projektowej funkcji sieciowej (NFDV). W przypadku usunięcia aplikacje NfApps są usuwane w kolejności odwrotnej. Jeśli wydawca musi zdefiniować konkretną kolejność aplikacji NfApps, różni się od domyślnej, element dependsOnProfile służy do definiowania unikatowej sekwencji operacji instalacji, aktualizacji i usuwania.

Jak używać metody dependsOnProfile

Wydawca może użyć właściwości dependsOnProfile w systemie plików NFDV, aby kontrolować sekwencję wykonań helm dla aplikacji NfApps. Biorąc pod uwagę poniższy przykład, podczas operacji instalacji aplikacja NfApps zostanie wdrożona w następującej kolejności: dummyApplication1, dummyApplication2, a następnie fikcyjnaApplication. Podczas operacji aktualizacji aplikacja NfApps zostanie zaktualizowana w następującej kolejności: dummyApplication2, dummyApplication1, a następnie fikcyjnaApplication. Podczas operacji usuwania aplikacja NfApps zostanie usunięta w następującej kolejności: dummyApplication2, dummyApplication1, a następnie fikcyjnaApplication.

{
    "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"
    }
}

Typowe błędy

Od dzisiaj, jeśli dependsOnProfile podany w systemie plików NFDV jest nieprawidłowy, operacja NF zakończy się niepowodzeniem z powodu błędu weryfikacji. Komunikat o błędzie weryfikacji jest wyświetlany w zasobie stanu operacji i wygląda podobnie do poniższego przykładu.

 {
  "id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
  "resourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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."
  }
}