Teilen über

Übersicht über die Helm-Anforderungen

  • Artikel

Helm ist ein Paketmanager für Kubernetes, der hilft, die Verwaltung des Anwendungslebenszyklus zu vereinfachen. Helm-Pakete werden als Charts bezeichnet und bestehen aus YAML-Konfigurations- und Vorlagendateien. Bei Ausführung eines Helm-Vorgangs werden die Charts in Kubernetes-Manifestdateien gerendert, um die entsprechenden Aktionen für den Anwendungslebenszyklus auszulösen. Für die effizienteste Integration in Azure Operator Service Manager (AOSM) sollten Herausgeber bei der Entwicklung von Helm-Charts bestimmte bewährte Methoden berücksichtigen.

Überlegungen zu registryUrl und imagePullSecrets

Jeder Helm-Chart erfordert im Allgemeinen eine registryUrl und imagePullSecrets. In der Regel macht ein Herausgeber diese Parameter in „values.yaml“ verfügbar. Zunächst hängt AOSM davon ab, dass der Herausgeber diese Werte strikt verfügbar macht, sodass sie während der Bereitstellung durch die richtigen Azure-Werte ersetzt werden können. Im Laufe der Zeit konnten nicht alle Herausgeber die von AOSM geforderte strenge Handhabung dieser Werte problemlos einhalten.

  • Einige Charts blenden registryUrl und/oder imagePullSecrets hinter bedingten Bedingungen oder anderen Werteeinschränkungen aus, die nicht immer erfüllt wurden.
  • Einige Charts deklarieren registryUrl und/oder imagePullSecrets nicht als erwartete benannte Zeichenfolge, sondern als Array.

Um die strengen Complianceanforderungen für Herausgeber zu verringern, führte AOSM später zwei verbesserte Methoden zur Behandlung dieser Werte ein. Zuerst injectArtifactStoreDetail und schließlich Cluster Registry. Diese beiden neueren Methoden hängen nicht von den im Helm-Paket angezeigten gültigen Werten für registryUrl oder imagePullSecrets ab. Stattdessen injizieren die Methoden diese Werte im Auftrag der Netzwerkfunktion direkt in Podvorgänge.

Methodenübersicht für registryUrl und imagePullSecrets

Alle drei Methoden werden in diesem Artikel unterstützt und beschrieben. Ein Herausgeber sollte die beste Option für die Netzwerkfunktion und den Anwendungsfall auswählen.

Legacy.

  • Erfordert, dass Herausgeber registryUrl und imagePullSecrets in Helm-Werten und Bereitstellungsvorlagen für die Ersetzung konform parametrisieren.
  • Images, die in Azure Container Registry (ACR) gehostet werden.

InjectArtifactStoreDetail.

  • Verwendet einen Webhook, um registryUrl und imagePullSecrets mit minimalen Abhängigkeiten von Helm direkt in Podvorgänge zu injizieren.
  • Images werden weiterhin im Herausgeber-ACR gehostet.

Clusterregistrierung.

  • Verwendet einen Webhook, um registryUrl und imagePullSecrets ohne Abhängigkeit von Helm direkt in Podvorgänge zu injizieren.
  • Images werden in der lokalen NFO-Erweiterungsclusterregistrierung gehostet.

Hinweis

In allen drei Fällen ersetzt AOSM die AOSM-Werte für alle Werte, die ein Herausgeber in Vorlagen verfügbar macht. Der einzige Unterschied ist die Methode zum Ersetzen.

Legacyanforderungen für registryUrl und imagePullSecrets

Azure Operator Service Manager (AOSM) verwendet den Network Function Manager-Dienst (NFM) zum Bereitstellen der Containerized Network Function (CNF). Mit der Legacymethode ersetzt NFM die AOSM-Containerwerte registryUrl und imagePullSecrets im Helm-Vorgang während der Netzwerkfunktionsbereitstellung (NF).

Verwenden einer Legacymethode

Die folgende Vorlage für die Helm-Bereitstellung zeigt ein Beispiel dafür, wie ein Herausgeber registryPath und imagePullSecrets aus Kompatibilität mit dem AOSM-Legacyansatz verfügbar machen soll.

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

Die folgende values.schema.json-Datei zeigt ein Beispiel dafür, wie ein Herausgeber registryPath- und imagePullSecretsvalue-Anforderungen für die Kompatibilität mit dem AOSM-Legacyansatz problemlos festlegen kann.

{ 
  "$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" ], 
      } 
   } 
}

Im Folgenden NFDVersion request payload sehen Sie ein Beispiel dafür, wie ein Herausgeber die Werte für registryPath und imagePullSecretsvalue zur Kompatibilität mit dem AOSM-Legacyansatz bereitstellen kann.

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

Im Folgenden values.yaml sehen Sie ein Beispiel dafür, wie ein Herausgeber die Werte für registryPath und imagePullSecretsvalue zur Kompatibilität mit dem AOSM-Legacyansatz bereitstellen kann.

global: 
   imagePullSecrets: [] 
   registryPath: “”

Hinweis

  • Der registryPath wird ohne Präfix wie https:// oder oci:// festgelegt. Bei Bedarf muss der Herausgeber ein Präfix im Helm-Paket definieren.
  • imagePullSecrets und registryPath müssen im Create NFDVersion-Onboarding-Schritt bereitgestellt werden.

Weitere Überlegungen mit der Legacy-Methode

Herausgeber sollten außerdem die folgenden Empfehlungen berücksichtigen, wenn sie die Legacymethode verwenden:

  • Vermeiden von Verweisen auf externe Registrierung
  • Durchführen manueller Überprüfungen
  • Sicherstellen von statischen Imagerepositorys und Tags

Vermeiden von Verweisen auf externe Registrierung

Benutzer sollten keine Verweise auf eine externe Registrierung verwenden. Wenn beispielsweise deployment.yaml einen hartcodierten Registrierungspfad oder externe Registrierungsverweise verwendet, schlägt die Überprüfung fehl.

Durchführen manueller Überprüfungen

Überprüfen Sie die erstellten Images und Containerspezifikationen, um sicherzustellen, dass die Images das Präfix „registryURL“ haben und die imagePullSecrets mit „secretName“ aufgefüllt werden.

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

ODER

 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>

Sicherstellen von statischen Imagerepositorys und Tags

Jeder Helm-Chart sollte ein statisches Imagerepository und Tags enthalten. Die statischen Werte werden wie folgt festgelegt:

  • Legen Sie die Elemente in der Imagezeile fest oder
  • Legen Sie sie in values.yaml fest und geben diese Werte nicht in der Network Function Design Version (NFDV) an.

Eine Network Function Design Version (NFDV) sollte einem statischen Satz von Helm-Charts und Images zugeordnet werden. Die Charts und Images werden nur aktualisiert, indem eine neue Network Function Design Version (NFDV) veröffentlicht wird.

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

Oder

 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-Anforderungen für registryUrl und imagePullSecrets

In einigen Fällen sind Helm-Charts von Drittanbietern möglicherweise nicht vollständig mit den AOSM-Anforderungen für registryURL kompatibel. In diesem Fall können Sie das injectArtifactStoreDetails-Feature verwenden, um Complianceänderungen an Helm-Charts zu vermeiden. Wenn injectArtifactStoreDetails aktiviert ist, wird eine Webhookmethode verwendet, um die richtigen registryUrl- und imagePullSecrets-Werte dynamisch während der Podvorgänge zu injizieren. Dadurch werden die Werte überschrieben, die im Helm-Paket konfiguriert sind.

Verwenden der injectArtifactStoreDetails-Methode

Um injectArtifactStoreDetails zu aktivieren, legen Sie den installOptions-Parameter in im roleOverrides-Abschnitt der NF-Ressource auf TRUE fest, so wie im folgenden Beispiel gezeigt.

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

Hinweis

Das Helm-Diagrammpaket muss weiterhin ordnungsgemäß formatierte registryURL- und imagePullSecrets-Werte verfügbar machen.

Clusterregistrierungsanforderungen für registryUrl und imagePullSecrets

Informationen zur Verwendung der Clusterregistrierung finden Sie in der Konzeptdokumentation.

Einschränkungen für die Unveränderlichkeit von Charts

Einschränkungen für die Unveränderlichkeit verhindern Änderungen an einer Datei oder einem Verzeichnis. Beispielsweise kann eine unveränderliche Datei nicht geändert oder umbenannt werden. Benutzer sollten verhindern, dass veränderbare Tags wie „latest“, „dev“ oder „stabil“ verwendet werden. Beispiel: Wenn deployment.yaml „latest“ als .Values.image.tag verwendet, würde die Bereitstellung fehlschlagen.

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

Chart-CRD-Deklaration und Verwendungsteilung

Es wird empfohlen, die Deklaration und Verwendung von Kundenressourcendefinitionen (CRD) in separate Helm-Charts aufzuteilen, um Updates zu unterstützen. Ausführliche Informationen finden Sie unter: method-2-separate-charts