Übersicht über die Helm-Anforderungen

Artikel
02/09/2025

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 deklarierte registryUrl und imagePullSecrets. Die bewährten Methoden empfehlen, dass der Herausgeber diese beiden Parameter konsistent als Variablen in „values.yaml“ definiert. Zunächst hängt AOSM davon ab, dass der Herausgeber diese Werte strikt verfügbar macht, sodass sie während der Bereitstellung aufgenommen und dann injiziert werden können. Dieser Ansatz wird als Legacymethode bezeichnet. Mit der Zeit entstanden viele Komplikationen, da nicht alle Herausgebercharts die strenge Definition von registryUrl und imagePullSecrets erfüllten, die von AOSM benötigt wird.

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 für registryUrl und imagePullSecrets 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 Werten für registryUrl oder imagePullSecrets ab. Stattdessen leiten diese Methoden diese Werte im Auftrag der Netzwerkfunktion ab und fügen sie ein.

Methodenübersicht für registryUrl und imagePullSecrets

Legacy.

Erforderlicher Herausgeber zum Parametrisieren von registryUrl und imagePullSecrets korrekt in Helm-Werten und Vorlagen zur Ersetzung.
Images, die in der Azure Container Registry (ACR) gehostet werden.

InjectArtifactStoreDetail.

Verwendet einen Webhook, um registryUrl und imagePullSecrets direkt in Pod ohne Abhängigkeit vom Helm einzufügen.
Images, die weiterhin in Publisher ACR gehostet werden.

Clusterregistrierung.

Identisch mit InjectArtifactStoreDetail, außer dass jetzt die Images in der lokalen Clusterregistrierung gehostet werden.

Hinweis

In allen drei Fällen ersetzt AOSM abgeleitete Geheimschlüssel durch geheime Schlüssel, die ein Herausgeber in Vorlagen verfügbar macht. Der einzige Unterschied bei Legacy und InjectArtifactStoreDetail ist, dass der geheime Schlüssel an Publisher ACR gebunden ist, während in der Clusterregistrierung der geheime Schlüssel an die Clusterregistrierung gebunden ist.

Legacyanforderungen für registryUrl und imagePullSecrets

Azure Operator Service Manager (AOSM) verwendet den Network Function Manager (NFM)-Dienst zum Bereitstellen der Containerized Network Function (CNF). Der NFM fügt Container registryUrl und imagePullSecrets dynamisch in die Helm-Werte während der Bereitstellung von Network Function (NF) ein. 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: “”

Name	Typ	Beschreibung
imagePullSecrets	String	imagePullSecrets sind ein Array geheimer Namen, die zum Abrufen von Containerimages verwendet werden
registryPath	String	registryPath ist der Serverspeicherort von `AzureContainerRegistry`

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.

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.

Manuelle Validierungen

Ü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>

Statisches Imagerepository 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 Änderungen an Helm-Charts zu vermeiden. Um injectArtifactStoreDetails zu verwenden, legen Sie den installOptions-Parameter im Abschnitt roleOverrides der NF-Ressource auf TRUE fest und verwenden Sie dann im Helm-Chartpaket den erforderlichen registryURL-Wert, um die Registrierungs-URL gültig zu halten. Sehen Sie sich das folgende Beispiel für den aktivierten injectArtifactStoreDetails-Parameter an.

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

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

Teilen über