Partager via

Vue d’ensemble des exigences en lien avec Helm

  • Article

Le gestionnaire de package pour Kubernetes, Helm, permet de simplifier la gestion du cycle de vie des applications. Les packages Helm sont appelés des graphiques et se composent de fichiers de configuration et de modèle YAML. Lors de l’exécution d’une opération Helm, les graphiques sont rendus dans des fichiers manifeste Kubernetes pour déclencher l’action du cycle de vie de l’application appropriée. Pour que l’intégration avec Azure Operator Service Manager (AOSM) soit la plus efficace, l’éditeur doit prendre en compte certaines considérations recommandées lors du développement des graphiques Helm.

Remarques à prendre en compte pour registryUrl et imagePullSecrets

Chaque graphique Helm nécessite généralement un paramètre registryUrl déclaré et un paramètre imagePullSecrets. Il est recommandé à l’éditeur de définir ces deux paramètres de manière cohérente en tant que variables dans values.yaml. Au début, AOSM dépendait du fait que l’éditeur expose ces valeurs de manière stricte, afin qu’elles puissent être ingérées, puis injectées pendant le déploiement. Cette approche est appelée méthode héritée. Au fil du temps, de nombreuses complications se sont produites, car tous les graphiques des éditeurs n’étaient pas conformes à la définition stricte des paramètres registryUrl et imagePullSecrets requise par AOSM.

  • Certains graphiques masquent registryUrl et/ou imagePullSecrets derrière des conditions, ou d’autres restrictions de valeurs, qui n’étaient pas toujours remplies.
  • Certains graphiques ne déclarent pas les paramètres registryUrl et/ou imagePullSecrets sous la forme de la chaîne nommée attendue, mais sous la forme d’un tableau.

Pour réduire les exigences de conformité strictes des éditeurs pour registryUrl et imagePullSecrets, AOSM a introduit plus tard deux méthodes améliorées de gestion de ces valeurs. Tout d’abord injectArtifactStoreDetail et enfin le Registre de clusters. Ces deux méthodes plus récentes ne dépendent pas de l’affichage ou non des paramètres registryUrl et imagePullSecrets dans le package Helm. Au lieu de cela, ces méthodes dérivent de ces valeurs et les injectent pour le compte de la fonction réseau.

Résumé de la méthode pour registryUrl et imagePullSecrets

Héritage.

  • Éditeur requis pour paramétriser registryUrl et imagePullSecrets correctement dans les modèles et les valeurs Helm de substitution.
  • Images hébergées dans Azure Container Registry (ACR) de l’éditeur.

InjectArtifactStoreDetail.

  • Utilise un webhook pour injecter registryUrl et imagePullSecrets directement dans le pod sans dépendance à Helm.
  • Images toujours hébergées dans l’ACR de l’éditeur.

Registre de clusters.

  • Identique à InjectArtifactStoreDetail, sauf que les images sont désormais hébergées dans le registre de clusters local.

Remarque

Dans les trois cas, AOSM remplace les secrets dérivés d’AOSM par les secrets qu’un éditeur expose dans les modèles. La seule différence est Héritage et InjectArtifactStoreDetail, le secret est lié à l’ACR de l’éditeur, tandis que dans le Registre de clusters, le secret est lié au registre de clusters.

Exigences Legacy pour registryUrl et imagePullSecrets

Azure Operator Service Manager (AOSM) utilise le service Network Function Manager (NFM) pour déployer la fonction réseau conteneurisée (CNF). Le service NFM injecte dynamiquement registryUrl et imagePullSecrets du conteneur dans les valeurs Helm pendant le déploiement de la fonction réseau (NF). Le modèle de déploiement Helm suivant montre un exemple de la façon dont un éditeur doit exposer registryPath et imagePullSecrets pour la compatibilité avec l’approche héritée d’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

Le fichier values.schema.json suivant montre un exemple de la façon dont un éditeur peut définir facilement les exigences liées aux paramètres registryPath et imagePullSecrets pour la compatibilité avec l’approche héritée d’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" ], 
      } 
   } 
}

La NFDVersion request payload suivante montre un exemple de la façon dont un éditeur peut fournir les valeurs registryPath et imagePullSecrets pour la compatibilité avec l’approche héritée d’AOSM.

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

La values.yaml suivante montre un exemple de la façon dont un éditeur peut fournir les valeurs registryPath et imagePullSecrets pour la compatibilité avec l’approche héritée d’AOSM.

global: 
   imagePullSecrets: [] 
   registryPath: “”
Nom Type Description
imagePullSecrets Chaîne Le paramètre imagePullSecrets est un tableau de noms de secrets, qui sont utilisés pour extraire des images conteneur
registryPath Chaîne Le paramètre registryPath est l’emplacement du serveur AzureContainerRegistry

Remarque

  • Le paramètre registryPath est défini sans préfixe comme https:// ou oci://. Si nécessaire, l’éditeur doit définir un préfixe dans le package Helm.
  • Les paramètres imagePullSecrets et registryPath doivent être fournis à l’étape d’intégration NFDVersion de création.

Éviter des références à un registre externe

Les utilisateurs doivent éviter d’utiliser des références à un registre externe. Par exemple, si deployment.yaml utilise un chemin d’accès au Registre codé en dur ou des références à un registre externe, il échoue à la validation.

Validations manuelles

Passez en revue les images et les spécifications de conteneur créées pour vous assurer que les images ont le préfixe registryURL et que le paramètre imagesPullSecrets est renseigné avec secretName.

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

OR

 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>

Référentiel et balises d’images statiques

Chaque graphique Helm doit contenir des balises et un référentiel d’images statiques. Les valeurs statiques sont définies comme suit :

  • Définition de ces éléments dans la ligne d’image ou,
  • Définition de ces éléments dans values.yaml, qui ne sont pas exposés dans la version de conception de fonction réseau (NFDV).

Une version de conception de fonction réseau (NFDV) doit être mappée à un ensemble statique de graphiques et d’images Helm. Les graphiques et les images sont mis à jour uniquement en publiant une nouvelle version NFDV.

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

Or

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

Exigences injectArtifactStoreDetails pour registryUrl et imagePullSecrets

Dans certains cas, les graphiques Helm tiers peuvent ne pas être entièrement conformes aux exigences AOSM pour registryURL. Dans ce cas, la fonctionnalité injectArtifactStoreDetails peut être utilisée pour éviter d’apporter des modifications aux packages Helm. Pour utiliser injectArtifactStoreDetails, définissez le paramètre installOptions dans la section roleOverrides de la ressource NF sur true, puis, dans le package de graphiques Helm, utilisez une valeur registryURL nécessaire pour que l’URL du registre reste valide. Consultez l’exemple suivant où le paramètre injectArtifactStoreDetails est activé.

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

Restrictions d’immuabilité du graphique

Les restrictions d’immuabilité empêchent les modifications d’un fichier ou d’un répertoire. Par exemple, un fichier immuable ne peut pas être modifié ni renommé. Les utilisateurs doivent éviter d’utiliser des balises mutables telles que latest, dev ou stable. Par exemple, si deployment.yaml a utilisé « latest » pour .Values.image.tag, le déploiement échoue.

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

Déclaration CRD de graphique et fractionnement de l’utilisation

Nous vous recommandons de fractionner la déclaration et l’utilisation des définitions de ressources client (CRD) en graphiques Helm distincts pour prendre en charge les mises à jour. Pour plus d’informations, consultez : method-2-separate-charts