Helmpaketanforderungen

Artikel
11/08/2023

Helm ist ein Paketmanager für Kubernetes, mit dem Sie Kubernetes-Anwendungen verwalten können. Helmpakete werden als Diagramme bezeichnet, und sie bestehen aus einigen YAML-Konfigurationsdateien und einigen Vorlagen, die in Kubernetes-Manifestdateien gerendert werden. Diagramme werden von jedem für jede Umgebung wiederverwendbar, wodurch Komplexität und Duplikate reduziert werden.

Anforderungen für Registrierungs-URL-Pfad und Imagepullsecrets

Beim Entwickeln eines Helmpakets ist es üblich, die URL des Containerregistrierungsservers in den Werten beizubehalten. Das Beibehalten der Containerregistrierungsserver-URL in den Werten ist nützlich, um Artefakte zwischen jeder Umgebungscontainerregistrierung zu verschieben. Azure Operator Service Manager (AOSM) verwendet den Network Function Manager (NFM)-Dienst zum Bereitstellen von Containerized Network Function (CNF). Der Network Function Manager (NFM) enthält Features zum Einfügen von Containerregistrierungsserverspeicherorten und Imagepullsecrets in die Helmwerte während der Netzwerkfunktionsbereitstellung (NF). Ein imagePullSecret ist ein Autorisierungstoken, das auch als geheimer Schlüssel bezeichnet wird, der Docker-Anmeldeinformationen speichert, die für den Zugriff auf eine Registrierung verwendet werden. Wenn Sie beispielsweise eine Anwendung über kubernetes-Bereitstellung bereitstellen müssen, können Sie eine Bereitstellung wie das folgende Beispiel definieren:

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

values.schema.json ist eine Datei, mit der Sie Wertanforderungen und Einschränkungen an einer zentralen Stelle für Helm-Diagramme problemlos festlegen können. Definieren Sie in dieser Datei registryPath und imagePullSecrets als erforderliche Eigenschaften.

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

Die NFDVersion-Anforderungsnutzlast stellt die folgenden Werte in den registryValuesPaths bereit:

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

Während einer NF-Bereitstellung legt der Network Function Operator (NFO) den RegistryPath auf den richtigen Azure Container Registry (ACR)-Serverspeicherort fest. Beispielsweise führt der NFO den folgenden entsprechenden Befehl aus:

$ helm install --set "global.registryPath=<registryURL>" --set "global.imagePullSecrets[0].name=<secretName>" releasename ./releasepackage

Hinweis

Der registryPath wird ohne Präfix wie https:// oder oci:// festgelegt. Wenn im Helmpaket ein Präfix erforderlich ist, müssen Herausgeber dies im Paket definieren.

values.yaml ist eine Datei, die die Standardwerte für ein Helm-Diagramm enthält. Es ist eine YAML-Datei, die die Standardwerte für ein Diagramm definiert. In der Datei values.yaml müssen zwei Arten von Variablen vorhanden sein; imagePullSecrets und registryPath. Jede wird in der Tabelle beschrieben.

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.`AzureContainerRegistry`

imagePullSecrets und registryPath müssen im Create NFDVersion-Onboarding-Schritt bereitgestellt werden.

Ein im Cluster ausgeführtes NFO füllt diese beiden Variablen (imagePullSecrets und registryPath) während einer Helmversion mit dem Befehl "Install –set" auf.

Weitere Informationen finden Sie unter: Pull-image-private-registry

Unveränderlichkeitseinschränkungen

Unveränderlichkeitseinschränkungen verhindern Änderungen an einer Datei oder einem Verzeichnis. Beispielsweise kann eine unveränderliche Datei nicht geändert oder umbenannt werden, und eine Datei, die Anfügevorgänge zulässt, kann nicht gelöscht, geändert oder umbenannt werden.

Vermeiden der Verwendung von veränderbaren Tags

Benutzer sollten die Verwendung von veränderbaren Tags wie neueste, Dev oder Stable vermeiden. Beispiel: Wenn deployment.yaml "latest" für die . Values.image.tag würde die Bereitstellung fehlschlagen.

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

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.

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

Empfehlungen

Das Aufteilen der Deklaration und Verwendung von benutzerdefinierten Ressourcendefinitionen (CUSTOM Resource Definitions, CRDs) sowie die Verwendung mithilfe manueller Überprüfungen sind empfohlene Methoden. Jede wird in den folgenden Abschnitten beschrieben.

Geteilte CRD-Deklaration und -Verwendung

Es wird empfohlen, die Deklaration und Verwendung von CRDs in separate Steuerdiagramme aufzuteilen, um Updates zu unterstützen. Ausführliche Informationen finden Sie unter: Methoden-2-separate-Diagramme

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

 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 Bild-Repository und Tags

Jedes Steuerdiagramm sollte ein statisches Bild-Repository und Tags enthalten. Benutzer sollten das Bild-Repository und das Tag auf statische Werte festlegen. Die statischen Werte können wie folgt festgelegt werden:

Durch hartcodieren Sie sie in der Bildzeile oder
Festlegen der Werte in values.yaml und nicht verfügbarmachen dieser Werte in der Network Function Design Version (NFDV).

Eine Network Function Design Version (NFDV) sollte einem statischen Satz von Steuerdiagrammen und Bildern zugeordnet werden. Die Diagramme und Bilder 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

Teilen über