Solução de problemas da extensão do Azure Machine Learning

Artigo
09/03/2024

Neste artigo, saiba como solucionar problemas comuns que você pode encontrar com a implantação da extensão do Azure Machine Learning no AKS ou no Kubernetes habilitado para Arc.

Como a extensão do Azure Machine Learning é instalada

A extensão do Azure Machine Learning é lançada como um gráfico do Helm e é instalada pelo Helm V3. Todos os componentes da extensão do Azure Machine Learning são instalados no namespace azureml. Você pode usar os comandos a seguir para verificar o status da extensão.

# get the extension status
az k8s-extension show --name <extension-name>

# check status of all pods of Azure Machine Learning extension
kubectl get pod -n azureml

# get events of the extension
kubectl get events -n azureml --sort-by='.lastTimestamp'

Solução de problemas do erro de implantação da extensão do Azure Machine Learning

Erro: não é possível reutilizar um nome que ainda esteja em uso

Esse erro significa que o nome da extensão que você especificou já existe. Se o nome for utilizado pela extensão do Azure Machine Learning, você precisará aguardar cerca de uma hora e tentar novamente. Se o nome estiver sendo usado por outros gráficos Helm, você precisará usar outro nome. Execute helm list -Aa para listar todos os gráficos Helm em seu cluster.

Erro: a operação anterior para o gráfico Helm ainda está em andamento

Você precisará esperar cerca de uma hora e tentar novamente depois que a operação desconhecida for concluída.

Erro: não é possível criar um conteúdo no namespace azureml porque ele está sendo encerrado

Esse erro acontece quando uma operação de desinstalação não é concluída e outra operação de instalação é disparada. Você pode executar o comando az k8s-extension show para verificar o status de provisionamento da extensão e verificar se a extensão foi desinstalada antes de executar outras ações.

Erro: falha ao baixar o gráfico – caminho não encontrado

Esse erro acontece quando você especifica uma versão de extensão errada. Você precisa verificar se a versão especificada existe. Se você quiser usar a versão mais recente, não precisará especificar --version.

Erro: não é possível importar para a versão atual: metadados de propriedade inválidos

Esse erro significa que há um conflito entre os recursos de cluster existentes e a extensão do Azure Machine Learning. Uma mensagem de erro completa pode ser semelhante ao seguinte texto:

CustomResourceDefinition "jobs.batch.volcano.sh" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "amlarc-extension"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "azureml"

Execute as seguintes etapas para atenuar o problema.

Verifique quem é o proprietário dos recursos problemáticos e se o recurso pode ser excluído ou modificado.
Se o recurso só estiver sendo usado pela extensão do Azure Machine Learning e puder ser excluído, você poderá adicionar rótulos manualmente para atenuar o problema. Tomando a mensagem de erro anterior como exemplo, você pode executar comandos da seguinte maneira:
```
kubectl label crd jobs.batch.volcano.sh "app.kubernetes.io/managed-by=Helm" 
kubectl annotate crd jobs.batch.volcano.sh "meta.helm.sh/release-namespace=azureml" "meta.helm.sh/release-name=<extension-name>"
```
Ao definir os rótulos e as anotações para o recurso, isso significa que o helm está gerenciando o recurso que é de propriedade da extensão do Azure Machine Learning.
Quando o recurso também é utilizado por outros componentes em seu cluster e não pode ser modificado. Veja Implantar a extensão do Azure Machine Learning para ver se há uma definição de configuração usada para desabilitar o recurso em conflito.

HealthCheck da extensão

Quando a instalação falhou e não atingiu nenhuma das mensagens de erro acima, você pode usar o trabalho de verificação de integridade interno para fazer uma verificação abrangente da extensão. A extensão de aprendizado de máquina do Azure contém um trabalho HealthCheck para verificar previamente a prontidão do cluster quando você tenta instalar, atualizar ou excluir a extensão. O trabalho HealthCheck gera um relatório salvo em um configmap denominado arcml-healthcheck no namespace azureml. Os códigos de erro e possíveis soluções para o relatório estão listados em Código de erro do HealthCheck.

Execute o comando a seguir para obter o relatório do HealthCheck.

kubectl describe configmap -n azureml arcml-healthcheck

A verificação de integridade é disparada sempre que você instala, atualiza ou exclui a extensão. O relatório de verificação de integridade é estruturado com várias partes pre-install, pre-rollback, pre-upgrade e pre-delete.

Se a instalação da extensão falhar, você deverá investigar pre-install e pre-delete.
Se a atualização da extensão falhar, você deverá investigar pre-upgrade e pre-rollback.
Se a exclusão da extensão falhar, você deverá investigar pre-delete.

Quando você solicita suporte, recomendamos que você execute o comando a seguir e envie o arquivo healthcheck.logs para nós, que pode nos facilitar a identificação do problema.

kubectl logs healthcheck -n azureml

Código de erro do HealthCheck

Esta tabela mostra como solucionar problemas dos códigos de erro retornados pelo relatório do HealthCheck.

Código do Erro	Mensagem de erro	Descrição
E40001	LOAD_BALANCER_NOT_SUPPORT	O balanceador de carga não é compatível com o cluster. Você precisa configurar o balanceador de carga em seu cluster ou considerar a configuração de `inferenceRouterServiceType` para `nodePort` ou `clusterIP`.
E40002	INSUFFICIENT_NODE	Você habilitou `inferenceRouterHA`, que exige pelo menos três nós em seu cluster. Desabilite a HA se você tiver menos de três nós.
E40003	INTERNAL_LOAD_BALANCER_NOT_SUPPORT	Atualmente, apenas o AKS dá suporte ao balanceador de carga interno e só damos suporte ao tipo `azure`. Não defina `internalLoadBalancerProvider` se você não tiver um cluster do AKS.
E40007	INVALID_SSL_SETTING	O certificado ou chave SSL não é válido. O CNAME deve ser compatível com o certificado.
E45002	PROMETHEUS_CONFLICT	O operador Prometheus instalado está em conflito com o operador Prometheus existente. Para obter mais informações, confira Operador Prometheus
E45003	BAD_NETWORK_CONNECTIVITY	Você precisa atender aos requisitos de rede.
E45004	AZUREML_FE_ROLE_CONFLICT	Não há suporte para a extensão do Azure Machine Learning no AKS herdado. Para instalar a extensão do Azure Machine Learning, você precisa excluir os componentes herdados do azureml-fe.
E45005	AZUREML_FE_DEPLOYMENT_CONFLICT	Não há suporte para a extensão do Azure Machine Learning no AKS herdado. Para instalar a extensão do Azure Machine Learning, execute o comando abaixo desse formulário para excluir os componentes herdados do azureml-fe, para obter mais detalhes consulte aqui.

Comandos para excluir os componentes herdados do azureml-fe no cluster do AKS:

kubectl delete sa azureml-fe
kubectl delete clusterrole azureml-fe-role
kubectl delete clusterrolebinding azureml-fe-binding
kubectl delete svc azureml-fe
kubectl delete svc azureml-fe-int-http
kubectl delete deploy azureml-fe
kubectl delete secret azuremlfessl
kubectl delete cm azuremlfeconfig

Integração de componentes de código aberto

A extensão do Azure Machine Learning usa alguns componentes de código aberto, incluindo o Operador do Prometheus, o Agendador do Volcano e o exportador DCGM. Se o cluster do Kubernetes já tiver alguns deles instalados, você poderá ler as seções a seguir para integrar seus componentes existentes à extensão do Azure Machine Learning.

Operador Prometheus

O operador Prometheus é uma estrutura código aberto para ajudar a criar o sistema de monitoramento de métricas no Kubernetes. A extensão do Azure Machine Learning também utiliza o operador do Prometheus para ajudar a monitorar a utilização de recursos de trabalhos.

Se o cluster tiver o operador do Prometheus instalado por outro serviço, você poderá especificar installPromOp=false para desativar o operador do Prometheus na extensão do Azure Machine Learning para evitar um conflito entre dois operadores do Prometheus. Nesse caso, o operador do Prometheus existente gerencia todas as instâncias do Prometheus. Para garantir que o Prometheus funcione corretamente, preste atenção nos itens a seguir ao desabilitar o operador do Prometheus na extensão Azure Machine Learning.

Verifique se o Prometheus no namespace azureml é gerenciado pelo operador Prometheus. Em alguns cenários, o operador Prometheus é definido para monitorar apenas alguns namespaces específicos. Nesse caso, verifique se o namespace azureml está na lista de permissões. Para obter mais informações, confira sinalizadores de comando.
Verifique se o kubelet-service está habilitado no operador Prometheus. O kubelet-service contém todos os pontos de extremidade do kubelet. Para obter mais informações, confira sinalizadores de comando. Você também precisa garantir que o kubelet-service tenha um rótulo k8s-app=kubelet.

Crie um ServiceMonitor para o kubelet-service. Execute o seguinte comando, substituindo as variáveis:

cat << EOF | kubectl apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: prom-kubelet
  namespace: azureml
  labels:
    release: "<extension-name>"     # Please replace to your Azure Machine Learning extension name
spec:
  endpoints:
  - port: https-metrics
    scheme: https
    path: /metrics/cadvisor
    honorLabels: true
    tlsConfig:
      caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
      insecureSkipVerify: true
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabelings:
    - sourceLabels:
      - __metrics_path__
      targetLabel: metrics_path
  jobLabel: k8s-app
  namespaceSelector:
    matchNames:
    - "<namespace-of-your-kubelet-service>"  # Please change this to the same namespace of your kubelet-service
  selector:
    matchLabels:
      k8s-app: kubelet    # Please make sure your kubelet-service has a label named k8s-app and it's value is kubelet

EOF

Exportador de DCGM

O Dcgm-exporter é a ferramenta oficial recomendada pela NVIDIA para coletar métricas de GPU. Nós o integramos à extensão do Azure Machine Learning. Mas, por padrão, o dcgm-exporter não está habilitado e nenhuma métrica de GPU é coletada. Você pode especificar o sinalizador installDcgmExporter como true para habilitá-lo. Como essa é a ferramenta oficial da NVIDIA, talvez você já o tenha instalado no cluster de GPU. Em caso afirmativo, você pode definir installDcgmExporter para false e seguir as etapas para integrar seu dcgm-exporter à extensão do Azure Machine Learning. Outra coisa a observar é que o dcgm-export permite que usuários configurem quais métricas expor. Para a extensão do Azure Machine Learning, certifique-se de que as métricas DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_FREE e DCGM_FI_DEV_FB_USED estejam expostas.

Verifique se você tem a extensão AzureML e o exportador de dcgm instalados com êxito. O dcgm-exporter pode ser instalado pelo gráfico Helm do dcgm-exporter ou pelo gráfico Helm do gpu-operator

Verifique se há um serviço para o dcgm-exporter. Se ele não existir ou você não souber como verificar, execute o comando a seguir para criar um.

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: dcgm-exporter-service
  namespace: "<namespace-of-your-dcgm-exporter>" # Please change this to the same namespace of your dcgm-exporter
  labels:
    app.kubernetes.io/name: dcgm-exporter
    app.kubernetes.io/instance: "<extension-name>" # Please replace to your Azure Machine Learning extension name
    app.kubernetes.io/component: "dcgm-exporter"
  annotations:
    prometheus.io/scrape: 'true'
spec:
  type: "ClusterIP"
  ports:
  - name: "metrics"
    port: 9400  # Please replace to the correct port of your dcgm-exporter. It's 9400 by default
    targetPort: 9400  # Please replace to the correct port of your dcgm-exporter. It's 9400 by default
    protocol: TCP
  selector:
    app.kubernetes.io/name: dcgm-exporter  # Those two labels are used to select dcgm-exporter pods. You can change them according to the actual label on the service
    app.kubernetes.io/instance: "<dcgm-exporter-helm-chart-name>" # Please replace to the helm chart name of dcgm-exporter
EOF

Verifique se o serviço na etapa anterior está definido corretamente

kubectl -n <namespace-of-your-dcgm-exporter> port-forward service/dcgm-exporter-service 9400:9400
# run this command in a separate terminal. You will get a lot of dcgm metrics with this command.
curl http://127.0.0.1:9400/metrics

Configure o ServiceMonitor para expor o serviço dcgm-exporter à extensão do Azure Machine Learning. Execute o seguinte comando e ele entrará em vigor em alguns minutos.

cat << EOF | kubectl apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: dcgm-exporter-monitor
  namespace: azureml
  labels:
    app.kubernetes.io/name: dcgm-exporter
    release: "<extension-name>"   # Please replace to your Azure Machine Learning extension name
    app.kubernetes.io/component: "dcgm-exporter"
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: dcgm-exporter
      app.kubernetes.io/instance: "<extension-name>"   # Please replace to your Azure Machine Learning extension name
      app.kubernetes.io/component: "dcgm-exporter"
  namespaceSelector:
    matchNames:
    - "<namespace-of-your-dcgm-exporter>"  # Please change this to the same namespace of your dcgm-exporter
  endpoints:
  - port: "metrics"
    path: "/metrics"
EOF

Agendador Volcano

Se o cluster já tiver o conjunto Volcano instalado, você poderá definir installVolcano=false para que a extensão não instale o agendador Volcano. O agendador Volcano e o controlador Volcano são necessários para o envio e o agendamento do trabalho de treinamento.

A configuração do agendador do Volcano usada pela extensão do Azure Machine Learning é:

volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
        - name: task-topology
        - name: priority
        - name: gang
        - name: conformance
    - plugins:
        - name: overcommit
        - name: drf
        - name: predicates
        - name: proportion
        - name: nodeorder
        - name: binpack

Você precisa usar essas mesmas definições de configuração e desabilitar o webhook job/validate na admissão do volcano se a versão do volcano for inferior a 1.6, para que as cargas de trabalho de treinamento do Azure Machine Learning possam ser executadas corretamente.

Integração do agendador do Volcano que dá suporte ao dimensionador automático de cluster

Conforme a discussão nesta conversa, plug-in gang não está funcionando bem com o AC (dimensionador automático) de cluster nem com o dimensionador automático de nós no AKS.

Se você usar o volcano que vem com a extensão Azure Machine Learning através da configuração installVolcano=true, a extensão terá uma configuração de agendador por padrão, que configura o plug-in gang para evitar o deadlock do trabalho. Portanto, o dimensionador automático do cluster (CA) no cluster do AKS não terá suporte com o volcano instalado por extensão.

Nesse caso, se você preferir que o dimensionador automático do cluster do AKS funcione normalmente, poderá configurar esse parâmetro volcanoScheduler.schedulerConfigMap através da extensão de atualização e especificar uma configuração personalizada do agendador do volcano sem gang para ele, por exemplo:

volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: sla 
        arguments:
        sla-waiting-time: 1m
    - plugins:
      - name: conformance
    - plugins:
        - name: drf
        - name: predicates
        - name: proportion
        - name: nodeorder
        - name: binpack

Para utilizar essa configuração no seu cluster do AKS, é necessário seguir as etapas a seguir:

Crie um arquivo configmap com a configuração acima no namespace azureml. Em geral, esse namespace será criado quando você instalar a extensão do Azure Machine Learning.
Defina volcanoScheduler.schedulerConfigMap=<configmap name> na configuração de extensão para aplicar esse configmap. E você precisa ignorar a validação de recursos ao instalar a extensão configurando amloperator.skipResourceValidation=true. Por exemplo:
```
az k8s-extension update --name <extension-name> --config volcanoScheduler.schedulerConfigMap=<configmap name> amloperator.skipResourceValidation=true --cluster-type managedClusters --cluster-name <your-AKS-cluster-name> --resource-group <your-RG-name>
```

Observação

Como o plug-in gang é removido, um deadlock pode acontecer quando o Volcano agenda o trabalho.

Para evitar essa situação, você pode usar o mesmo tipo de instância entre os trabalhos.

O uso de uma configuração de agendador diferente do padrão fornecido pela extensão do Azure Machine Learning pode não ter suporte total. Continue com cuidado.

Observe que você precisará desabilitar o webhook job/validate na admissão do Volcano se a versão do Volcano for inferior à 1.6.

Controlador Nginx de entrada

A instalação da extensão do Azure Machine Learning vem com uma classe de controlador de entrada nginx como k8s.io/ingress-nginx por padrão. Se você já tiver um controlador nginx de entrada no seu cluster, precisará usar uma classe de controlador diferente para evitar falhas na instalação.

Você tem duas opções:

Altere sua classe de controlador existente para algo diferente de k8s.io/ingress-nginx.
Criar ou atualizar nossa extensão do Azure Machine Learning com uma classe de controlador personalizada que seja diferente da sua, seguindo os seguintes exemplos.

Por exemplo, para criar a extensão com uma classe de controlador personalizado:

az ml extension create --config nginxIngress.controller="k8s.io/amlarc-ingress-nginx"

Para atualizar a extensão com uma classe de controlador personalizado:

az ml extension update --config nginxIngress.controller="k8s.io/amlarc-ingress-nginx"

Ocorreu um erro no controlador de entrada do Nginx instalado com a extensão de aprendizado de máquina do Azure por causa de erros de falta de memória (OOM)

Sintoma

Ocorreu um erro no controlador de entrada do nginx instalado com a extensão de aprendizado de máquina do Azure por causa de erros de falta de memória (OOM), mesmo quando não houver carga de trabalho. Os logs do controlador não mostram nenhuma informação útil para diagnosticar o problema.

Possível causa

Esse problema poderá ocorrer se o controlador de entrada nginx for executado em um nó com muitas CPUs. Por padrão, o controlador de entrada nginx gera processos de trabalho de acordo com o número de CPUs, que podem consumir mais recursos e causar erros de OOM nos nós com mais CPUs. Esse é um problema conhecido relatado no GitHub

Resolução

Para resolver esse problema, é possível:

Ajuste o número de processos de trabalho instalando a extensão com o parâmetro nginxIngress.controllerConfig.worker-processes=8.
Aumente o limite de memória usando o parâmetro nginxIngress.resources.controller.limits.memory=<new limit>.

Certifique-se de ajustar esses dois parâmetros de acordo com suas especificações de nó e requisitos de carga de trabalho específicos para otimizar suas cargas de trabalho com eficiência.

Compartilhar via