Referência de configuração do cluster do Kubernetes para o Azure Machine Learning

  • Artigo

Este artigo contém informações de referência para configurar o Kubernetes com o Azure Machine Learning.

Versão e região compatíveis do Kubernetes

  • Os clusters do Kubernetes que instalam a extensão do Azure Machine Learning têm uma janela de suporte de versão igual a "N-2", que está alinhada com a política de suporte de versão do AKS (Serviço de Kubernetes do Azure), em que "N" é a última versão secundária de GA do Serviço de Kubernetes do Azure.

    • Por exemplo, se o AKS introduzir a 1.20.a hoje, as versões 1.20.a, 1.20.b, 1.19.c, 1.19.d, 1.18.e e 1.18.f serão compatíveis.

    • Se os clientes estiverem executando uma versão do Kubernetes sem suporte, eles precisarão atualizá-la ao solicitar o suporte para o cluster. Os clusters que executam as versões sem suporte do Kubernetes não são cobertos pelas políticas de suporte de extensão do Azure Machine Learning.

  • Disponibilidade da região da extensão do Azure Machine Learning:

Quando você implantar a extensão do Azure Machine Learning, alguns serviços relacionados serão implantados no cluster do Kubernetes para o Azure Machine Learning. A tabela a seguir lista os Serviços Relacionados e seu uso de recursos no cluster:

Deploy/Daemonset Réplica # Treinamento Inferência Solicitação de CPU (m) Limite da CPU (m) Solicitação de memória (Mi) Limite de memória (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 2.048
fluent-bit 1 por nó ✓ ✓ 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 fins de teste)
ou
3 (para fins de produção)		 ✓ N/D 900 2000 800 1200
online-deployment 1 por implantação User-created N/D <user-define> <user-define> <user-define> <user-define>
online-deployment/identity-sidecar 1 por implantação ✓ 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

Excluindo as implantações/pods do usuário, os requisitos mínimos totais de recursos do sistema são os seguintes:

Cenário Inferência habilitada Treinamento habilitado Solicitação de CPU (m) Limite da CPU (m) Solicitação de memória (Mi) Limite de memória (Mi) Contagem de nós Tamanho mínimo de VM recomendado SKU de VM do AKS correspondente
Para teste ✓ N/D 1780 8300 2440 12296 1 Nó 2 vCPU, 7 GiB Memory, 6400 IOPS, 1500Mbps BW DS2v2
Para teste N/D ✓ 410 4420 1492 10960 1 Nó 2 vCPU, 7 GiB Memory, 6400 IOPS, 1500Mbps BW DS2v2
Para teste ✓ ✓ 1910 10420 2884 15744 1 Nó 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS3v2
Para produção ✓ N/D 3600 12700 4240 15296 3 nó(s) 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS3v2
Para produção N/D ✓ 410 4420 1492 10960 1 nó(s) 8 vCPU, 28GiB Memroy, 25600 IOPs, 6000Mbps BW DS4v2
Para produção ✓ ✓ 3730 14820 4684 18744 3 nó(s) 4 vCPU, 14 GiB Memory, 12800 IOPS, 1500Mbps BW DS4v2

Observação

  • Para fins de teste, você deve consultar a solicitação de recursos.
  • Para fins de produção, você deve se consultar o limite de recursos.

Importante

Seguem outras considerações para consulta:

  • Para maior largura de banda de rede e melhor desempenho de E/S de disco, recomendamos uma SKU maior.
    • Tome DV2/DSv2 como exemplo. Usar uma SKU grande pode reduzir o tempo de pull da imagem para melhorar o desempenho de rede/armazenamento.
    • Mais informações sobre a reserva do AKS podem ser encontradas na reserva do AKS.
  • Se você estiver usando o cluster do AKS, talvez seja necessário considerar o limite de tamanho em uma imagem de contêiner no AKS. Mais informações podem ser encontradas em Limite de tamanho da imagem de contêiner do AKS.

Pré-requisitos para clusters ARO ou OCP

Desabilitar o SELinux (Security Enhanced Linux)

Em computadores com o SELinux habilitado, não há suporte para o conjunto de dados do Azure Machine Learning (um recurso do SDK v1 usado em trabalhos de treinamento do Azure Machine Learning). Portanto, você precisa desabilitar o selinux em todos os trabalhos para usar o conjunto de dados do Azure Machine Learning.

Configuração privilegiada para ARO e OCP

Para a implantação de extensão do Azure Machine Learning no cluster ARO ou OCP, permita acesso privilegiado às contas de serviço do Azure Machine Learning, execute o comando oc edit scc privileged e adicione as seguintes contas de serviço em "usuários:":

  • 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

Observação

  • {EXTENSION-NAME}: é o nome da extensão especificado com o comando az k8s-extension create --name da CLI.
  • {KUBERNETES-COMPUTE-NAMESPACE}: é o namespace da computação do Kubernetes especificado quando a computação é anexada ao workspace do Azure Machine Learning. Ignore a configuração de system:serviceaccount:{KUBERNETES-COMPUTE-NAMESPACE}:default se KUBERNETES-COMPUTE-NAMESPACE for default.

Detalhes do log coletado

Alguns logs sobre cargas de trabalho do Azure Machine Learning no cluster serão coletados por meio de componentes de extensão, como status, métricas, ciclo de vida etc. A lista a seguir mostra todos os detalhes do log coletados, incluindo o tipo dos logs coletados e para onde eles foram enviados ou armazenados.

Pod Descrição do recurso Informações de log detalhadas
amlarc-identity-controller Solicite e renova o token do Registro de Contêiner do Azure/Blobs do Azure por meio de identidade gerenciada. Usado somente quando enableInference=true é definido ao instalar a extensão. Ele tem logs de rastreamento que mostram o status da obtenção de identidade para os pontos de extremidade se autenticarem no serviço do Azure Machine Learning.
amlarc-identity-proxy Solicite e renova o token do Registro de Contêiner do Azure/Blobs do Azure por meio de identidade gerenciada. Usado somente quando enableInference=true é definido ao instalar a extensão. Ele tem logs de rastreamento que mostram o status da obtenção de identidade para o cluster se autenticar no serviço do Azure Machine Learning.
aml-operator Gerencie o ciclo de vida dos trabalhos de treinamento. Os logs contêm o status do pod do trabalho de treinamento do Azure Machine Learning no cluster.
azureml-fe-v2 O componente de front-end que roteia as solicitações de inferência de entrada para serviços implantados. Logs de acesso no nível da solicitação, incluindo ID da solicitação, hora de início, código de resposta, detalhes do erro e durações da latência da solicitação. Logs de rastreamento de alterações nos metadados do serviço, o serviço íntegro de execução do serviço e outros para fins de depuração.
gateway O gateway é usado para se comunicar e enviar dados bidirecionalmente. Rastreia logs em solicitações de serviços do Azure Machine Learning para os clusters.
healthcheck -- Os logs contêm o status do recurso de namespace azureml (extensão do Azure Machine Learning) para diagnosticar o que está tornando a extensão não funcional.
inference-operator-controller-manager Gerencie o ciclo de vida dos pontos de extremidade de inferência. Os logs contêm o ponto de extremidade de inferência do Azure Machine Learning e o status do pod de implantação no cluster.
metrics-controller-manager Gerenciar a configuração do Prometheus. Logs de rastreamento do status de upload de métricas de implantação de inferência e trabalho de treinamento sobre a utilização da CPU e a utilização da memória.
relay server O servidor de retransmissão só é necessário no cluster conectado ao Arc e não será instalado no cluster do AKS. O servidor de retransmissão funciona com a Retransmissão do Azure para se comunicar com os serviços de nuvem. Os logs contêm informações no nível da solicitação da Retransmissão do Azure.

Os trabalhos do Azure Machine Learning se conectam com o armazenamento de dados personalizado

PV (Volume Persistente) e PVC (Reivindicação de Volume Persistente) são conceitos do Kubernetes, permitindo que o usuário forneça e consuma vários recursos de armazenamento.

  1. Crie um PV, usando o NFS como exemplo:
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. Crie um PVC no mesmo namespace do Kubernetes com cargas de trabalho de ML. Em metadata, você precisa adicionar o rótulo ml.azure.com/pvc: "true" para ser reconhecido pelo Azure Machine Learning e adicionar a anotação ml.azure.com/mountpath: <mount path> para definir o caminho de montagem.
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

  • Somente o trabalho/componente de comando, o trabalho/componente do hyperdrive e a implantação em lote dão suporte ao armazenamento de dados personalizado de PVCs. > * O ponto de extremidade online em tempo real, o trabalho de AutoML e o trabalho PRS não dão suporte ao armazenamento de dados personalizado de PVCs.
  • Além disso, somente os pods do mesmo namespace do Kubernetes com os PVCs serão montados no volume. O cientista de dados pode acessar o mount path especificado na anotação de PVC do trabalho. O trabalho de AutoML e o trabalho de Prs não terão acesso aos PVCs.

Tolerâncias e taints do Azure Machine Learning com suporte

Taint e tolerância são conceitos do Kubernetes que funcionam juntos para garantir que os pods não sejam agendados em nós inadequados.

Os clusters do Kubernetes integrados ao Azure Machine Learning (incluindo clusters do AKS e do Arc Kubernetes) agora dão suporte a taints e tolerâncias específicos do Azure Machine Learning, permitindo que os usuários adicionem taints específicos do Azure Machine Learning em nós dedicados do Azure Machine Learning, para impedir que cargas de trabalho que não são do Azure Machine Learning sejam agendadas nesses nós dedicados.

Só damos suporte à colocação de taints específicos do amlarc em seus nós, que são definidos da seguinte maneira:

Taint Chave Valor Efeito Descrição
amlarc geral ml.azure.com/amlarc true NoSchedule, NoExecute ou PreferNoSchedule Todas as cargas de trabalho do Azure Machine Learning, incluindo pods de serviço do sistema de extensão e pods de carga de trabalho de aprendizado de máquina, tolerariam esse taint amlarc overall.
sistema do amlarc ml.azure.com/amlarc-system true NoSchedule, NoExecute ou PreferNoSchedule Somente os pods de serviços do sistema de extensão do Azure Machine Learning tolerariam esse taint amlarc system.
carga de trabalho do amlarc ml.azure.com/amlarc-workload true NoSchedule, NoExecute ou PreferNoSchedule Somente pods de carga de trabalho de aprendizado de máquina tolerariam esse taint amlarc workload.
grupo de recursos do amlarc ml.azure.com/resource-group <nome do grupo de recursos> NoSchedule, NoExecute ou PreferNoSchedule Somente os pods de carga de trabalho de aprendizado de máquina criados com base no grupo de recursos específico tolerariam esse taint amlarc resource group.
workspace do amlarc ml.azure.com/workspace <nome do workspace> NoSchedule, NoExecute ou PreferNoSchedule Somente os pods de carga de trabalho de aprendizado de máquina criados com base no workspace específico tolerariam esse taint amlarc workspace.
computação do amlarc ml.azure.com/compute <nome da computação> NoSchedule, NoExecute ou PreferNoSchedule Somente os pods de carga de trabalho de aprendizado de máquina criados com o destino de computação específico tolerariam esse taint amlarc compute.

Dica

  1. Para o AKS (Serviço de Kubernetes do Azure), você pode seguir o exemplo em Melhores práticas para recursos avançados do agendador no AKS (Serviço de Kubernetes do Azure) para aplicar taints a pools de nós.
  2. Para clusters do Kubernetes do Arc, como clusters do Kubernetes locais, você pode usar o comando kubectl taint para adicionar taints aos nós. Para obter mais exemplos, consulte a Documentação do Kubernetes.

Práticas recomendadas

De acordo com seus requisitos de agendamento dos nós dedicados do Azure Machine Learning, você pode adicionar vários taints específicos do amlarc para restringir quais cargas de trabalho do Azure Machine Learning podem ser executadas em nós. Listamos as práticas recomendadas para usar taints do amlarc:

  • Para impedir que as cargas de trabalho que são sejam do Azure Machine Learning sejam executadas em nós/pools de nós dedicados do Azure Machine Learning, basta adicionar o taint aml overall a esses nós.
  • Para impedir que pods que não sejam do sistema sejam executados em nós/pools de nós dedicados ao Azure Machine Learning, você precisa adicionar os seguintes taints:
    • Taint amlarc overall
    • Taint amlarc system
  • Para impedir que cargas de trabalho que não sejam do machine learning sejam executados em nós/pools de nós dedicados ao Azure Machine Learning, você precisa adicionar os seguintes taints:
    • Taint amlarc overall
    • Taint amlarc workloads
  • Para impedir que cargas de trabalho não criadas a partir do workspace X sejam executadas em nós/pools de nós dedicados ao Azure Machine Learning, você precisa adicionar os seguintes taints:
    • Taint amlarc overall
    • Taint amlarc resource group (has this <workspace X>)
    • Taint amlarc <workspace X>
  • Para impedir que cargas de trabalho não criadas pelo destino de computação X sejam executadas em nós/pools de nós dedicados ao Azure Machine Learning, você precisa adicionar os seguintes taints:
    • Taint amlarc overall
    • Taint amlarc resource group (has this <workspace X>)
    • Taint amlarc workspace (has this <compute X>)
    • Taint amlarc <compute X>

Integrar outro controlador de entrada com a extensão Azure Machine Learning por HTTP ou HTTPS

Além do balanceador de carga de inferência azureml-fe padrão do Azure Machine Learning, você também pode integrar outros balanceadores de carga à extensão do Azure Machine Learning por HTTP ou HTTPS.

Este tutorial ajuda a ilustrar como integrar o Nginx Ingress Controller ou o Gateway de Aplicativo do Azure.

Pré-requisitos

  • Implante a extensão do Azure Machine Learning com inferenceRouterServiceType=ClusterIP e allowInsecureConnections=True, para que o Nginx Ingress Controller possa gerenciar a terminação TLS sozinho só em vez de enviá-la ao azureml-fe quando o serviço for exposto por HTTPS.
  • Para fazer a integração com o Nginx Ingress Controller, você precisará de uma configuração de cluster do Kubernetes com o Nginx Ingress Controller.
  • Para fazer a integração com Gateway de Aplicativo do Azure, você precisará de uma configuração de cluster do Kubernetes com o controlador de entrada do Gateway de Aplicativo do Azure.
  • Se você quiser usar HTTPS neste aplicativo, será necessário um certificado x509 e a respectiva chave privada.

Expor serviços via HTTP

Para expor o azureml-fe, usaremos o seguinte 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

Essa entrada expõe o serviço azureml-fe e a implantação selecionada como um back-end padrão do Nginx Ingress Controller.

# 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

Essa entrada expõe o serviço azureml-fe e a implantação selecionada como um back-end padrão do Gateway de Aplicativo.

Salve o recurso de entrada acima como ing-azureml-fe.yaml.

  1. Implante ing-azureml-fe.yaml executando:

    kubectl apply -f ing-azureml-fe.yaml

  2. Verifique o status da implantação no log do controlador de entrada.

  3. Agora o aplicativo azureml-fe deve estar disponível. Você pode conferir isso acessando:

    • Nginx Ingress Controller: o endereço do balanceador de carga público do Nginx Ingress Controller
    • Gateway de Aplicativo do Azure: o endereço público do Gateway de Aplicativo.

  4. Criar um trabalho de inferência e invocá-lo.

    Observação

    Substitua o IP em scoring_uri pelo endereço público do balanceador de carga do Nginx Ingress Controller antes de fazer a invocação.

Expor serviços via HTTPS

  1. Antes de implantar a entrada, você precisa criar um segredo de Kubernetes para hospedar o certificado e a chave privada. Você pode criar um segredo de Kubernetes executando

    kubectl create secret tls <ingress-secret-name> -n azureml --key <path-to-key> --cert <path-to-cert>

  2. Defina a entrada a seguir. Na entrada, especifique o nome do segredo na seção 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

    Observação

    Substitua <domain> e <ingress-secret-name> no recurso de entrada acima pelo domínio que aponta para o balanceador de carga do Nginx Ingress Controller/Gateway de Aplicativo e o nome do segredo. Armazene o Recurso de Entrada acima em um nome de arquivo ing-azureml-fe-tls.yaml.

  3. Implantar o ing-azureml-fe-tls.yaml executando

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

  4. Verifique o status da implantação no log do controlador de entrada.

  5. Agora o aplicativo azureml-fe estará disponível em HTTPS. Você pode conferir isso verificando o endereço público do balanceador de carga do Nginx Ingress Controller.

  6. Criar um trabalho de inferência e invocá-lo.

    Observação

    Substitua o protocolo e o IP em scoring_uri por HTTP e domínio o apontando para o balanceador de carga do Nginx Ingress Controller ou do Gateway de Aplicativo antes da invocação.

Usar o modelo do ARM para implantar a extensão

A extensão no cluster gerenciado pode ser implantada com o modelo do ARM. Veja um modelo de exemplo no deployextension.json, com um arquivo de parâmetro de demonstração deployextension.parameters.json

Para usar o modelo de implantação de exemplo, edite o arquivo de parâmetro com o valor correto e execute o seguinte comando:

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

Veja mais informações de como usar o modelo do ARM na documentação de modelo do ARM

Nota de versão da extensão Azure ML

Observação

Novos recursos são lançados quinzenalmente.

Data Versão Descrição da versão
21 de novembro de 2023 1.1.39 Vulnerabilidades corrigidas. Mensagem de erro refinada. Maior estabilidade para a API do servidor de retransmissão.
1º de novembro de 2023 1.1.37 Atualize a versão do enviado do plano de dados.
11 de outubro de 2023 1.1.35 Corrigir imagem vulnerável. Correções de bugs.
25 de agosto de 2023 1.1.34 Corrigir imagem vulnerável. Retorne um erro de identidade mais detalhado. Correções de bugs.
18 de julho de 2023 1.1.29 Adicionar novos erros do operador de identidade. Correções de bugs.
4 de junho de 2023 1.1.28 Melhorar o dimensionador automático para lidar com vários pools de nós. Correções de bugs.
18 de abril de 2023 1.1.26 Correções de bugs e correções de vulnerabilidades.
27 de março de 2023 1.1.25 Adicione limitação de trabalho no Azure Machine Learning. Falha rápida para o trabalho de treinamento quando a instalação do SSH falhou. Reduzir o intervalo de extração do Prometheus para 30s. Aprimoramento das mensagens de erro de inferência. Corrigir imagem vulnerável.
7 de março de 2023 1.1.23 Alterar o tipo de instância padrão para usar a memória 2Gi. Atualizar as configurações de métricas para pontuação-FE que adicionam scrape_interval de 15s. Adicionar a especificação de recurso para sidecar MDC. Corrigir imagem vulnerável. Correções de bugs.
14 de fevereiro de 2023 1.1.21 Correções de bugs.
07 de fevereiro de 2023 1.1.19 Aprimoramento da mensagem de retorno de erro de inferência. Atualização do tipo de instância padrão para usar o limite de memória de 2 Gi. Verificação da integridade do cluster quanto à integridade do pod, à cota de recursos, à versão do Kubernetes e à versão da extensão. Correções de bug
27 de dezembro de 2022 1.1.17 Migração do Fluent-bit de DaemonSet para sidecars. Adição de suporte para o MDC. Refinamento das mensagens de erro. Suporte a trabalhos do modo de cluster (Windows, Linux). Correções de bug
29 de novembro de 2022 1.1.16 Adição da validação de tipo de instância por novo CRD. Tolerância de suporte. Encurtamento do nome do SVC. Hora principal da carga de trabalho. Correções de bugs e aprimoramentos gerais.
Setembro de 13, 2022 1.1.10 Correções de bug.
29 de agosto de 2022 1.1.9 Lógica de verificação de integridade aprimorada. Correções de bug.
23 de junho de 2022 1.1.6 Correções de bug.
15 de junho de 2022 1.1.5 Treinamento atualizado para usar o novo runtime comum para executar trabalhos. Foi removido o uso da Retransmissão do Azure para a extensão do AKS. Foi removido o uso do barramento de serviço da extensão. Uso atualizado do contexto de segurança. Inferência de azureml-fe atualizada para v2. Atualizado para usar o Volcano como agendador de trabalho de treinamento. Correções de bug.
14 de outubro de 2021 1.0.37 Suporte à montagem de volume de PV/PVC no trabalho de treinamento AMLArc.
16 de setembro de 2021 1.0.29 Novas regiões disponíveis, WestUS, CentralUS, NorthCentralUS, KoreaCentral. Capacidade de expansão da fila de trabalho. Confira os detalhes da fila de trabalho no Workspace do Azure Machine Learning Studio. Política de eliminação automática. Support max_run_duration_seconds in ScriptRunConfig. O sistema tenta cancelar automaticamente a execução se demorar mais do que o valor de configuração. Aprimoramento de desempenho no suporte ao dimensionamento automático de cluster. Implantação do agente do Arc e da extensão de ML do registro de contêiner local.
24 de agosto de 2021 1.0.28 O tipo de instância de computação tem suporte no YAML do trabalho. Atribuir Identidade Gerenciada à computação AMLArc.
10 de agosto de 2021 1.0.20 Novo suporte à distribuição do Kubernetes, K3S – Kubernetes leve. Implante a extensão do Azure Machine Learning no cluster do AKS sem se conectar por meio do AutoML (Machine Learning Automatizado) do Azure Arc com o SDK do Python. Use a CLI 2.0 para anexar o cluster do Kubernetes a um Workspace do Azure Machine Learning. Otimize a utilização de recursos de CPU/memória dos componentes da extensão do Azure Machine Learning.
2 de julho de 2021 1.0.13 Suporte a novas distribuições do Kubernetes, Kubernetes do OpenShift e GKE (Mecanismo de Kubernetes do Google). Suporte ao dimensionamento automático. Se o cluster do Kubernetes gerenciado pelo usuário habilitar o dimensionamento automático, o cluster será dimensionado ou automaticamente dimensionado de acordo com o volume de execuções e implantações ativas. Melhoria de desempenho no inicializador de trabalho, o que reduz muito o tempo de execução do trabalho.