Udostępnij za pośrednictwem

Użyj parametrów opcji programu Helm, aby zapobiec usunięciu po niepowodzeniu instalacji

  • Artykuł

Wdrożenia usługi sieci lokacji (SNS) mogą zakończyć się niepowodzeniem, ponieważ podstawowe wdrożenie funkcji sieciowej (NF) kończy się niepowodzeniem z instalacją programu Helm. Program Azure Operator Service Manager (AOSM) domyślnie usuwa nieudane wdrożenia z docelowego klastra Kubernetes w celu zachowania zasobów. Helm install błędy często wymagają, aby zasoby trwały w klastrze, aby umożliwić debugowanie awarii. W tym artykule z instrukcjami opisano sposób edytowania szablonu arm NF w celu zastąpienia tego zachowania przez ustawienie parametru helm install --atomic na false.

Wymagania wstępne

  • Musisz dołączyć system plików NF do usługi AOSM przy użyciu rozszerzenia AOSM interfejsu wiersza polecenia Az. W tym artykule odwołuje się do struktury folderów i plików wyjściowych interfejsu wiersza polecenia i przedstawiono przykłady oparte na interfejsie wiersza polecenia
  • Błędy instalacji programu Helm mogą być złożone. Debugowanie wymaga wiedzy technicznej na temat kilku technologii oprócz znajomości domeny systemu plików NF
  • Wymagane Contributor są przypisania ról w grupie zasobów zawierającej zarządzany magazyn artefaktów usługi AOSM
  • Odpowiednie środowisko IDE, takie jak Visual Studio Code
  • Interfejs wiersza polecenia USŁUGI ORAS

Ważne

Zdecydowanie zaleca się przetestowanie, czy helm install pakiet Helm powiedzie się w docelowym środowisku Kubernetes połączonym z usługą Arc przed podjęciem próby wdrożenia przy użyciu rozwiązania AOSM.

Zastępowanie --atomic pojedynczego wykresu helm NF

W tej sekcji wyjaśniono, jak zastąpić --atomic NF, który składa się z pojedynczego wykresu helm.

Lokalizowanie i edytowanie szablonu BICEP systemu plików NF

  1. Przejdź do nsd-cli-output katalogu, otwórz artifacts katalog i otwórz <nf-arm-template>.bicep plik. <nf-arm-template> jest skonfigurowany w pliku wejściowym NSD rozszerzenia interfejsu wiersza polecenia az AOSM. Możesz potwierdzić, że masz odpowiedni plik, porównując się z poniższym przykładowym szablonem fikcyjnej funkcji sieciowej konteneryzowanej firmy Contoso (CNF).

    @secure()
param configObject object

var resourceGroupId = resourceGroup().id

var identityObject = (configObject.managedIdentityId == '')  ? {
  type: 'SystemAssigned'
} : {
  type: 'UserAssigned'
  userAssignedIdentities: {
    '${configObject.managedIdentityId}': {}
  }
}

var nfdvSymbolicName = '${configObject.publisherName}/${configObject.nfdgName}/${configObject.nfdv}'

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' existing = {
  name: nfdvSymbolicName
  scope: resourceGroup(configObject.publisherResourceGroup)
}

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
  }
}]

  2. Znajdź nazwę aplikacji funkcji sieciowej, przechodząc do cnf-cli-output katalogu, otwierając nfDefinition katalog i kopiując wartość z jedynego wpisu w tablicy networkFunctionApplications w zasobie nfdv . Upewnij się, że masz poprawną wartość, porównując z następującym fikcyjnym fragmentem kodu BICEP firmy Contoso. W takim przypadku nazwa aplikacji funkcji sieciowej to Contoso.

    resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso'

  3. Edytuj szablon, aby zastąpić domyślną opcję instalacji --atomic narzędzia Helm, dodając następującą konfigurację do nfResource właściwości w szablonie usługi ARM NF:

    roleOverrideValues: ['{"name": "Contoso-one", "deployParametersMappingRuleProfile": {"applicationEnablement": "Enabled", "helmMappingRuleProfile": {"options": {"installOptions": {"atomic": "false"}},{"upgradeOptions": {"atomic": "false"}}}}}']

  4. Upewnij się, że ta edycja jest poprawna, porównując poniższy fragment kodu z przykładowego systemu plików NF firmy Contoso

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Skompiluj edytowany szablon usługi ARM i przekaż go do magazynu artefaktów

  1. Przejdź do katalogu utworzonego nsd-cli-output/artifacts az aosm nsd build przez polecenie i skompiluj szablon arm funkcji sieciowej z pliku BICEP wygenerowanego przez interfejs wiersza polecenia.

    bicep build <nf-name>.bicep

  2. Wygeneruj poświadczenia tokenu mapy zakresu na podstawie manifestu artefaktu utworzonego w poleceniu az aosm nsd publish .

    Ważne

    Wymagane jest użycie manifestu artefaktu utworzonego w poleceniu az aosm nsd publish . Szablon arm systemu plików NF jest zadeklarowany tylko w tym manifeście, dlatego tylko token mapy zakresu wygenerowany przez ten manifest umożliwia wypychanie (lub ściąganie) szablonu arm systemu plików NF do magazynu artefaktów.

    az rest --method POST --url 'https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.HybridNetwork/publishers/<publisher>/artifactStores/<artifact-store>/artifactManifests/<artifactManifest>/listCredential?api-version=2023-09-01'

  3. Zaloguj się do usługi ACR zarządzanej przez usługę ACR w usłudze AOSM. Nazwę usługi ACR zarządzaną przez usługę AOSM można znaleźć w artykule Omówienie zasobu usługi Artifact Store w witrynie Azure Portal. Nazwę użytkownika i hasło można znaleźć w danych wyjściowych poprzedniego kroku.

    oras login <aosm-managed-acr-name>.azurecr.io --username <username> --password <scope map token>

  4. Użyj usługi ORAS, aby przekazać szablon arm funkcji sieciowej do zarządzanej przez usługę AOSM usługi Azure Container Registry (ACR). Tag <arm-template-version> artefaktu musi mieć 1.0.0 format. Wartości <arm-template-name> i <arm-template-version> muszą być zgodne z wartościami w manifeście artefaktu utworzonym w poleceniu az aosm nsd publish .

Zastępowanie --atomic systemu plików NF z wieloma pakietami helm

Wiele złożonych NFs jest tworzonych na podstawie wielu wykresów helm. Te NFs są wyrażane w wersji definicji funkcji sieciowej (NFDV) z wieloma aplikacjami funkcji sieciowych i są instalowane z wieloma helm install poleceniami — jeden na wykres helm.

Proces zastępowania --atomic wielo helm NF jest taki sam jak w przypadku pojedynczego systemu plików NF helm, oprócz edycji wprowadzonej do szablonu usługi ARM.

Fikcyjny multi-helm NF, Contoso-multi-helm, składa się z trzech wykresów helm. Jego NFDV ma trzy aplikacje funkcji sieciowych. Jedna aplikacja funkcji sieciowej mapuje na jeden wykres helm. Te aplikacje funkcji sieciowych mają właściwość name ustawioną odpowiednio na Contoso-one, Contoso-twoi Contoso-three . Oto przykładowy fragment kodu NFDV definiujący tę funkcję sieciową.

resource nfdv 'Microsoft.Hybridnetwork/publishers/networkfunctiondefinitiongroups/networkfunctiondefinitionversions@2023-09-01' = {
  parent: nfdg
  name: nfDefinitionVersion
  location: location
  properties: {
    deployParameters: string(loadJsonContent('deployParameters.json'))
    networkFunctionType: 'ContainerizedNetworkFunction'
    networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-one'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-two'
          ...
        },
        {
          artifactType: 'HelmPackage'
          name: 'Contoso-three'
          ...
        }]
      }
    }
  }

Parametr --atomic można zastąpić niezależnie dla każdej z tych aplikacji funkcji sieciowych. Oto przykładowy szablon BICEP systemu plików NF, który zastępuje --atomic false element dla Contoso-one parametrów i Contoso-two, ale ustawia wartość atomic true dla elementu Contoso-three.

resource nfResource 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = [for (values, i) in configObject.deployParameters: {
  name: '${configObject.nfdgName}${i}'
  location: configObject.location
  identity: identityObject
  properties: {
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdv.id
      idType: 'Open'
    }
    nfviType: 'AzureArcKubernetes'
    nfviId: (configObject.customLocationId == '') ? resourceGroupId : configObject.customLocationId
    allowSoftwareUpdate: true
    configurationType: 'Open'
    deploymentValues: string(values)
    roleOverrideValues: [
      '{"name":"Contoso-one","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-two","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
      '{"name":"Contoso-three","deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"injectArtifactStoreDetails":"true", "atomic": "false"},"upgradeOptions":{"injectArtifactStoreDetails":"true","atomic": "false"}}}}}'
    ]}}]

Następne kroki

Teraz możesz ponowić próbę wdrożenia SNS. Wdrożenie można przesłać ponownie za pomocą usługi ARM, BICEP lub interfejsu API REST usługi AOSM. Możesz również usunąć nieudane sns za pomocą przeglądu sns witryny Azure Portal i ponownie wdrożyć go, wykonując kroki opisane w przewodniku Szybki start, zastępując parametry systemu plików NF przewodnika Szybki start parametrami funkcji sieciowej. Wydania narzędzia Helm wdrożone w klastrze Kubernetes nie zostaną usunięte po awarii. Jak debugować błędy wdrażania sns opisuje zestaw narzędzi do debugowania typowych błędów instalacji narzędzia Helm.