Condividi tramite

Panoramica dei requisiti Helm

  • Articolo

Helm è una gestione pacchetti per Kubernetes che consente di semplificare la gestione del ciclo di vita delle applicazioni. I pacchetti Helm sono denominati grafici e sono costituiti da file di configurazione e modello YAML. Al momento dell'esecuzione di un'operazione Helm, i grafici vengono visualizzati nei file manifesto di Kubernetes per attivare l'azione appropriata del ciclo di vita dell'applicazione. Per un'integrazione più efficiente con Azure Operator Service Manager (AOSM), l'editore deve prendere in considerazione alcune considerazioni sulle procedure consigliate per lo sviluppo di grafici Helm.

Considerazioni su registryUrl e imagePullSecrets

Ogni grafico Helm richiede in genere un registryUrl e imagePullSecrets. In genere, un server di pubblicazione espone questi parametri nel file values.yaml. Inizialmente, AOSM dipende dall'editore che espone questi valori in modo rigoroso, quindi potrebbe essere sostituito con i valori di Azure appropriati durante la distribuzione. Nel tempo, non tutti gli editori potrebbero facilmente rispettare la gestione rigorosa di questi valori richiesti da AOSM.

  • Alcuni grafici nascondono registryUrl e/o imagePullSecrets dietro le istruzioni condizionali o altre restrizioni di valori, che non sono sempre state soddisfatte.
  • Alcuni grafici non dichiarano registryUrl e/o imagePullSecrets come stringa denominata prevista, ma come matrice.

Per ridurre i requisiti di conformità rigorosi per gli editori, AOSM in seguito ha introdotto due metodi migliorati per la gestione di questi valori. Innanzitutto injectArtifactStoreDetail e infine registro cluster. Questi due metodi più recenti non dipendono da registryUrl o imagePullSecret validi visualizzati nel pacchetto Helm. Questi metodi inseriscono invece questi valori direttamente nelle operazioni dei pod, per conto della funzione di rete.

Riepilogo dei metodi per registryUrl e imagePullSecrets

Tutti e tre i metodi sono supportati e descritti in questo articolo. Un editore deve scegliere l'opzione migliore per la funzione di rete e il caso d'uso.

Eredità.

  • Richiede all'editore di parametrizzare in modo conforme registryUrl & imagePullSecrets nei valori Helm e nei modelli di distribuzione per la sostituzione.
  • Le immagini sono ospitate nel Registro Azure Container del server di pubblicazione.

InjectArtifactStoreDetail.

  • Usa un webhook per inserire registryUrl & imagePullSecrets direttamente nelle operazioni dei pod, con dipendenze minime da helm.
  • Le immagini sono ancora ospitate nel Registro Azure Container dell'editore.

Registro cluster.

  • Usa un webhook per inserire registryUrl & imagePullSecrets direttamente nelle operazioni dei pod, senza alcuna dipendenza da helm.
  • Le immagini sono ospitate nel registro del cluster di estensione NFO locale.

Nota

In tutti e tre i casi, AOSM sostituisce i valori di AOSM per qualsiasi valore esposto da un editore nei modelli. L'unica differenza è il metodo per la sostituzione.

Requisiti legacy per registryUrl e imagePullSecrets

Azure Operator Service Manager (AOSM) usa il servizio NFM (Network Function Manager) per distribuire funzioni di rete incluse in contenitori. Con il metodo legacy, NFM sostituisce i valori registro contenitori AOSMUrl e imagePullSecrets nell'operazione helm durante la distribuzione della funzione di rete .

Uso del metodo legacy

Il modello di distribuzione Helm seguente mostra un esempio di come un server di pubblicazione deve esporre registryPath e imagePullSecrets per la compatibilità con l'approccio legacy 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

Il file seguente values.schema.json mostra un esempio di come un server di pubblicazione possa impostare facilmente i requisiti registryPath e imagePullSecretsvalue per la compatibilità con l'approccio legacy 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" ], 
      } 
   } 
}

Di seguito NFDVersion request payload viene illustrato un esempio di come un server di pubblicazione può fornire i valori registryPath e imagePullSecretsvalue per la compatibilità con l'approccio legacy AOSM.

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

Di seguito values.yaml viene illustrato un esempio di come un server di pubblicazione può fornire i valori registryPath e imagePullSecretsvalue per la compatibilità con l'approccio legacy AOSM.

global: 
   imagePullSecrets: [] 
   registryPath: “”

Nota

  • RegistryPath viene impostato senza alcun prefisso, https:// ad esempio o oci://. Se necessario, il server di pubblicazione deve definire un prefisso nel pacchetto helm.
  • imagePullSecrets e registryPath devono essere forniti nel passaggio di onboarding create NFDVersion.

Altre considerazioni con il metodo Legacy

Quando si usa il metodo legacy, è consigliabile prendere in considerazione anche i suggerimenti seguenti:

  • Evitare riferimenti al Registro di sistema esterno
  • Eseguire convalide manuali
  • Assicurarsi che repository e tag di immagini statici

Evitare riferimenti al Registro di sistema esterno

Gli utenti devono evitare di usare riferimenti a un registro esterno. Ad esempio, se deployment.yaml usa un percorso del Registro di sistema hardcoded o un registro di sistema esterno fa riferimento a un errore di convalida.

Eseguire convalide manuali

Esaminare le immagini e le specifiche del contenitore create per assicurarsi che le immagini abbiano il prefisso registryURL e che imagePullSecrets siano popolati con secretName.

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

OPPURE

 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>

Assicurarsi che repository e tag di immagini statici

Ogni grafico Helm deve contenere tag e repository di immagini statiche. I valori statici vengono impostati come segue:

  • Impostarli nella riga dell'immagine o,
  • Impostarli in values.yaml e non esporre questi valori nella versione NFDV (Network Function Design Version).

Una versione NFDV (Network Function Design Version) deve essere mappata a un set statico di grafici helm e immagini. I grafici e le immagini vengono aggiornati solo pubblicando una nuova versione NFDV (Network Function Design Version).

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

O

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

requisiti injectArtifactStoreDetails per registryUrl e imagePullSecrets

In alcuni casi, i grafici Helm di terze parti potrebbero non essere completamente conformi ai requisiti di AOSM per RegistryURL. In questo caso, è possibile usare la funzionalità injectArtifactStoreDetails per evitare di apportare modifiche alla conformità ai pacchetti Helm. Con injectArtifactStoreDetails abilitato, viene usato un metodo webhook per inserire il registryUrl e imagePullSecrets in modo dinamico durante le operazioni del pod. In questo modo vengono ignorati i valori configurati nel pacchetto Helm.

Uso del metodo injectArtifactStoreDetails

Per abilitare injectArtifactStoreDetails, impostare il parametro installOptions nella sezione ruolo risorsa NFOverrides su true, come illustrato nell'esempio seguente.

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

Nota

Il pacchetto del grafico Helm deve comunque esporre valori registryURL e imagePullSecrets formattati correttamente.

Requisiti del Registro di sistema del cluster per registryUrl e imagePullSecrets

Per informazioni sull'uso del registro cluster, vedere la documentazione sul concetto.

Restrizioni di immutabilità del grafico

Le restrizioni di immutabilità impediscono modifiche a un file o a una directory. Ad esempio, non è possibile modificare o rinominare un file non modificabile. Gli utenti devono evitare di usare tag modificabili, ad esempio latest, dev o stable. Ad esempio, se deployment.yaml usa 'latest' per . Values.image.tag la distribuzione avrà esito negativo.

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

Dichiarazione CRD grafico e suddivisione dell'utilizzo

È consigliabile suddividere la dichiarazione e l'utilizzo delle definizioni delle risorse dei clienti (CRD) in grafici Helm separati per supportare gli aggiornamenti. Per informazioni dettagliate, vedere: method-2-separate-charts