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

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:

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

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

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.

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.

1. 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

2. 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

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:

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.

1. Implemente ing-azureml-fe.yaml mediante la ejecución de:

   kubectl apply -f ing-azureml-fe.yaml
   

2. Compruebe el registro del estado de implementación del controlador de entrada.

3. 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.

4. 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

1. 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>
   

2. 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.

3. Implemente ing-azureml-fe-tls.yaml mediante la ejecución de

   kubectl apply -f ing-azureml-fe-tls.yaml
   

4. Compruebe el registro del estado de implementación del controlador de entrada.

5. 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.

6. 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