Resolver problemas da extensão do Azure Machine Learning

Artigo
03/10/2024

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

Como é instalada a extensão do Azure Machine Learning

A extensão do Azure Machine Learning é lançada como um gráfico de leme e instalada pelo Helm V3. Todos os componentes da extensão do Azure Machine Learning são instalados no azureml namespace. Você pode usar os seguintes comandos 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'

Resolver o erro de implementação da extensão do Azure Machine Learning

Erro: não é possível reutilizar um nome que ainda esteja a ser utilizado

Este erro significa que o nome da extensão que especificou já existe. Se o nome for utilizado pela extensão do Azure Machine Learning, terá de aguardar cerca de uma hora e tentar novamente. Se o nome for utilizado por outros gráficos helm, terá de utilizar outro nome. Execute helm list -Aa para listar todos os gráficos de leme em seu cluster.

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

Tem de aguardar cerca de uma hora e tentar novamente após a conclusão da operação desconhecida.

Erro: não é possível criar novo conteúdo no espaço de nomes azureml porque está a ser terminado

Este erro ocorre quando uma operação de desinstalação não é concluída e outra operação de instalação é acionada. Pode executar o comando az k8s-extension show para verificar o estado de aprovisionamento da extensão e certificar-se de que a extensão foi desinstalada antes de efetuar outras ações.

Erro: falha ao transferir o Gráfico, caminho não encontrado

Este erro ocorre quando especifica uma versão errada da extensão. Tem de se certificar de que a versão especificada existe. Se você quiser usar a versão mais recente, não precisa especificar --version .

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

Este erro significa que existe 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"

Use as etapas a seguir para mitigar o problema.

Verifique quem é o proprietário dos recursos problemáticos e se o recurso pode ser eliminado ou modificado.
Se o recurso for utilizado apenas pela extensão do Azure Machine Learning e puder ser eliminado, pode adicionar manualmente etiquetas para mitigar o problema. Ao utilizar a mensagem de erro anterior como exemplo, pode executar comandos da seguinte forma,
```
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 as etiquetas e anotações para o recurso, significa que o helm está a gerir o recurso que pertence à extensão do Azure Machine Learning.
Quando o recurso também é utilizado por outros componentes no seu cluster e não pode ser modificado. Consulte implantar a extensão do Azure Machine Learning para ver se há uma definição de configuração para desabilitar o recurso de 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 na extensão. A extensão de aprendizado de máquina do Azure contém um HealthCheck trabalho para pré-verificar a preparação do cluster quando você tenta instalar, atualizar ou excluir a extensão. O trabalho HealthCheck gera um relatório, que é salvo em um configmap nomeado arcml-healthcheck no azureml namespace. 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 este comando para obter o relatório HealthCheck,

kubectl describe configmap -n azureml arcml-healthcheck

A verificação do estado de funcionamento é acionada sempre que instalar, atualizar ou eliminar a extensão. O relatório de verificação do estado de funcionamento está estruturado com várias partespre-install, pre-rollbackpre-upgrade e pre-delete.

Se a extensão estiver instalada falhou, você deve olhar para pre-install e pre-delete.
Se a extensão for atualizada falhar, você deve examinar pre-upgrade e pre-rollback.
Se a extensão for excluída falhou, você deve olhar para pre-delete.

Quando pedir suporte, recomendamos que execute o seguinte comando e nos envie o ficheiro healthcheck.logs, pois pode facilitar-nos a localização do problema.

kubectl logs healthcheck -n azureml

Código de erro do HealthCheck

Esta tabela mostra como resolver os códigos de erro devolvidos pelo relatório de HealthCheck.

Código de Erro	Mensagem de Erro	Description
E40001	LOAD_BALANCER_NOT_SUPPORT	O balanceador de carga não é suportado no cluster. Você precisa configurar o balanceador de carga em seu cluster ou considerar a configuração `inferenceRouterServiceType` de `nodePort` ou `clusterIP`.
E40002	INSUFFICIENT_NODE	Você habilitou `inferenceRouterHA` que requer pelo menos três nós em seu cluster. Desative o HA se tiver menos de três nós.
E40003	INTERNAL_LOAD_BALANCER_NOT_SUPPORT	Atualmente, apenas o AKS suporta o balanceador de carga interno, e nós suportamos apenas o `azure` tipo. Não defina `internalLoadBalancerProvider` se você não tiver um cluster AKS.
E40007	INVALID_SSL_SETTING	A chave SSL ou o certificado 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 seu Operador Prometheus existente. Para obter mais informações, consulte Operador Prometheus
E45003	BAD_NETWORK_CONNECTIVITY	Você precisa atender aos requisitos de rede.
E45004	AZUREML_FE_ROLE_CONFLICT	A extensão do Azure Machine Learning não é suportada no AKS herdado. Para instalar a extensão do Azure Machine Learning, você precisa excluir os componentes azureml-fe herdados.
E45005	AZUREML_FE_DEPLOYMENT_CONFLICT	A extensão do Azure Machine Learning não é suportada no AKS herdado. Para instalar a extensão do Azure Machine Learning, você precisa executar o comando abaixo deste formulário para excluir os componentes azureml-fe herdados, mais detalhes que você pode consultar aqui.

Comandos para excluir os componentes azureml-fe herdados no cluster 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 Open Source

A extensão do Azure Machine Learning usa alguns componentes de código aberto, incluindo o Prometheus Operator, o Volcano Scheduler 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 com a extensão do Azure Machine Learning.

Operador Prometheus

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

Se o cluster tiver o operador Prometheus instalado por outro serviço, você poderá especificar installPromOp=false para desabilitar o operador Prometheus na extensão do Azure Machine Learning para evitar um conflito entre dois operadores Prometheus. Neste caso, o operador Prometheus existente gerencia todas as instâncias Prometheus. Para garantir que o Prometheus funcione corretamente, as seguintes coisas precisam ser prestadas atenção ao desabilitar o operador Prometheus na extensão do Azure Machine Learning.

Verifique se prometheus no namespace azureml é gerenciado pelo operador Prometheus. Em alguns cenários, o operador prometheus é definido para monitorar apenas alguns namespaces específicos. Em caso afirmativo, verifique se azureml namespace está na allowlist. Para obter mais informações, consulte sinalizadores de comando.
Verifique se o kubelet-service está ativado no operador prometheus. Kubelet-service contém todos os pontos finais do kubelet. Para obter mais informações, consulte sinalizadores de comando. E também precisa se certificar de que o kubelet-service tem um rótulok8s-app=kubelet.

Crie ServiceMonitor para kubelet-service. Execute o seguinte comando com variáveis substituídas:

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

DCGM exportador

Dcgm-exporter é a ferramenta oficial recomendada pela NVIDIA para coletar métricas de GPU. Integrámo-lo na extensão Azure Machine Learning. Mas, por padrão, dcgm-exporter não está habilitado e nenhuma métrica de GPU é coletada. Você pode especificar installDcgmExporter sinalizador para true habilitá-lo. Como é a ferramenta oficial da NVIDIA, você já pode tê-la instalada no seu cluster de GPU. Em caso afirmativo, você pode definir installDcgmExporter false e seguir as etapas para integrar seu dcgm-exporter à extensão do Azure Machine Learning. Outra coisa a notar é que dcgm-exporter permite ao usuário configurar quais métricas expor. Para a extensão do Azure Machine Learning, certifique-se de que DCGM_FI_DEV_GPU_UTILo , DCGM_FI_DEV_FB_FREE e DCGM_FI_DEV_FB_USED as métricas estão expostas.

Certifique-se de ter a extensão Aureml e dcgm-exporter instalados com êxito. Dcgm-exportador pode ser instalado por Dcgm-exportador helm chart ou Gpu-operator helm chart

Verifique se há um serviço para dcgm-exporter. Se ele não existir ou você não souber como verificar, execute o seguinte comando 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á configurado 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 entra em vigor em poucos 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 de Vulcões

Se o seu cluster já tiver o pacote volcano instalado, você pode definir installVolcano=false, para que a extensão não instale o agendador volcano. Agendador de vulcão e controlador de vulcão são necessários para a submissão de trabalho de treinamento e agendamento.

A configuração do agendador de vulcão 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 configurações e precisa desabilitar job/validate o webhook na admissão do vulcão se sua versão do vulcão 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 de vulcão com suporte ao autoscaler de cluster

Como discutido neste tópico , o plug-in gang não está funcionando bem com o cluster autoscaler(CA) e também com o nó autoscaler no AKS.

Se você usar o vulcão que vem com a extensão do Azure Machine Learning via configuraçãoinstallVolcano=true, a extensão tem uma configuração do agendador por padrão, que configura o plug-in gang para evitar o bloqueio do trabalho. Portanto, o cluster autoscaler(CA) no cluster AKS não será suportado com o vulcão instalado por extensão.

Para este caso, se você preferir que o autoscaler de cluster AKS possa funcionar normalmente, você pode configurar esse volcanoScheduler.schedulerConfigMap parâmetro por meio da extensão de atualização e especificar uma configuração personalizada de nenhum agendador de vulcão de gangue 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: overcommit
        - name: drf
        - name: predicates
        - name: proportion
        - name: nodeorder
        - name: binpack

Para usar essa configuração em seu cluster AKS, você precisa seguir as seguintes etapas:

Crie um arquivo configmap com a configuração acima no azureml namespace. Esse namespace geralmente será criado quando você instalar a extensão do Azure Machine Learning.

Defina volcanoScheduler.schedulerConfigMap=<configmap name> na configuração da extensão para aplicar este configmap. E você precisa ignorar a validação de recursos ao instalar a extensão configurando amloperator.skipResourceValidation=trueo . Por exemplo:

az k8s-extension update --name <extension-name> --extension-type Microsoft.AzureML.Kubernetes --config volcanoScheduler.schedulerConfigMap=<configmap name> amloperator.skipResourceValidation=true --cluster-type managedClusters --cluster-name <your-AKS-cluster-name> --resource-group <your-RG-name> --scope cluster

Nota

Como o plugin da gangue é removido, há potencial de que o impasse aconteça quando o vulcão agenda o trabalho.

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

Note que você precisa desativar job/validate o webhook na admissão do vulcão se a sua versão do vulcão for inferior a 1.6.

Ingress controlador Nginx

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

Tem duas opções:

Altere sua classe de controlador existente para algo diferente de k8s.io/ingress-nginx.
Crie ou atualize nossa extensão do Azure Machine Learning com uma classe de controlador personalizada diferente da sua, seguindo os exemplos a seguir.

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

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

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

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

O controlador de ingresso Nginx instalado com a extensão do Azure Machine Learning falha devido a erros de falta de memória (OOM)

Sintoma

O controlador de ingresso nginx instalado com a extensão do Azure Machine Learning falha devido a erros de falta de memória (OOM), mesmo quando não há carga de trabalho. Os logs do controlador não mostram nenhuma informação útil para diagnosticar o problema.

Possível causa

Esse problema pode ocorrer se o controlador de entrada nginx é 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, o que pode consumir mais recursos e causar erros OOM em nós com mais CPUs. Este é um problema conhecido relatado no GitHub

Resolução

Para resolver este problema, pode:

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 específicas de nó e requisitos de carga de trabalho para otimizar suas cargas de trabalho de forma eficaz.

Partilhar via