Share via

Solucionar problemas de computação do Kubernetes

  • Artigo

Neste artigo, você aprenderá como solucionar problemas de erros comuns de carga de trabalho na computação do Kubernetes. Erros comuns incluem trabalhos de treinamento e erros de ponto de extremidade.

Guia de inferência

Os erros comuns do ponto de extremidade do Kubernetes na computação do Kubernetes são categorizados em dois escopos: escopo de computação e escopo de cluster. Os erros de escopo de computação estão relacionados ao destino de computação, como o destino de computação não ser encontrado ou o destino de computação não estar acessível. Os erros do escopo do cluster estão relacionados ao cluster subjacente do Kubernetes, como o cluster em si não está acessível ou o cluster não foi encontrado.

Erros da computação do Kubernetes

A seguir estão listados os tipos de erro comuns no escopo de computação que você pode encontrar ao usar a computação do Kubernetes para criar pontos de extremidade online e implantações online para inferência de modelo em tempo real. Você pode solucionar problemas seguindo as seções vinculadas para obter diretrizes:

ERROR: GenericComputeError

A mensagem de erro é a seguinte:

Failed to get compute information.

Esse erro deve ocorrer quando o sistema falha ao obter as informações de computação do cluster do Kubernetes. Você pode verificar os seguintes itens para solucionar o problema:

  • Verifique o status do cluster do Kubernetes. Se o cluster não estiver em execução, você precisará iniciar o cluster primeiro.
  • Verifique a integridade do cluster do Kubernetes.
    • Você pode exibir o relatório de verificação de integridade do cluster para quaisquer problemas, por exemplo, se o cluster não estiver acessível.
    • Você pode acessar o portal do workspace para verificar o status da computação.
  • Verifique se as informações sobre os tipos de instância estão corretas. Você pode verificar os tipos de instância com suporte na documentação da computação do Kubernetes.
  • Tente desanexar e reanexar a computação ao workspace, se aplicável.

Observação

Para solucionar erros anexando novamente, certifique-se de anexar novamente com a mesma configuração exata que a computação desanexada anteriormente, como o mesmo nome de computação e namespace. Caso contrário, você poderá encontrar outros erros.

ERROR: ComputeNotFound

A mensagem de erro é a seguinte:

Cannot find Kubernetes compute.

Esse erro deve ocorrer quando:

  • O sistema não encontra a computação ao criar/atualizar novo ponto de extremidade/implantação online.
  • A computação de pontos de extremidade/implantações online existentes foi removida.

Você pode verificar os seguintes itens para solucionar o problema:

  • Tente recriar o ponto de extremidade e a implantação.
  • Tente desanexar e reanexar a computação ao workspace. Preste atenção a mais anotações sobre reanexação.

ERROR: ComputeNotAccessible

A mensagem de erro é a seguinte:

The Kubernetes compute is not accessible.

Esse erro deve ocorrer quando a MSI do workspace (identidade gerenciada) não tiver acesso ao cluster do AKS. Você pode verificar se o MSI do workspace tem acesso ao AKS e, caso contrário, pode seguir este documento para gerenciar o acesso e a identidade.

ERRO: InvalidComputeInformation

A mensagem de erro é a seguinte:

The compute information is invalid.

Há um processo de validação de destino de computação ao implantar modelos no cluster do Kubernetes. Esse erro deve ocorrer quando as informações de computação forem inválidas. Por exemplo, o destino da computação não foi encontrado ou a configuração da extensão do Azure Machine Learning foi atualizada em seu cluster do Kubernetes.

Você pode verificar os seguintes itens para solucionar o problema:

  • Verifique se o destino de computação usado está correto e existe no workspace.
  • Tente desanexar e reanexar a computação ao workspace. Preste atenção a mais anotações sobre reanexação.

ERRO: InvalidComputeNoKubernetesConfiguration

A mensagem de erro é a seguinte:

The compute kubeconfig is invalid.

Esse erro deve ocorrer quando o sistema não consegue localizar nenhuma configuração para se conectar ao cluster, como:

  • Para o cluster do Arc-Kubernetes, não é possível encontrar nenhuma configuração de Retransmissão do Azure.
  • Para o cluster do AKS, não é possível encontrar nenhuma configuração do AKS.

Para recompilar a configuração da conexão de computação no cluster, você pode tentar desanexar e reanexar a computação ao workspace. Preste atenção a mais anotações sobre reanexação.

Erro de cluster do Kubernetes

Veja abaixo uma lista de tipos de erro no escopo do cluster que você pode encontrar ao usar a computação do Kubernetes para criar pontos de extremidade online e implantações online para inferência de modelo em tempo real. Você pode solucionar esses problemas seguindo as diretrizes:

ERROR: GenericClusterError

A mensagem de erro é a seguinte:

Failed to connect to Kubernetes cluster: <message>

Esse erro deve ocorrer quando o sistema falha ao se conectar ao cluster do Kubernetes por um motivo desconhecido. Você pode verificar os seguintes itens para solucionar o problema:

Para clusters do AKS:

  • Verifique se o cluster do AKS está desligado.
    • Se o cluster não estiver em execução, você precisará iniciar o cluster primeiro.
  • Verifique se o cluster do AKS habilitou a rede selecionada usando intervalos de IP autorizados.
    • Se o cluster do AKS tiver habilitado intervalos de IP autorizados, certifique-se de que todos os intervalos de IP do plano de controle do Azure Machine Learning tenham sido habilitados para o cluster do AKS. Para obter mais informações, você pode ver este documento.

Para um cluster do AKS ou um cluster de Kubernetes habilitado para o Azure Arc:

  • Verifique se o servidor de API do Kubernetes está acessível executando o comando kubectl no cluster.

ERROR: ClusterNotReachable

A mensagem de erro é a seguinte:

The Kubernetes cluster is not reachable.

Esse erro deve ocorrer quando o sistema não consegue se conectar a um cluster. Você pode verificar os seguintes itens para solucionar o problema:

Para clusters do AKS:

  • Verifique se o cluster do AKS está desligado.
    • Se o cluster não estiver em execução, você precisará iniciar o cluster primeiro.

Para um cluster do AKS ou um cluster de Kubernetes habilitado para o Azure Arc:

  • Verifique se o servidor de API do Kubernetes está acessível executando o comando kubectl no cluster.

ERRO: ClusterNotFound

A mensagem de erro é a seguinte:

Cannot found Kubernetes cluster.

Esse erro deve ocorrer quando o sistema não consegue localizar o cluster do AKS/Arc-Kubernetes.

Você pode verificar os seguintes itens para solucionar o problema:

  • Primeiro, verifique a ID do recurso de cluster no portal do Azure para conferir se o recurso de cluster do Kubernetes ainda existe e se está sendo executado normalmente.
  • Se o cluster existir e estiver em execução, tente desanexar e reanexar a computação ao workspace. Preste atenção a mais anotações sobre reanexação.

Dica

Veja mais guias de solução de problemas para erros comuns ao criar ou atualizar os pontos de extremidade e as implantações online do Kubernetes, em Como solucionar problemas de pontos de extremidade online.

Erro de identidade

ERRO: RefreshExtensionIdentityNotSet

Esse erro ocorre quando a extensão é instalada, mas a identidade da extensão não é atribuída corretamente. Você pode tentar reinstalar a extensão para corrigir o problema.

Observe que esse erro é apenas para clusters gerenciados

Como verificar se sslCertPemFile e sslKeyPemFile está correto?

Para permitir que quaisquer erros conhecidos sejam revelados, você pode usar os comandos para executar uma linha de base para seu certificado e chave. Espere que o segundo comando retorne "Chave RSA ok" sem solicitar a senha.

openssl x509 -in cert.pem -noout -text
openssl rsa -in key.pem -noout -check

Execute os comandos para verificar se o sslCertPemFile e sslKeyPemFile estão correspondendo:

openssl x509 -in cert.pem -noout -modulus | md5sum
openssl rsa -in key.pem -noout -modulus | md5sum

Para o sslCertPemFile, esse é o certificado público. Ele deve incluir a cadeia de certificados que inclui os seguintes certificados e que deve estar na sequência do certificado do servidor, do certificado da AC intermediária e do certificado da AC raiz:

  • O certificado do servidor: o servidor apresenta ao cliente durante o handshake do protocolo TLS. Ele contém a chave pública do servidor, o nome do domínio e outras informações. O certificado do servidor é assinado por uma autoridade de certificação (AC) intermediária que atesta a identidade do servidor.
  • O certificado da AC intermediária: a AC intermediária apresenta ao cliente para provar sua autoridade para conectar o certificado do servidor. Ele contém a chave pública, o nome e outras informações da AC intermediária. O certificado da AC intermediária é assinado por uma AC raiz que atesta a identidade da AC intermediária.
  • O certificado da AC raiz: a AC raiz apresenta ao cliente para provar sua autoridade para conectar o certificado da AC intermediária. Ele contém a chave pública, o nome e outras informações da AC raiz. O certificado da AC raiz é autoassinado e tem a confiança do cliente.

Guia de treinamento

Quando o trabalho de treinamento estiver em execução, você poderá verificar o status do trabalho no portal do espaço de trabalho. Quando você encontrar algum status de trabalho anormal, como a repetição do trabalho várias vezes, ou o trabalho ficou preso no estado de inicialização, ou até mesmo o trabalho acabou falhando, você pode seguir o guia para solucionar o problema.

Depuração da repetição do trabalho

Se o pod do trabalho de treinamento em execução no cluster tiver sido encerrado devido ao fato de o nó estar sendo executado no nó OOM (sem memória), o trabalho será repetido automaticamente para outro nó disponível.

Para depurar ainda mais a causa raiz da tentativa do trabalho, acesse o portal do workspace para verificar o log de repetição do trabalho.

  • Cada log de repetição é registrado em uma nova pasta de log com o formato "retry-<retry number>" (por exemplo: retry-001).

Em seguida, você pode obter as informações de mapeamento do nó do trabalho de repetição para descobrir em qual nó o trabalho de repetição está sendo executado.

Screenshot of adding a new extension to the Azure Arc-enabled Kubernetes cluster from the Azure portal.

Você pode obter informações de mapeamento de nó de trabalho do amlarc_cr_bootstrap.log na pasta system_logs.

O nome do host do nó no qual o pod de trabalho está executando é indicado nesse log, por exemplo:

++ echo 'Run on node: ask-agentpool-17631869-vmss0000"

"ask-agentpool-17631869-vmss0000" representa o nome do host do nó que executa esse trabalho no cluster do AKS. Em seguida, você pode acessar o cluster para verificar o status do nó para uma investigação mais aprofundada.

O pod de trabalho fica preso no estado inicial

Se o trabalho for executado por mais tempo do que o esperado e se você descobrir que os pods de trabalho estão ficando presos em um estado inicial com o aviso Unable to attach or mount volumes: *** failed to get plugin from volumeSpec for volume ***-blobfuse-*** err=no volume plugin matched, o problema poderá ocorrer porque a extensão do Azure Machine Learning não dá suporte ao modo de download para dados de entrada.

Para resolver esse problema, altere para o modo de montagem dos dados de entrada.

Erros comuns de falha do trabalho

Abaixo está uma lista de tipos de erro comuns que você pode encontrar ao usar a computação do Kubernetes para criar e executar um trabalho de treinamento, que você pode solucionar os problemas seguindo a diretriz:

Falha no trabalho. 137

Se a mensagem de erro for:

Azure Machine Learning Kubernetes job failed. 137:PodPattern matched: {"containers":[{"name":"training-identity-sidecar","message":"Updating certificates in /etc/ssl/certs...\n1 added, 0 removed; done.\nRunning hooks in /etc/ca-certificates/update.d...\ndone.\n * Serving Flask app 'msi-endpoint-server' (lazy loading)\n * Environment: production\n   WARNING: This is a development server. Do not use it in a production deployment.\n   Use a production WSGI server instead.\n * Debug mode: off\n * Running on http://127.0.0.1:12342/ (Press CTRL+C to quit)\n","code":137}]}

Verifique a configuração do proxy e verifique se 127.0.0.1 foi adicionado a proxy-skip-range ao usar az connectedk8s connect seguindo essa configuração de rede.

Falha no trabalho. E45004

Se a mensagem de erro for:

Azure Machine Learning Kubernetes job failed. E45004:"Training feature is not enabled, please enable it when install the extension."

Verifique se você tem enableTraining=True definido ao fazer a instalação da extensão do Azure Machine Learning. Encontre mais detalhes em Implantar a extensão do Azure Machine Learning no cluster do AKS ou do Kubernetes para Arc

Falha no trabalho. 400

Se a mensagem de erro for:

Azure Machine Learning Kubernetes job failed. 400:{"Msg":"Encountered an error when attempting to connect to the Azure Machine Learning token service","Code":400}

Você pode seguir a seção de solução de problemas de Link Privado para verificar as configurações de rede.

Fornecer uma chave de conta ou um token SAS

Se você precisar acessar o Registro de Contêiner do Azure (ACR) para a imagem do Docker e acessar a Conta de Armazenamento para obter os dados de treinamento, esse problema deverá ocorrer quando a computação não for especificada com uma identidade gerenciada.

Para acessar o Registro de Contêiner do Azure (ACR) a partir de um cluster de computação do Kubernetes para imagens do Docker ou acessar uma conta de armazenamento para dados de treinamento, você precisa anexar a computação do Kubernetes com uma identidade gerenciada atribuída pelo sistema ou atribuída pelo usuário habilitada.

No cenário de treinamento acima, essa identidade de computação é necessária para que a computação do Kubernetes seja usada como uma credencial para se comunicar entre o recurso ARM vinculado ao espaço de trabalho e o cluster de computação do Kubernetes. Portanto, sem essa identidade, o trabalho de treinamento falhará e relatará a ausência da chave da conta ou do token SAS. Por exemplo, ao acessar a conta do armazenamento gerenciado, se você não especificar uma identidade gerenciada para a computação do Kubernetes, o trabalho falhará com a seguinte mensagem de erro:

Unable to mount data store workspaceblobstore. Give either an account key or SAS token

A causa é que a conta de armazenamento padrão do espaço de trabalho de aprendizado de máquina sem nenhuma credencial não está acessível para trabalhos de treinamento na computação do Kubernetes.

Para atenuar esse problema, você pode atribuir a identidade gerenciada à computação na etapa de anexação de computação ou atribuir a identidade gerenciada à computação depois que ela for anexada. Mais detalhes podem ser encontrados em Atribuir identidade gerenciada ao destino de computação.

Falha na autorização do AzureBlob

Se você precisar acessar o AzureBlob para fazer upload ou download de dados em seus trabalhos de treinamento na computação do Kubernetes, o trabalho falhará com a seguinte mensagem de erro:

Unable to upload project files to working directory in AzureBlob because the authorization failed.

A causa é a falha na autorização quando o trabalho tenta fazer upload dos arquivos do projeto para o AzureBlob. Você pode verificar os seguintes itens para solucionar o problema:

  • Verifique se a conta de armazenamento habilitou as exceções de "Permitir que os serviços do Azure na lista de serviços confiáveis acessem essa conta de armazenamento" e se o workspace está na lista de instâncias de recursos.
  • Verifique se o workspace tem uma identidade gerenciada atribuída pelo sistema.

Poderíamos usar o método para verificar a configuração do link privado fazendo logon em um pod no cluster do Kubernetes e, em seguida, verificar as configurações de rede relacionadas.

  • Localize a ID do workspace no portal do Azure ou obtenha essa ID executando az ml workspace show na linha de comando.

  • Exiba todos os pods azureml-fe executados por kubectl get po -n azureml -l azuremlappname=azureml-fe.

  • Faça logon em qualquer um deles e execute kubectl exec -it -n azureml {scorin_fe_pod_name} bash.

  • Se o cluster não usar proxy, execute nslookup {workspace_id}.workspace.{region}.api.azureml.ms. Se você configurar o link privado da VNet para o workspace corretamente, o IP interno na VNet deverá ser respondido por meio da ferramenta DNSLookup.

  • Se o cluster usar proxy, você poderá tentar curl workspace

curl https://{workspace_id}.workspace.westcentralus.api.azureml.ms/metric/v2.0/subscriptions/{subscription}/resourceGroups/{resource_group}/providers/Microsoft.MachineLearningServices/workspaces/{workspace_name}/api/2.0/prometheus/post -X POST -x {proxy_address} -d {} -v -k

Quando o proxy e o espaço de trabalho estiverem configurados corretamente com um link privado, você deverá observar uma tentativa de se conectar a um IP interno. Uma resposta com um código de status HTTP 401 é esperada nesse cenário se um token não for fornecido.

Outros problemas conhecidos

A atualização de computação do Kubernetes não entra em vigor

No momento, a CLI v2 e o SDK v2 não permitem atualizar nenhuma configuração de uma computação existente do Kubernetes. Por exemplo, a alteração do namespace não entra em vigor.

O nome do workspace ou do grupo de recursos termina com '-'

Uma causa comum da falha de "InternalServerError" ao criar cargas de trabalho, como implantações, pontos de extremidade ou trabalhos em uma computação do Kubernetes, é ter os caracteres especiais como '-' no final do seu workspace ou nome do grupo de recursos.

Próximas etapas