Compartir a través de

Información general sobre los requisitos de Helm

  • Artículo

Helm es un administrador de paquetes para Kubernetes que ayuda a simplificar la administración del ciclo de vida de las aplicaciones. Los paquetes de Helm se denominan "gráficos" y constan de archivos de plantilla y configuración de YAML. Tras la ejecución de una operación de Helm, los gráficos se representan en archivos de manifiesto de Kubernetes para desencadenar la acción adecuada del ciclo de vida de la aplicación. Para una integración más eficaz con Azure Operator Service Manager (AOSM), el publicador debe tener en cuenta ciertas consideraciones recomendadas al desarrollar gráficos de Helm.

Consideraciones para registryUrl e imagePullSecrets

Normalmente, todos los gráficos de Helm requieren registryUrl e imagePullSecrets. Normalmente, un publicador expone estos parámetros en values.yaml. Al principio, AOSM dependía del publicador que expone estos valores de forma estricta, por lo que podrían sustituirse por los valores de Azure adecuados durante la implementación. El tiempo extra, no todos los publicadores podrían cumplir fácilmente el control estricto de estos valores requeridos por AOSM.

  • Algunos gráficos ocultaban registryUrl o imagePullSecrets detrás de condicionales u otras restricciones de valores, que no siempre se cumplían.
  • Algunos gráficos no declaran registryUrl ni imagePullSecrets como una cadena con nombre (valor esperado), sino como una matriz.

Para reducir los requisitos de cumplimiento estrictos en los publicadores, AOSM introdujo más adelante dos métodos mejorados para controlar estos valores. Primero injectArtifactStoreDetail y, por último, ClusterRegistry. Estos dos métodos más recientes no dependen de los registrosUrl o imagePullSecrets válidos que aparecen en el paquete de Helm. En su lugar, estos métodos insertan estos valores directamente en operaciones de pod, en nombre de la función de red.

Resumen del método para registryUrl e imagePullSecrets

Los tres métodos se admiten y se describen en este artículo. Un publicador debe elegir la mejor opción para su función de red y caso de uso.

Heredado.

  • Requiere que el publicador parametrice de forma compatible el registryUrl e imagePullSecrets en valores de Helm y plantillas de implementación para la sustitución.
  • Las imágenes se hospedan en el publicador de Azure Container Registry (ACR).

InjectArtifactStoreDetail.

  • Usa un webhook para insertar registryUrl e imagePullSecrets directamente en operaciones de pod, con dependencias mínimas en Helm.
  • Las imágenes todavía se hospedan en el publicador ACR.

ClusterRegistry.

  • Use un webhook para insertar registryUrl & imagePullSecrets directamente en operaciones de pod, sin dependencia en Helm.
  • Las imágenes se hospedan en el registro de clúster de extensión NFO local.

Nota:

En los tres casos, AOSM sustituye los valores de AOSM por los valores que expone un publicador en las plantillas. La única diferencia es el método para la sustitución.

Requisitos heredados para registryUrl e imagePullSecrets

Azure Operator Service Manager (AOSM) usa el servicio Network Function Manager (NFM) para implementar funciones de red en contenedor (CNFs). Con el método heredado, NFM sustituye los valores registryUrl e imagePullSecrets del contenedor AOSM en la operación helm durante la implementación de la función de red (NF).

Uso del método heredado

En la siguiente plantilla de implementación de Helm, se muestra un ejemplo de cómo un publicador debe exponer registryPath e imagePullSecrets por motivos de compatibilidad con el enfoque heredado de 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

En el siguiente archivo values.schema.json, se muestra un ejemplo de cómo un publicador puede establecer fácilmente los requisitos registryPath e imagePullSecretsvalue para la compatibilidad con el enfoque heredado de 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" ], 
      } 
   } 
}

NFDVersion request payload muestra un ejemplo de cómo un publicador puede proporcionar los valores registryPath e imagePullSecretsvalue para la compatibilidad con el enfoque heredado de AOSM.

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

values.yaml muestra un ejemplo de cómo un publicador puede proporcionar los valores registryPath e imagePullSecretsvalue para la compatibilidad con el enfoque heredado de AOSM.

global: 
   imagePullSecrets: [] 
   registryPath: “”

Nota:

  • registryPath se establece sin ningún prefijo como https:// o oci://. Si es necesario, el publicador debe definir un prefijo en el paquete de Helm.
  • imagePullSecrets y registryPath deben proporcionarse en el paso de creación de la incorporación de NFDVersion.

Otras consideraciones con el método Heredado

Publisher debe tener en cuenta las siguientes recomendaciones al usar el método heredado:

  • Evitar referencias al registro externo
  • Realizar validaciones manuales
  • Asegurarse de que las etiquetas y el repositorio de imágenes estáticas

Evitar referencias al registro externo

Los usuarios deben evitar usar referencias a un registro externo. Por ejemplo, si deployment.yaml usa una ruta de acceso del registro codificada de forma rígida o hace referencia a un registro externo, se producirá un error en la validación.

Realizar validaciones de forma manual

Revise las imágenes y las especificaciones de contenedor creadas para asegurarse de que las imágenes tengan el prefijo registryURL y que los valores imagePullSecrets se rellenen con secretName.

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

O BIEN

 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>

Asegurarse de que las etiquetas y el repositorio de imágenes estáticas

Cada gráfico de Helm debe contener un repositorio de imágenes estático y etiquetas. Los valores estáticos se establecen de la siguiente manera:

  • Se establecen en la línea de imagen o
  • Se establecen en values.yaml y no se exponen estos valores en la versión del diseño de funciones de red (NFDV).

Una versión del diseño de funciones de red (NFDV) debe asignarse a un conjunto estático de gráficos e imágenes de Helm. Los gráficos e imágenes solo se actualizan al publicar una nueva versión del diseño de funciones de red (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}}

Requisitos de injectArtifactStoreDetails para registryUrl e imagePullSecrets

En algunos casos, es posible que los gráficos de Helm de terceros no cumplan totalmente los requisitos de AOSM para registryURL. En este caso, se puede usar la característica injectArtifactStoreDetails para evitar realizar cambios de cumplimiento en los paquetes de Helm. Con injectArtifactStoreDetails habilitado, se usa un método de webhook para insertar el registryUrl y imagePullSecrets adecuados dinámicamente durante las operaciones del pod. Esto invalida los valores configurados en el paquete de Helm.

Uso del método injectArtifactStoreDetails

Para habilitar injectArtifactStoreDetails, establezca el parámetro installOptions en la sección nf resource roleOverrides en true, como se muestra en el ejemplo siguiente.

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:

El paquete de gráficos de Helm todavía debe exponer valores registryURL e imagePullSecrets con formato correcto.

Requisitos del registro de clúster para registryUrl e imagePullSecrets

Para obtener información sobre el uso del registro de clústeres, consulte la documentación del concepto.

Restricciones de inmutabilidad del gráfico

Las restricciones de inmutabilidad impiden los cambios en un archivo o directorio. Por ejemplo, no se puede cambiar ni renombrar un archivo inmutable. Los usuarios deben evitar el uso de etiquetas mutables como "latest", "dev" o "stable". Por ejemplo, si deployment.yaml usó "latest" para .Values.image.tag, se produciría un error en la implementación.

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

División de uso y declaración de CRD de gráfico

Se recomienda dividir la declaración y el uso de definiciones de recursos de cliente (CRD) en gráficos de Helm independientes para admitir actualizaciones. Para obtener información detallada, consulte: method-2-separate-charts