Partage 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 registryUrl et imagePullSecrets. Le plus souvent, un éditeur expose ces paramètres dans values.yaml. Au début, AOSM dépendait de l’éditeur exposant ces valeurs de manière stricte, afin qu’elles puissent être remplacées par les valeurs Azure appropriées pendant le déploiement. Les heures supplémentaires, tous les éditeurs ne peuvent pas se conformer facilement à la gestion stricte de ces valeurs requises 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 sur les éditeurs, 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 registryUrl ou d’imagePullSecrets valides apparaissant dans le package Helm. Au lieu de cela, ces méthodes injectent ces valeurs directement dans les opérations de pod, au nom de la fonction réseau.

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

Les trois méthodes sont prises en charge et décrites dans cet article. Un éditeur doit choisir la meilleure option pour sa fonction réseau et son cas d’usage.

Héritage.

  • Nécessite que l'éditeur paramètre correctement registryUrl et imagePullSecrets dans les valeurs de helm et les modèles de déploiement pour la substitution.
  • Les images sont hébergées dans l’éditeur Azure Container Registry (ACR).

InjectArtifactStoreDetail.

  • Utilise un webhook pour injecter registryUrl &imagePullSecrets directement dans les opérations de pod, avec des dépendances minimales sur helm.
  • Les images sont toujours hébergées dans l’éditeur ACR.

Registre de clusters.

  • Utilise un webhook pour injecter registryUrl &imagePullSecrets directement dans les opérations de pod, sans dépendance sur helm.
  • Les images sont hébergées dans le registre de cluster d’extension NFO local.

Remarque

Dans les trois cas, AOSM remplace les valeurs AOSM pour les valeurs qu’un éditeur expose dans les modèles. La seule différence est la méthode de substitution.

Exigences Legacy pour registryUrl et imagePullSecrets

Azure Operator Service Manager (AOSM) utilise le service Network Function Manager (NFM) pour déployer des fonctions réseau conteneurisées (CNF). Avec la méthode héritée, NFM remplace les valeurs AOSM container registryUrl et imagePullSecrets dans l’opération helm pendant le déploiement de la fonction réseau (NF).

Utilisation de la méthode héritée

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: “”

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.

Autres considérations relatives à la méthode Héritée

Publisher doit prendre en compte les recommandations suivantes lors de l’utilisation de la méthode héritée :

  • Éviter des références à un registre externe
  • Validation manuelle des performances
  • Vérifier le référentiel d’images statiques et les balises

É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.

Effectuer des 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>

Vérifier le référentiel d’images statiques et les balises

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 de conformité aux packages Helm. Avec injectArtifactStoreDetails activé, une méthode de webhook est utilisée pour injecter dynamiquement les registryUrl et imagePullSecrets appropriés pendant les opérations de pod. Cela remplace les valeurs qui sont configurées dans le package Helm.

Utilisation de la méthode injectArtifactStoreDetails

Pour activer injectArtifactStoreDetails, définissez le paramètre installOptions dans la section nF resource roleOverrides sur true, comme illustré dans l’exemple suivant.

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

Remarque

Le package de graphique Helm doit toujours exposer des valeurs registryURL et imagePullSecrets correctement mises en forme.

Exigences de Registre de cluster pour registryUrl et imagePullSecrets

Pour plus d’informations sur l’utilisation du Registre de clusters, consultez la documentation concept.

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