Översikt över Helm-krav

Helm är en pakethanterare för Kubernetes som hjälper till att förenkla programlivscykelhanteringen. Helm-paket kallas diagram och består av YAML-konfigurations- och mallfiler. Vid körning av en Helm-åtgärd renderas diagrammen i Kubernetes-manifestfiler för att utlösa lämplig programlivscykelåtgärd. För den mest effektiva integreringen med Azure Operator Service Manager (AOSM) bör utgivare överväga vissa överväganden för bästa praxis när de utvecklar Helm-diagram.

Överväganden för registryUrl och imagePullSecrets

Varje Helm-diagram kräver vanligtvis en registryUrl och imagePullSecrets. Oftast exponerar en utgivare dessa parametrar i values.yaml. Först var AOSM beroende av att utgivaren exponerade dessa värden på ett strikt sätt, så att de kunde ersättas med rätt Azure-värden under distributionen. Övertid kan inte alla utgivare enkelt följa den strikta hanteringen av dessa värden som krävs av AOSM.

• Vissa diagram döljer registryUrl och/eller imagePullSecrets bakom villkor eller andra värdebegränsningar som inte alltid har uppfyllts.
• Vissa diagram deklarerar inte registryUrl och/eller imagePullSecrets som den förväntade namngivna strängen, i stället som en matris.

För att minska de strikta efterlevnadskraven för utgivare introducerade AOSM senare två förbättrade metoder för att hantera dessa värden. Först injectArtifactStoreDetail och slutligen Klusterregister. Dessa två nyare metoder är inte beroende av giltiga registryUrl eller imagePullSecrets som visas i Helm-paketet. I stället matar dessa metoder in dessa värden direkt i poddåtgärder för nätverksfunktionens räkning.

Metodsammanfattning för registryUrl och imagePullSecrets

Alla tre metoderna stöds och beskrivs i den här artikeln. En utgivare bör välja det bästa alternativet för sin nätverksfunktion och användningsfall.

Legat.

• Kräver att utgivaren parameteriserar registryUrl och imagePullSecrets i helm-värden och distributionsmallar för ersättning.
• Avbildningar finns i utgivaren Azure Container Registry (ACR).

InjectArtifactStoreDetail.

• Använder en webhook för att mata in registryUrl & imagePullSecrets direkt i poddåtgärder, med minimala beroenden vid helm.
• Bilder finns fortfarande i utgivaren ACR.

Klusterregister.

• Använder en webhook för att mata in registryUrl & imagePullSecrets direkt i poddåtgärder, utan beroende av helm.
• Avbildningar finns i det lokala NFO-tilläggsklusterregistret.

Äldre krav för registryUrl och imagePullSecrets

Azure Operator Service Manager (AOSM) använder NFM-tjänsten (Network Function Manager) för att distribuera Containerized Network Functions (CNFs). Med den äldre metoden ersätter NFM AOSM-containerregistretUrl- och imagePullSecrets-värdena i helm-åtgärden under NF-distributionen (Network Function).

Använda äldre metod

Följande helm-distributionsmall visar ett exempel på hur en utgivare ska exponera registryPath och imagePullSecrets för kompatibilitet med en äldre AOSM-metod.

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 

Följande values.schema.json fil visar ett exempel på hur en utgivare enkelt kan ställa in registryPath- och imagePullSecretsvalue-krav för kompatibilitet med en äldre AOSM-metod.

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

Följande NFDVersion request payload visar ett exempel på hur en utgivare kan tillhandahålla registerPath- och imagePullSecretsvalue-värdena för kompatibilitet med en äldre AOSM-metod.

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

Följande values.yaml visar ett exempel på hur en utgivare kan tillhandahålla registerPath- och imagePullSecretsvalue-värdena för kompatibilitet med en äldre AOSM-metod.

global: 
   imagePullSecrets: [] 
   registryPath: “” 

Andra överväganden med äldre metod

Dessutom bör du överväga följande rekommendationer när du använder den äldre metoden:

• Undvik referenser till det externa registret
• Utföra en manuell validering
• Kontrollera lagringsplatsen och taggarna för statiska avbildningar

Undvik referenser till det externa registret

Användarna bör undvika att använda referenser till ett externt register. Om deployment.yaml till exempel använder en hårdkodad registersökväg eller externa registerreferenser misslyckas verifieringen.

Utföra manuella valideringar

Granska de avbildningar och containerspecifikationer som skapats för att säkerställa att avbildningarna har prefixet registryURL och att imagePullSecrets fylls med secretName.

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

ELLER

 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>

Kontrollera lagringsplatsen och taggarna för statiska avbildningar

Varje helm-diagram ska innehålla lagringsplats och taggar för statiska avbildningar. De statiska värdena anges på följande sätt:

• Ange dem på bildraden eller,
• Ange dem i values.yaml och exponera inte dessa värden i NFDV (Network Function Design Version).

En NFDV (Network Function Design Version) ska mappas till en statisk uppsättning helm-diagram och bilder. Diagrammen och bilderna uppdateras bara genom att publicera en ny NFDV (Network Function Design Version).

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

Eller

 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 krav för registryUrl och imagePullSecrets

I vissa fall kanske helm-diagram från tredje part inte är helt kompatibla med AOSM-kraven för registryURL. I det här fallet kan funktionen injectArtifactStoreDetails användas för att undvika att göra ändringar i helm-paketens efterlevnad. När injectArtifactStoreDetails är aktiverat används en webhook-metod för att mata in rätt registryUrl och imagePullSecrets dynamiskt under poddåtgärderna. Detta åsidosätter de värden som har konfigurerats i helm-paketet.

Använda injectArtifactStoreDetails-metoden

Om du vill aktivera injectArtifactStoreDetails anger du parametern installOptions i avsnittet NF resource roleOverrides till true, enligt följande exempel.

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

Klusterregisterkrav för registryUrl och imagePullSecrets

Information om hur du använder klusterregister finns i konceptdokumentationen.

Begränsningar för diagram oföränderlighet

Oföränderlighetsbegränsningar förhindrar ändringar i en fil eller katalog. En oföränderlig fil kan till exempel inte ändras eller byta namn. Användare bör undvika att använda föränderliga taggar, till exempel senaste, utvecklingsbara eller stabila. Om deployment.yaml till exempel använde "senaste" för . Values.image.tag distributionen skulle misslyckas.

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

Crd-deklaration för diagram och användningsdelning

Vi rekommenderar att du delar upp deklarationen och användningen av kundresursdefinitioner (CRD) i separata helm-diagram för att stödja uppdateringar. Detaljerad information finns i: method-2-separate-charts