Referencia para la configuración de un clúster de Kubernetes para Azure Machine Learning

Artículo
09/01/2024

Este artículo contiene información de referencia para configurar Kubernetes con Azure Machine Learning.

Versión y región de Kubernetes admitida

Los clústeres de Kubernetes que instalan la extensión de Azure Machine Learning tienen una ventana de compatibilidad de versión de "N-2", que está alineada con la directiva de compatibilidad con versiones de Azure Kubernetes Service (AKS), donde "N" es la versión secundaria de disponibilidad general más reciente de Azure Kubernetes Service.
- Por ejemplo, si AKS presenta la versión 1.20.a hoy, las versiones 1.20.a, 1.20.b, 1.19.c, 1.19.d, 1.18.e y 1.18.f son compatibles.
- Si los clientes ejecutan una versión incompatible de Kubernetes, se les pide que la actualicen al solicitar soporte técnico para el clúster. Los clústeres que ejecutan versiones de Kubernetes no admitidas no están cubiertos por las directivas de soporte técnico de la extensión de Azure Machine Learning.
Disponibilidad regional de la extensión de Azure Machine Learning:
- La extensión de Azure Machine Learning se puede implementar en AKS o en Kubernetes habilitado para Azure Arc en las regiones admitidas enumeradas en la Productos disponibles por región.

Planeamiento de recursos recomendado

Al implementar la extensión de Azure Machine Learning, se implementan algunos servicios relacionados en el clúster de Kubernetes para Azure Machine Learning. En la tabla siguiente se enumeran los servicios relacionados y su uso de recursos en el clúster:

Implementación/DaemonSet	Núm. de réplicas	Cursos	Inferencia	Solicitud de CPU (m)	Límite de CPU (m)	Solicitud de memoria (Mi)	Límite de memoria (Mi)
metrics-controller-manager	1	✓	✓	10	100	20	300
prometheus-operator	1	✓	✓	100	400	128	512
prometheus	1	✓	✓	100	1000	512	4096
kube-state-metrics	1	✓	✓	10	100	32	256
gateway	1	✓	✓	50	500	256	2048
fluent-bit	1 por nodo	✓	✓	10	200	100	300
inference-operator-controller-manager	1	✓	N/D	100	1000	128	1024
amlarc-identity-controller	1	✓	N/D	200	1000	200	1024
amlarc-identity-proxy	1	✓	N/D	200	1000	200	1024
azureml-ingress-nginx-controller	1	✓	N/D	100	1000	64	512
azureml-fe-v2	1 (para fines de prueba) o bien 3 (para fines de producción)	✓	N/D	900	2000	800	1200
online-deployment	1 por implementación	User-created	N/D	<user-define>	<user-define>	<user-define>	<user-define>
online-deployment/identity-sidecar	1 por implementación	✓	N/D	10	50	100	100
aml-operator	1	N/D	✓	20	1020	124	2168
volcano-admission	1	N/D	✓	10	100	64	256
volcano-controller	1	N/D	✓	50	500	128	512
volcano-schedular	1	N/D	✓	50	500	128	512

Si se excluyen sus propias implementaciones o pods, los requisitos mínimos totales de recursos del sistema son los siguientes:

Escenario	Inferencia habilitada	Entrenamiento habilitado	Solicitud de CPU (m)	Límite de CPU (m)	Solicitud de memoria (Mi)	Límite de memoria (Mi)	Número de nodos	Tamaño de máquina virtual mínimo recomendado	SKU de máquina virtual de AKS correspondiente
Para pruebas	✓	N/D	1780	8300	2440	12 296	1 nodo	2 vCPU, 7 GiB de memoria, 6400 IOPS, 1500 Mbps BW	DS2v2
Para pruebas	N/D	✓	410	4420	1492	10 960	1 nodo	2 vCPU, 7 GiB de memoria, 6400 IOPS, 1500 Mbps BW	DS2v2
Para pruebas	✓	✓	1910	10420	2884	15 744	1 nodo	4 vCPU, 14 GiB de memoria, 12800 IOPS, 1500 Mbps BW	DS3v2
Para producción	✓	N/D	3600	12 700	4240	15296	3 nodos	4 vCPU, 14 GiB de memoria, 12800 IOPS, 1500 Mbps BW	DS3v2
Para producción	N/D	✓	410	4420	1492	10 960	1 nodo	8 vCPU, 28 GiB de memoria, 25 600 IOPS, 6000 Mbps BW	DS4v2
Para producción	✓	✓	3730	14 820	4684	18 744	3 nodos	4 vCPU, 14 GiB de memoria, 12800 IOPS, 1500 Mbps BW	DS4v2

Nota

Con fines de prueba, debe hacer referencia a la solicitud de recursos.
Con fines de producción, debe hacer referencia al límite de recursos.

Importante

Estas son algunas otras consideraciones a modo de referencia:

Para un mayor ancho de banda de red y un mejor rendimiento de E/S de disco, se recomienda una SKU mayor.
- Tome DV2/DSv2 como ejemplo: el uso de la SKU grande puede reducir el tiempo de extracción de la imagen y mejorar el rendimiento de la red y el almacenamiento.
- Puede encontrar más información sobre la reserva de AKS en Reserva de AKS.
Si usa un clúster de AKS, debe tener en cuenta el límite de tamaño en una imagen de contenedor de AKS; puede encontrar más información en Límite de tamaño de imagen de contenedor de AKS.

Requisitos previos para clústeres de ARO o OCP

Deshabilitación de Security Enhanced Linux (SELinux)

El conjunto de datos de Azure Machine Learning (una característica del SDK v1 que se usa en trabajos de entrenamiento de Azure Machine Learning) no se admite en máquinas con SELinux habilitado. Por lo tanto, debe deshabilitar selinux en todos los roles de trabajo para poder usar el conjunto de datos de Azure Machine Learning.

Configuración con privilegios para ARO y OCP

Para la implementación de la extensión de Azure Machine Learning en un clúster de ARO u OCP, conceda acceso con privilegios a las cuentas de servicio de Azure Machine Learning, ejecute el comando oc edit scc privileged y agregue las siguientes cuentas de servicio en "users:":

system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
system:serviceaccount:azureml:{EXTENSION-NAME}-kube-state-metrics
system:serviceaccount:azureml:prom-admission
system:serviceaccount:azureml:default
system:serviceaccount:azureml:prom-operator
system:serviceaccount:azureml:load-amlarc-selinux-policy-sa
system:serviceaccount:azureml:azureml-fe-v2
system:serviceaccount:azureml:prom-prometheus
system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default
system:serviceaccount:azureml:azureml-ingress-nginx
system:serviceaccount:azureml:azureml-ingress-nginx-admission

Nota:

{EXTENSION-NAME} es el nombre de extensión especificado por el comando az k8s-extension create --name de la CLI.
{KUBERNETES-COMPUTE-NAMESPACE}: es el espacio de nombres del proceso de Kubernetes especificado al asociar el proceso al área de trabajo de Azure Machine Learning. Omita la system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default configuración si KUBERNETES-COMPUTE-NAMESPACE es default.

Detalles del registro recopilados

Se recopilarán algunos registros sobre las cargas de trabajo de Azure Machine Learning del clúster mediante los componentes de la extensión, como el estado, las métricas, el ciclo de vida, etc. En la lista siguiente, se muestran todos los detalles del registro recopilados, incluido el tipo de registros recopilados y dónde se enviaron o almacenaron.

Pod	Descripción del recurso	Información de registro detallada
amlarc-identity-controller	Solicitud y renovación del token de Blob de Azure/Azure Container Registry a través de la identidad administrada.	Solo se usa cuando `enableInference=true` se establece al instalar la extensión. Dispone de registros de seguimiento del estado de la obtención de identidad para que los puntos de conexión se autentiquen con Azure Machine Learning Service.
amlarc-identity-proxy	Solicitud y renovación del token de Blob de Azure/Azure Container Registry a través de la identidad administrada.	Solo se usa cuando `enableInference=true` se establece al instalar la extensión. Dispone de registros de seguimiento del estado de la obtención de identidad para que el clúster se autentique con Azure Machine Learning Service.
aml-operator	Administrar el ciclo de vida de los trabajos de entrenamiento.	Los registros contienen el estado del pod del trabajo de entrenamiento de Azure Machine Learning en el clúster.
azureml-fe-v2	Componente de front-end que enruta las solicitudes de inferencia entrantes a los servicios implementados.	Acceda a los registros en el nivel de solicitud, incluido el identificador de solicitud, la hora de inicio, el código de respuesta, los detalles de error y las duraciones de la latencia de solicitud. Registros de seguimiento de los cambios de metadatos del servicio, estado correcto del servicio, etc., con fines de depuración.
gateway	La puerta de enlace se utiliza para comunicarse y enviar datos hacia adelante y hacia atrás.	Registros de seguimiento de las solicitudes de los servicios de Azure Machine Learning a los clústeres.
healthcheck	--	Los registros contienen el estado del recurso de espacio de nombres `azureml` (extensión de Azure Machine Learning) para diagnosticar qué hace que la extensión no funcione.
inference-operator-controller-manager	Administrar el ciclo de vida de los puntos de conexión de inferencia.	Los registros contienen el punto de conexión de inferencia de Azure Machine Learning y el estado del pod de implementación del clúster.
metrics-controller-manager	Administra la configuración de Prometheus.	Registros de seguimiento del estado de carga del trabajo de entrenamiento y métricas de la implementación de inferencia sobre el uso de CPU y el uso de memoria.
relay server	Relayserver solo es necesario en el clúster conectado a Arc y no se instalará en el clúster de AKS.	El servidor de retransmisión funciona con Azure Relay para comunicarse con los servicios en la nube. Los registros contienen información en el nivel de solicitud de Azure Relay.

Conexión de los trabajos de Azure Machine Learning con el almacenamiento de datos personalizado

El volumen persistente (PV) y la notificación de volumen persistente (PVC) son conceptos de Kubernetes, que permiten al usuario proporcionar y consumir varios recursos de almacenamiento.

Creación de PV, tome NFS como ejemplo.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv 
spec:
  capacity:
    storage: 1Gi 
  accessModes:
    - ReadWriteMany 
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  nfs: 
    path: /share/nfs
    server: 20.98.110.84 
    readOnly: false

Cree PVC en el mismo espacio de nombres de Kubernetes con cargas de trabajo de ML. En metadata, debe agregar la etiqueta ml.azure.com/pvc: "true" para que Azure Machine Learning la reconozca y agregar la anotación ml.azure.com/mountpath: <mount path> para establecer la ruta de acceso de montaje.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc  
  namespace: default
  labels:
    ml.azure.com/pvc: "true"
  annotations:
    ml.azure.com/mountpath: "/mnt/nfs"
spec:
  storageClassName: ""
  accessModes:
  - ReadWriteMany      
  resources:
     requests:
       storage: 1Gi

Importante

Solo el trabajo o componente del comando, el trabajo o componente de Hyperdrive y la implementación por lotes admiten el almacenamiento de datos personalizado desde PVC(s). > * El punto de conexión en línea en tiempo real, el trabajo de AutoML y el trabajo PRS no admiten el almacenamiento de datos personalizado desde PVC(s).
Además, solo los pods en el mismo espacio de nombres Kubernetes con el PVC (s) se montará el volumen. El científico de datos puede acceder a la mount path especificada en la anotación PVC del trabajo. El trabajo de AutoML y el trabajo Prs no tendrán acceso a los PVC.

Tolerancias y defectos admitidos de Azure Machine Learning

Intolerancia y tolerancia son conceptos de Kubernetes que funcionan conjuntamente para garantizar que los pods no estén programados en nodos inadecuados.

Los clústeres de Kubernetes integrados con Azure Machine Learning (incluidos AKS y los clústeres de Kubernetes habilitados para Arc) ahora admiten tolerancias y defectos específicos de Azure Machine Learning, lo que permite a los usuarios agregar defectos específicos de Azure Machine Learning en los nodos dedicados a Azure Machine Learning, para evitar que se programen cargas de trabajo que no sean de Azure Machine Learning en estos nodos dedicados.

Solo se admite la colocación de intolerancias específicas de amlarc en los nodos y se definen de la siguiente manera:

Intolerancia	Clave	Value	Efecto	Descripción
amlarc overall	ml.azure.com/amlarc	true	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Todas las cargas de trabajo de Azure Machine Learning, incluidos los pods del servicio del sistema de extensión y los pods de carga de trabajo de aprendizaje automático tolerarán esta intolerancia `amlarc overall`.
amlarc system	ml.azure.com/amlarc-system	true	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Solo los pods de los servicios del sistema de extensión de Azure Machine Learning tolerarán esta intolerancia `amlarc system`.
amlarc workload	ml.azure.com/amlarc-workload	true	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Solo los pods de carga de trabajo de aprendizaje automático tolerarán esta intolerancia `amlarc workload`.
amlarc resource group	ml.azure.com/resource-group	<Nombre del grupo de recursos>	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Solo los pods de carga de trabajo de aprendizaje automático creados a partir del grupo de recursos específico tolerarán esta intolerancia `amlarc resource group`.
amlarc workspace	ml.azure.com/workspace	<nombre del área de trabajo>	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Solo los pods de carga de trabajo de aprendizaje automático creados a partir del área de trabajo específica tolerarán esta intolerancia `amlarc workspace`.
amlarc compute	ml.azure.com/compute	<nombre del proceso>	`NoSchedule`, `NoExecute` o `PreferNoSchedule`	Solo los pods de carga de trabajo de aprendizaje automático creados con el destino de proceso específico tolerarán esta intolerancia `amlarc compute`.

Sugerencia

Para Azure Kubernetes Service (AKS), puede seguir el ejemplo de Procedimientos recomendados para características avanzadas del programador en Azure Kubernetes Service (AKS) para aplicar intolerancias a grupos de nodos.
En el caso de los clústeres de Arc Kubernetes como, por ejemplo, los clústeres de Kubernetes locales, puede usar el comando kubectl taint para agregar intolerancias a los nodos. Para obtener más ejemplos, consulte la documentación de Kubernetes.

Procedimientos recomendados

Según los requisitos de programación de los nodos dedicados de Azure Machine Learning, puede agregar varias intolerancias específicas de amlarc para restringir qué cargas de trabajo de Azure Machine Learning se pueden ejecutar en los nodos. Enumeramos los procedimientos recomendados para usar intolerancias amlarc:

Para evitar que las cargas de trabajo que no sean de Azure Machine Learning se ejecuten en grupos de nodos o nodos dedicados de Azure Machine Learning, simplemente agregue la intolerancia aml overall a estos nodos.
Para evitar que los pods que no sean del sistema se ejecuten en grupos de nodos o nodos dedicados de Azure Machine Learning, tiene que agregar las siguientes intolerancias:
- Intolerancia amlarc overall
- Intolerancia amlarc system
Para evitar que las cargas de trabajo que no sean de ML se ejecuten en grupos de nodos o nodos dedicados de Azure Machine Learning, tiene que agregar las siguientes intolerancias:
- Intolerancia amlarc overall
- Intolerancia amlarc workloads
Para evitar que las cargas de trabajo creadas en el área de trabajo X se ejecuten en grupos de nodos o nodos dedicados de Azure Machine Learning, tiene que agregar las siguientes intolerancias:
- Intolerancia amlarc overall
- Intolerancia amlarc resource group (has this <workspace X>)
- Intolerancia amlarc <workspace X>
Para evitar que las cargas de trabajo creadas en el destino de proceso X se ejecuten en grupos de nodos o nodos dedicados de Azure Machine Learning, tiene que agregar las siguientes intolerancias:
- Intolerancia amlarc overall
- Intolerancia amlarc resource group (has this <workspace X>)
- Intolerancia amlarc workspace (has this <compute X>)
- Intolerancia amlarc <compute X>

Integración de otro controlador de entrada con la extensión de Azure Machine Learning mediante HTTP o HTTPS

Además del equilibrador de carga de inferencia de Azure Machine Learning predeterminado azureml-fe, también puede integrar otros equilibradores de carga con la extensión de Azure Machine Learning mediante HTTP o HTTPS.

En este tutorial se indica cómo integrar el controlador de entrada Nginx o la instancia de Azure Application Gateway.

Prerrequisitos

Implemente la extensión de Azure Machine Learning con inferenceRouterServiceType=ClusterIP y allowInsecureConnections=True para que el controlador de entrada Nginx pueda controlar la terminación TLS por sí mismo en lugar de entregarla a azureml-fe cuando el servicio se expone mediante HTTPS.
Para la integración con el controlador de entrada Nginx, necesita una configuración de clúster de Kubernetes con ese controlador.
- Cree un controlador básico: si empieza desde cero, consulte estas instrucciones.
Para la integración con Azure Application Gateway, necesita una configuración de clúster de Kubernetes con el controlador de entrada de Azure Application Gateway.
- Implementación greenfield: si va a empezar desde cero, consulte estas instrucciones.
- Implementación brownfield: si ya tiene un clúster de AKS y una instancia de Application Gateway, consulte estas instrucciones.
Si desea usar HTTPS en esta aplicación, necesita un certificado X509 y su clave privada.

Exponer servicios a través de HTTP

Para exponer azureml-fe, se usará el siguiente recurso de entrada:

# Nginx Ingress Controller example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

Esta entrada expone el servicio azureml-fe y la implementación seleccionada como back-end predeterminado del controlador de entrada Nginx.

# Azure Application Gateway example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: azure-application-gateway
  rules:
  - http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

Esta entrada expone el servicio azureml-fe y la implementación seleccionada como back-end predeterminado de la instancia de Application Gateway.

Guarde el recurso de entrada anterior como ing-azureml-fe.yaml.

Implemente ing-azureml-fe.yaml mediante la ejecución de:
```
kubectl apply -f ing-azureml-fe.yaml
```
Compruebe el registro del estado de implementación del controlador de entrada.
Ahora la aplicación azureml-fe debe estar disponible. Para comprobarlo, visite:
- Controlador de entrada Nginx: la dirección pública de LoadBalancer del controlador de entrada Nginx
- Azure Application Gateway: la dirección pública de la instancia de Application Gateway.
Cree un trabajo de inferencia e invoque.

Nota

Reemplace la dirección IP de scoring_uri por la dirección pública de LoadBalancer del controlador de entrada Nginx antes de realizar la invocación.

Exponer servicios a través de HTTPS

Antes de implementar la entrada, debe crear un secreto de Kubernetes para hospedar el certificado y la clave privada. Puede crear un secreto de Kubernetes mediante la ejecución de
```
kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>
```

Defina la siguiente entrada. En la entrada, especifique el nombre del secreto en la sección secretName.

# Nginx Ingress Controller example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - <domain>
    secretName: <ingress-secret-name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

# Azure Application Gateway example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: azureml-fe
  namespace: azureml
spec:
  ingressClassName: azure-application-gateway
  tls:
  - hosts:
    - <domain>
    secretName: <ingress-secret-name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /
        backend:
          service:
            name: azureml-fe
            port:
              number: 80
        pathType: Prefix

Nota

Reemplace <domain> y <ingress-secret-name> del recurso de entrada anterior por el dominio que apunta a LoadBalancer del controlador de entrada Nginx o instancia de Application Gateway y el nombre del secreto. Almacene el recurso de entrada anterior en un archivo bajo el nombre de ing-azureml-fe-tls.yaml.

Implemente ing-azureml-fe-tls.yaml mediante la ejecución de
```
kubectl apply -f ing-azureml-fe-tls.yaml
```
Compruebe el registro del estado de implementación del controlador de entrada.
Ahora, la aplicación azureml-fe está disponible en HTTPS. Para comprobarlo, visite la dirección pública de LoadBalancer del controlador de entrada Nginx.
Cree un trabajo de inferencia e invoque.

Nota

Reemplace el protocolo y la dirección IP de scoring_uri por https y el dominio que apunta a LoadBalancer del controlador de entrada Nginx o instancia de Application Gateway antes de realizar la invocación.

Uso de la plantilla de ARM para implementar la extensión

La extensión en un clúster administrado se puede implementar con la plantilla de ARM. Se puede encontrar una plantilla de ejemplo en deployextension.json, con un archivo de parámetros de demostración deployextension.parameters.json.

Para usar la plantilla de implementación de ejemplo, edite el archivo de parámetros con el valor correcto y ejecute el siguiente comando:

az deployment group create --name <ARM deployment name> --resource-group <resource group name> --template-file deployextension.json --parameters deployextension.parameters.json

Puede encontrar más información sobre cómo usar la plantilla de ARM en el documento de plantillas de ARM.

Nota de la versión de la extensión AzureML