Dela via

Översikt över Helm-krav

  • Artikel

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 ett deklarerat registerUrl och imagePullSecrets. Bästa praxis rekommenderar att utgivaren definierar dessa två parametrar konsekvent som variabler i values.yaml. Först var AOSM beroende av att utgivaren exponerade dessa värden på ett strikt sätt, så att de kunde matas in och sedan matas in under distributionen. Den här metoden kallas för den äldre metoden. Övertid, många komplikationer uppstod, eftersom inte alla utgivardiagram uppfyllde den strikta definitionen av registryUrl och imagePullSecrets 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 för registryUrl och imagePullSecrets 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 beror inte alls på registryUrl eller imagePullSecrets som visas i Helm-paketet. I stället härleds och matas dessa värden in för nätverksfunktionens räkning.

Metodsammanfattning för registryUrl och imagePullSecrets

Legat.

  • Obligatorisk utgivare för att parameterisera registryUrl & imagePullSecrets korrekt i helm-värden och mallar för ersättning.
  • Avbildningar som finns i utgivaren Azure Container Registry (ACR).

InjectArtifactStoreDetail.

  • Använder en webhook för att mata in registryUrl & imagePullSecrets direkt i podden utan något beroende av helm.
  • Bilder som fortfarande finns i utgivaren ACR.

Klusterregister.

  • Samma som InjectArtifactStoreDetail, förutom att avbildningarna nu finns i det lokala klusterregistret.

Kommentar

I alla tre fallen ersätter AOSM AOSM-härledda hemligheter med de hemligheter som en utgivare exponerar i mallar. Den enda skillnaden är Legacy och InjectArtifactStoreDetail, hemligheten är bunden till utgivaren ACR, medan hemligheten i Klusterregister är bunden till klusterregistret.

Ä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 Function (CNF). NFM matar in container registryUrl och imagePullSecrets dynamiskt i helm-värdena under NF-distributionen (Network Function). 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: “”
Namn Type Beskrivning
imagePullSecrets String imagePullSecrets är en matris med hemliga namn som används för att hämta containeravbildningar
registryPath String registryPath är AzureContainerRegistry serverplatsen

Kommentar

  • RegistryPath har angetts utan prefix som https:// eller oci://. Om det behövs måste utgivaren definiera ett prefix i helm-paketet.
  • imagePullSecrets och registryPath måste anges i registreringssteget skapa NFDVersion.

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.

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>

Lagringsplats och taggar för statisk avbildning

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-paket. Om du vill använda injectArtifactStoreDetails anger du parametern installOptions i avsnittet NF resource roleOverrides till true. Använd sedan det registerURL-värde som behövs i helm-diagrampaketet för att hålla register-URL:en giltig. Se följande exempel på parametern injectArtifactStoreDetails aktiverat.

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

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