Omówienie wymagań programu Helm

Artykuł
02/04/2025

Helm to menedżer pakietów dla platformy Kubernetes, który pomaga uprościć 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 odpowiedniej akcji cyklu życia aplikacji. Aby zapewnić najbardziej wydajną integrację z programem Azure Operator Service Manager (AOSM), wydawca powinien rozważyć pewne zagadnienia dotyczące najlepszych rozwiązań podczas tworzenia wykresów programu Helm.

Zagadnienia dotyczące rejestruUrl i imagePullSecrets

Każdy wykres helm zazwyczaj wymaga zadeklarowanego rejestruUrl i imagePullSecrets. Najlepsze rozwiązanie zaleca, aby wydawca konsekwentnie definiuje te dwa parametry jako zmienne w pliku values.yaml. Na początku usługa AOSM polegała na ujawnieniu tych wartości przez wydawcę w ścisły sposób, dzięki czemu można je pozyskiwać, a następnie wprowadzać podczas wdrażania. Takie podejście jest znane jako starsza metoda. W godzinach nadliczbowych pojawiło się wiele komplikacji, ponieważ nie wszystkie wykresy wydawców były zgodne z ścisłą definicją registryUrl i imagePullSecrets wymagane przez AOSM.

Niektóre wykresy ukrywają wartości registryUrl i/lub imagePullSecrets za warunkowymi lub innymi ograniczeniami wartości, które nie zawsze były spełnione.
Niektóre wykresy nie deklarują wartości registryUrl i/lub imagePullSecrets jako oczekiwanego nazwanego ciągu, a nie jako tablicę.

Aby zmniejszyć ścisłe wymagania dotyczące zgodności dla wydawców rejestruUrl i imagePullSecrets, system AOSM wprowadził później dwie ulepszone metody obsługi tych wartości. Najpierw wstrzykiwanieArtifactStoreDetail i na koniec Rejestr klastrów. Te dwie nowsze metody nie zależą od rejestruUrl lub imagePullSecrets wyświetlanych w pakiecie Helm w ogóle. Zamiast tego te metody pochodzą i wstrzykują te wartości w imieniu funkcji sieciowej.

Podsumowanie metody dla registryUrl i imagePullSecrets

Spuścizna.

Wymagany wydawca do parametryzacji registryUrl & imagePullSecrets poprawnie w wartościach helm i szablonach do podstawienia.
Obrazy hostowane w usłudze Azure Container Registry (ACR).

InjectArtifactStoreDetail.

Używa elementu webhook do wstrzykiwania rejestruUrl i imagePullSecrets bezpośrednio do zasobnika bez żadnej zależności od narzędzia Helm.
Obrazy nadal hostowane w usłudze ACR wydawcy.

Rejestr klastrów.

Tak samo jak InjectArtifactStoreDetail, z wyjątkiem teraz obrazy są hostowane w rejestrze klastra lokalnego.

Uwaga

We wszystkich trzech przypadkach usługa AOSM jest zastępowaniem wpisów tajnych pochodnych AOSM przy użyciu jakichkolwiek wpisów tajnych udostępnianych przez wydawcę w szablonach. Jedyną różnicą jest starsza wersja i wstrzykiwanieArtifactStoreDetail, wpis tajny jest powiązany z usługą ACR wydawcy, podczas gdy w rejestrze klastrów wpis tajny jest powiązany z rejestrem klastra.

Starsze wymagania dotyczące rejestruUrl i imagePullSecrets

Program Azure Operator Service Manager (AOSM) używa usługi Network Function Manager (NFM) do wdrażania konteneryzowanej funkcji sieciowej (CNF). NFM wprowadza rejestr kontenerówUrl i imagePullSecrets dynamicznie do wartości helm podczas wdrażania funkcji sieciowej (NF). Poniższy szablon wdrażania narzędzia Helm przedstawia przykład, w jaki sposób wydawca powinien uwidaczniać metodę registryPath i imagePullSecrets w celu zachowania zgodności ze starszym podejściem AOSM.

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.schema.json plik przedstawia przykład, w jaki sposób wydawca może łatwo ustawić wymagania registryPath i imagePullSecretsvalue pod kątem zgodności ze starszym podejściem AOSM.

{ 
  "$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żej NFDVersion request payload przedstawiono przykład sposobu, w jaki wydawca może dostarczyć wartości registryPath i imagePullSecretsvalue pod kątem zgodności ze starszym podejściem AOSM.

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

Poniżej values.yaml przedstawiono przykład sposobu, w jaki wydawca może dostarczyć wartości registryPath i imagePullSecretsvalue pod kątem zgodności ze starszym podejściem AOSM.

global: 
   imagePullSecrets: [] 
   registryPath: “”

Nazwisko	Pisz	Opis
imagePullSecrets	String	imagePullSecrets to tablica nazw wpisów tajnych, które są używane do ściągania obrazów kontenerów
registryPath	String	registryPath to `AzureContainerRegistry` lokalizacja serwera

Uwaga

Ścieżka rejestru jest ustawiana bez żadnego prefiksu, takiego jak https:// lub oci://. W razie potrzeby wydawca musi zdefiniować prefiks w pakiecie helm.
imagePullSecrets i registryPath należy podać w kroku tworzenia dołączania NFDVersion.

Unikaj odwołań do rejestru zewnętrznego

Użytkownicy powinni unikać używania odwołań do rejestru zewnętrznego. Jeśli na przykład plik deployment.yaml używa zakodowanej na stałe ścieżki rejestru lub odwołuje się do rejestru zewnętrznego, walidacja zakończy się niepowodzeniem.

Ręczne walidacje

Przejrzyj utworzone obrazy i specyfikacje kontenera, aby upewnić się, że obrazy mają prefiks registryURL, a obrazyPullSecrets są wypełniane ciągiem secretName.

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

LUB

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

Repozytorium i tagi obrazów statycznych

Każdy wykres helm powinien zawierać statyczne repozytorium obrazów i tagi. Wartości statyczne są ustawiane w następujący sposób:

Ustawianie ich w wierszu obrazu lub,
Ustawienie ich w pliku values.yaml i nie uwidacznianie tych wartości w wersji projektowania funkcji sieciowej (NFDV).

Wersja projektu funkcji sieciowej (NFDV) powinna być mapowana na statyczny zestaw wykresów i obrazów programu Helm. Wykresy i obrazy są aktualizowane tylko przez opublikowanie nowej wersji projektu funkcji sieciowej (NFDV).

 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 wymagania dotyczące registryUrl i imagePullSecrets

W niektórych przypadkach wykresy helm innych firm mogą nie być w pełni zgodne z wymaganiami AOSM dla rejestruURL. W takim przypadku można użyć funkcji injectArtifactStoreDetails, aby uniknąć wprowadzania zmian w pakietach helm. Aby użyć parametru injectArtifactStoreDetails, ustaw parametr installOptions w sekcji rola zasobu NFOverrides na wartość true, a następnie w pakiecie wykresu helm użyj dowolnej wartości registryURL, aby zachować prawidłowy adres URL rejestru. Zobacz poniższy przykład z włączonym parametrem injectArtifactStoreDetails.

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"}}}}}'
    ]
  }
}

Ograniczenia niezmienności wykresu

Ograniczenia niezmienności uniemożliwiają zmianę pliku lub katalogu. Na przykład nie można zmienić ani zmienić nazwy pliku niezmiennego. Użytkownicy powinni unikać używania tagów modyfikowalnych, takich jak najnowsze, deweloperskie lub stabilne. Jeśli na przykład plik deployment.yaml używa polecenia "latest" dla elementu . Values.image.tag wdrożenie zakończy się niepowodzeniem.

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

Podział deklaracji CRD wykresu i użycia

Zalecamy podzielenie deklaracji i użycia definicji zasobów klienta (CRD) na oddzielne wykresy helm w celu obsługi aktualizacji. Aby uzyskać szczegółowe informacje, zobacz: method-2-separate-charts

Udostępnij za pośrednictwem