Udostępnij przez

Najlepsze rozwiązania dotyczące pakietu Helm

Helm to menedżer pakietów dla platformy Kubernetes, który ułatwia zarządzanie cyklem życia aplikacji. Pakiety Helm są nazywane wykresami i składają się z konfiguracji YAML i plików szablonów. Po wykonaniu operacji programu Helm wykresy są renderowane w plikach manifestu platformy Kubernetes w celu wyzwolenia odpowiednich akcji cyklu życia aplikacji. Aby uzyskać najbardziej wydajną integrację z programem Azure Operator Service Manager, postępuj zgodnie z tymi zalecanymi najlepszymi rozwiązaniami podczas tworzenia wykresów programu Helm.

Zagadnienia dotyczące „registryPath” i „imagePullSecrets”

Każdy wykres helm zazwyczaj wymaga registryPath parametrów i imagePullSecrets . Najczęściej te parametry są uwidaczniane w values.yaml pliku. Na początku menedżer usług operatora platformy Azure zależy od wydawców zarządzających tymi wartościami w ścisły sposób (starsze podejście), które mają zostać zastąpione odpowiednimi wartościami platformy Azure podczas wdrażania. Ale nie wszyscy wydawcy mogą łatwo przestrzegać ścisłego zarządzania tymi wartościami. Niektóre wykresy ukrywają registryPath i/lub imagePullSecrets za warunkowymi lub innymi ograniczeniami wartości, które nie zawsze były spełnione. Niektóre wykresy deklarują registryPath i/lub imagePullSecrets jako tablicę, a nie jako oczekiwany nazwany ciąg.

Aby zmniejszyć wymagania dotyczące zgodności wydawców, program Azure Operator Service Manager wprowadził dwie ulepszone metody: injectArtifactStoreDetail i rejestr klastrów. Te nowsze metody nie zależą od registryPath ani imagePullSecrets nie pojawiają się w pakiecie Helm. Zamiast tego te metody używają elementu webhook do wstrzykiwania odpowiednich wartości platformy Azure bezpośrednio do operacji zasobnika.

Podsumowanie metody registryPath i imagePullSecrets

Wszystkie trzy metody są obecnie obsługiwane zgodnie z opisem w tym artykule. Wybierz najlepszą opcję dla funkcji sieciowej (NF) i przypadku użycia.

Spuścizna:

  • Wymaga sparametryzowania registryPath wartości i imagePullSecrets szablonów wdrażania programu Helm na potrzeby podstawienia.
  • Hostuje obrazy w usłudze Azure Container Registry.

InjectArtifactStoreDetail:

  • Używa elementu webhook do wstrzykiwania registryPath i imagePullSecrets bezpośredniego do operacji zasobnika z minimalnymi zależnościami w programie Helm.
  • Hostuje obrazy w usłudze Azure Container Registry.

Rejestr klastrów:

  • Używa elementu webhook do wstrzykiwania registryPath i imagePullSecrets bezpośredniego do operacji zasobnika bez zależności od programu Helm.
  • Hostuje obrazy w rozszerzeniu operatora funkcji sieci lokalnej (NFO).

We wszystkich trzech przypadkach program Azure Operator Service Manager zastępuje wartości platformy Azure wszystkimi wartościami udostępnianymi w szablonach. Jedyną różnicą jest metoda podstawienia.

Starsze wymagania dotyczące elementu registryPath i imagePullSecrets

Menedżer usług operatora platformy Azure używa usługi Menedżer funkcji sieci platformy Azure do wdrażania konteneryzowanych funkcji sieciowych (CNFs). W przypadku starszej metody menedżer funkcji sieci platformy Azure zastępuje wartości i registryPath kontenera imagePullSecrets programu Azure Operator Service Manager operacją programu Helm podczas wdrażania funkcji sieciowych.

Przykład starszej metody

Poniższy szablon wdrażania programu Helm przedstawia przykład sposobu uwidacznienia registryPath i imagePullSecrets:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: nginx-deployment 
  labels: 
    app: nginx 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      {{- if .Values.global.imagePullSecrets }} 
      imagePullSecrets: {{ toYaml .Values.global.imagePullSecrets | nindent 8 }} 
      {{- end }} 
      containers: 
      - name: contosoapp 
        image:{{ .Values.global.registryPath }}/contosoapp:1.14.2 
        ports: 
        - containerPort: 80

Poniższy values.yaml szablon przedstawia przykład sposobu podawania registryPath wartości i imagePullSecrets :

global: 
   imagePullSecrets: [] 
   registryPath: ""

values.schema.json Poniższy plik przedstawia przykład sposobu definiowania registryPath wartości iimagePullSecrets:

{ 
  "$schema": "http://json-schema.org/draft-07/schema#", 
  "title": "StarterSchema", 
  "type": "object", 
  "required": ["global"], 
  "properties": { 
      "global" : {
          "type": "object",
          "properties": {
              "registryPath": {"type": "string"}, 
              "imagePullSecrets": {"type": "string"}, 
          }
          "required": [ "registryPath", "imagePullSecrets" ], 
      } 
   } 
}

Poniższy ładunek żądania definicji funkcji sieciowej (NFDV) przedstawia przykład sposobu podawania registryPath wartości i imagePullSecrets podczas wdrażania:

"registryValuesPaths": [ "global.registryPath" ], 
"imagePullSecretsValuesPaths": [ "global.imagePullSecrets" ],

W poprzednich przykładach:

  • Wartość registryPath jest ustawiana bez żadnego prefiksu, takiego jak https:// lub oci://. W razie potrzeby zdefiniuj prefiks w pakiecie Helm.
  • imagePullSecrets należy registryPath podać podczas dołączania systemu plików NFDV.

Inne uwagi

Podczas korzystania ze starszej metody należy wziąć pod uwagę następujące zalecenia.

Unikanie odwołań do rejestru zewnętrznego

Odwołania do rejestru zewnętrznego mogą powodować problemy z walidacją. Jeśli na przykład deployment.yaml używa zakodowanej ścieżki rejestru lub odwołań do rejestru zewnętrznego, weryfikacja zakończy się niepowodzeniem.

Wykonywanie ręcznych walidacji

Przejrzyj specyfikacje obrazów i kontenerów, aby upewnić się, że obrazy mają prefiks i są registryPath wypełniane ciągiem :imagePullSecretssecretName

 helm template --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryPath>" <release-name> <chart-name> --dry-run

Oto kolejny przykład:

 helm install --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryPath>" <release-name> <chart-name> --dry-run
 kubectl create secret <secretName> regcred --docker-server=<registryPath> --dockerusername=<regusername> --docker-password=<regpassword>

Używanie repozytorium obrazów statycznych i tagów

Każdy wykres helm powinien zawierać repozytorium i tagi obrazów statycznych. Wartości statyczne można ustawić za pomocą jednej z następujących metod:

  • image W wierszu
  • W values.yamlsystemie bez uwidaczniania tych wartości w systemie plików NFDV

NFDV powinien być mapowany na statyczny zestaw wykresów i obrazów programu Helm. Wykresy i obrazy są aktualizowane tylko przez opublikowanie nowego systemu plików NFDV, jak pokazano w poniższych przykładach:

 image: "{{ .Values.global.registryPath }}/contosoapp:1.14.2"

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}"
 
YAML values.yaml
image:
  repository: contosoapp
  tag: 1.14.2

 image: http://myUrl/{{ .Values.image.repository }}:{{ .Values.image.tag}}

injectArtifactStoreDetails requirements for registryPath and imagePullSecrets (wymagania dotyczące metody injectArtifactStoreDetails dla metody registryPath i imagePullSecrets)

W niektórych przypadkach wykresy programu Helm innych firm mogą nie być w pełni zgodne z wymaganiami programu Azure Operator Service Manager dla programu registryPath. W takich przypadkach można użyć injectArtifactStoreDetails polecenia , aby uniknąć wprowadzania zmian zgodności w pakietach helm.

Po injectArtifactStoreDetails włączeniu można użyć metody elementu webhook, aby wstrzyknąć odpowiednie registryPath i imagePullSecrets dynamicznie podczas operacji zasobnika. Ta metoda zastępuje wartości skonfigurowane w pakiecie Helm. Nadal musisz używać legalnych wartości fikcyjnych, w których i registryPath do których imagePullSecrets się odwołujesz, zwykle w global sekcji .values.yaml

W poniższym values.yaml przykładzie pokazano, jak można podać registryPath wartości i imagePullSecrets pod kątem zgodności z podejściem injectArtifactStoreDetails :

global: 
   registryPath: "azure.io"
   imagePullSecrets: ["abc123"]

Uwaga

Jeśli registryPath w bazowym pakiecie Helm pozostanie puste, wdrożenie usługi sieciowej lokacji kończy się niepowodzeniem podczas pobierania obrazu.

Za pomocą metody injectArtifactStoreDetails

Aby włączyć injectArtifactStoreDetails, ustaw installOptions parametr w sekcji zasobu roleOverrides NF na truewartość , jak pokazano w poniższym przykładzie:

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}

Uwaga

Pakiet wykresu Helm musi nadal być poprawnie sformatowany registryPath i imagePullSecrets wartości.

Wymagania dotyczące rejestru klastra dla elementu registryPath i imagePullSecrets

W rejestrze klastrów obrazy są kopiowane z usługi Azure Container Registry do lokalnego repozytorium platformy Docker w klastrze Nexus Kubernetes. Metoda elementu webhook służy do dynamicznego wstrzykiwania odpowiednich registryPath wartości i imagePullSecrets podczas operacji zasobnika. Ta metoda zastępuje wartości skonfigurowane w pakiecie Helm. Nadal musisz używać legalnych wartości fikcyjnych, w których i registryPath do których imagePullSecrets się odwołujesz, zwykle w global sekcji .values.yaml

W poniższym values.yaml przykładzie pokazano, jak można podać registryPath wartości i imagePullSecrets pod kątem zgodności z podejściem rejestru klastra:

global: 
   registryPath: "azure.io"
   imagePullSecrets: ["abc123"]

Uwaga

Jeśli registryPath w bazowym pakiecie Helm pozostanie puste, wdrażanie sns kończy się niepowodzeniem podczas pobierania obrazu.

Aby uzyskać więcej informacji na temat korzystania z rejestru klastrów, zobacz dokumentację koncepcji.

Zalecenia dotyczące ograniczeń niezmienności

Ograniczenia niezmienności uniemożliwiają zmianę pliku lub katalogu. Na przykład, pliku niezmienialnego nie można zmienić ani zmienić jego nazwy. Należy unikać używania tagów modyfikowalnych, takich jak latest, devlub stable. Jeśli na przykład deployment.yaml jest używany latest program , .Values.image.tagwdrożenie zakończy się niepowodzeniem.

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}"

Zalecenia dotyczące podziału deklaracji CRD i użycia

Zalecamy podzielenie deklaracji i użycia definicji zasobów klienta (CRD) na oddzielne wykresy programu Helm w celu obsługi aktualizacji. Aby uzyskać szczegółowe informacje, zobacz dokumentację programu Helm dotyczącą oddzielania wykresów.

Zalecenia dotyczące tagowania wersji obrazu

Aby zapewnić spójne i przewidywalne wdrożenia, zalecamy następujące elementy dla wszystkich obrazów kontenerów:

  • Unikaj używania :latest w środowiskach produkcyjnych.
    • Użycie najnowszych może spowodować nieoczekiwane zachowanie, ponieważ rzeczywisty obraz za najnowszą wersją może ulec zmianie bez powiadomienia.
    • W konfiguracji rejestru klastra, jeśli wartość tagu zmieni się, ale nazwa tagu pozostanie taka sama, rejestr klastra nie pobierze ponownie zaktualizowanego obrazu.
    • Może to prowadzić do uruchamiania nieaktualnych lub niespójnych obrazów.
  • Zamiast tego zawsze używaj niezmiennych tagów, takich jak :1.4.2
  • Upewnij się, że każda kompilacja tworzy unikatowy tag, nie zastępuje istniejących tagów.

Te rozwiązania pomagają zapobiegać problemom z wdrażaniem i poprawiać możliwość śledzenia, wycofywanie bezpieczeństwa i zgodność z zabezpieczeniami.

Zalecenia dotyczące sekwencyjnego porządkowania aplikacji nfApplication

Domyślnie aplikacje CNF są instalowane lub aktualizowane na podstawie kolejności, w jakiej są wyświetlane w systemie plików NFDV. W przypadku operacji usuwania aplikacje CNF są usuwane w określonej kolejności odwrotnej. Jeśli musisz zdefiniować określoną kolejność aplikacji CNF, która różni się od domyślnej, użyj polecenia dependsOnProfile , aby zdefiniować unikatową sekwencję dla operacji instalacji, aktualizacji i usuwania.

Jak używać metody dependsOnProfile

Za pomocą dependsOnProfile systemu plików NFDV można kontrolować sekwencję wykonań programu Helm dla aplikacji CNF. W poniższym przykładzie:

  • Podczas operacji instalacji aplikacje CNF są wdrażane w następującej kolejności: dummyApplication1, , dummyApplication2dummyApplication.
  • Podczas operacji aktualizacji aplikacje CNF są aktualizowane w następującej kolejności: dummyApplication2, , dummyApplication1dummyApplication.
  • Podczas operacji usuwania aplikacje CNF są usuwane w następującej kolejności: dummyApplication2, , dummyApplication1dummyApplication.
{
    "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 dotyczące pliku dependsOnProfile

Obecnie, jeśli dependsOnProfile kod podany w NFDV jest nieprawidłowy, operacja NF kończy się niepowodzeniem z powodu błędu walidacji. Komunikat o błędzie weryfikacji jest wyświetlany w zasobie stanu operacji i wygląda podobnie do następującego 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."
  }
}
  • Last updated on