Compartir a través de


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.

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.

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

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

Nota:

Las nuevas características se publican con una frecuencia quincenal.

Date Versión Descripción de la versión
26 de septiembre de 2024 1.1.64 Se han corregido vulnerabilidades.
21 de noviembre de 2023 1.1.39 Se han corregido vulnerabilidades. Mensaje de error refinado. Mayor estabilidad para la API relayserver.
1 de noviembre de 2023 1.1.37 Actualice la versión de envoy del plano de datos.
11 de octubre de 2023 1.1.35 Corrija la imagen vulnerable. Correcciones de errores.
25 de agosto de 2023 1.1.34 Corrija la imagen vulnerable. Se devuelven errores de identidad más detallados. Correcciones de errores.
18 de julio de 2023 1.1.29 Agregue nuevos errores de operador de identidad. Correcciones de errores.
4 de junio de 2023 1.1.28 Mejore el escalador automático para controlar varios grupos de nodos. Correcciones de errores.
18 de abril de 2023 1.1.26 Correcciones de errores y correcciones de vulnerabilidades.
27 de marzo de 2023 1.1.25 Se ha agregado la limitación de trabajos de Azure Machine Learning. Error rápido para el trabajo de entrenamiento cuando se produjo un error en la configuración de SSH. Reduzca el intervalo de extracción de Prometheus a 30 s. Mejore los mensajes de error para la inferencia. Corrija la imagen vulnerable.
7 de marzo de 2023 1.1.23 Cambie el tipo de instancia predeterminado para que use la memoria 2Gi. Actualice las configuraciones de métricas para scoring-fe que agregan 15 s de scrape_interval. Agregue la especificación de recursos para el sidecar mdc. Corrija la imagen vulnerable. Correcciones de errores.
14 de febrero de 2023 1.1.21 Correcciones de errores.
7 de febrero de 2023 1.1.19 Mejora del mensaje de devolución de errores para la inferencia. Actualización del tipo de instancia predeterminado para usar el límite de memoria de 2Gi. Comprobación del estado del clúster en cuanto al estado de los pods, la cuota de recursos, la versión de Kubernetes y la versión de la extensión. Corrección de errores
27 de diciembre de 2022 1.1.17 Se ha trasladado Fluent Bit de DaemonSet a sidecars. Se ha agregado compatibilidad con MDC. Se han refinado los mensajes de error. Compatibilidad con trabajos del modo de clúster (Windows, Linux). Corrección de errores
29 de noviembre de 2022 1.1.16 Se ha agregado la validación del tipo de instancia mediante una nueva CRD. Se ha agregado compatibilidad con la tolerancia. Se ha acortado el nombre de SVC. Hora principal de la carga de trabajo. Mejoras y correcciones de varios errores.
13 de septiembre, 2022 1.1.10 Correcciones de errores.
29 de agosto de 2022 1.1.9 Se ha mejorado la lógica de comprobación de estado. Correcciones de errores.
23 de junio de 2022 1.1.6 Correcciones de errores.
15 de junio de 2022 1.1.5 Se ha actualizado el entrenamiento para que use el nuevo entorno de ejecución común para ejecutar trabajos. Se ha eliminado el uso de Azure Relay para la extensión de AKS. Se ha eliminado el uso de Service Bus de la extensión. Se ha actualizado el uso del contexto de seguridad. Se ha actualizado la inferencia azureml-fe a v2. Se ha actualizado para usar Volcano como programador de trabajos de entrenamiento. Correcciones de errores.
14 de octubre de 2021 1.0.37 Compatibilidad con montaje de volúmenes PV/PVC en el trabajo de entrenamiento de AMLArc.
16 de septiembre de 2021 1.0.29 Nuevas regiones disponibles, WestUS, CentralUS, NorthCentralUS, KoreaCentral. Capacidad de expansión de la cola de trabajos. Consulte los detalles de la cola de trabajos en el Estudio del área de trabajo de Azure Machine Learning. Directiva de eliminación automática. Compatibilidad con max_run_duration_seconds en ScriptRunConfig. El sistema intenta cancelar automáticamente la ejecución si tardó más que el valor configurado. Se ha mejorado el rendimiento en la compatibilidad con el escalado automático de clústeres. Implementación de agente de Arc y extensión de ML desde el registro de contenedor local.
24 de agosto de 2021 1.0.28 El tipo de instancia de proceso se admite en el trabajo YAML. Asigne la identidad administrada al proceso de AMLArc.
10 de agosto de 2021 1.0.20 Nueva compatibilidad con la distribución de Kubernetes, K3S: distribución ligera de Kubernetes. Implemente la extensión de Azure Machine Learning en el clúster de AKS sin conectarse mediante Azure Arc. Aprendizaje automático automatizado (AutoML) mediante el SDK de Python. Utilice la versión 2.0 de la CLI para conectar el clúster de Kubernetes a un área de trabajo de Azure Machine Learning. Optimice el uso de recursos de CPU y memoria de los componentes de la extensión de Azure Machine Learning.
2 de julio de 2021 1.0.13 Nueva compatibilidad con distribuciones de Kubernetes, OpenShift Kubernetes y GKE (Google Kubernetes Engine). Compatible con escalado automático. Si el clúster de Kubernetes administrado por el usuario habilita la escalabilidad automática, el clúster se escalará o reducirá horizontalmente de forma automática según el volumen de ejecuciones e implementaciones activas. Mejora del rendimiento en el iniciador de trabajos, lo que reduce en gran medida el tiempo de ejecución del trabajo.