Referência do código de erro do Anthos

As mensagens de erro do Anthos consistem em um código de erro no formato APME1234, em que 1234 é um número exclusivo, seguido por uma descrição do problema e uma sugestão de como corrigi-lo. Este documento lista todas essas mensagens de erro.

APME1000 ImageAccessError

Esse erro indica que o componente que produziu o erro não encontrou uma ou mais das imagens necessárias no registro especificado.

Verifique se estas condições foram atendidas:

  • As imagens necessárias existem no Container Registry.
  • O registro pode ser acessado a partir da origem do erro.
  • A estação de trabalho tem permissões READ e PULL no registro.
  • A estação de trabalho tem o arquivo ${HOME}/.docker/config.json e está configurada corretamente para acessar o registro.

APME1001 InvalidRegistryInputError

O valor da sinalização --private-registry precisa estar em conformidade com o formato: hostname[:port]/repository/location e não pode começar com um esquema (como https://). O nome do host não pode ser localhost ou 127.0.0.1. O valor é usado pelo Kubernetes para buscar imagens.

Valores de sinalização de exemplo:

  • fictional.registry.example/repository/location
  • fictional.registry.example:10443/repository/location
  • 10.200.0.2/library

APME2000 KubeContextNotFoundError

Esse erro indica que não foi possível encontrar o kubecontext especificado.

Verifique se:

  • O arquivo KUBECONFIG existe.
  • O arquivo $HOME/.kube/config existe quando a variável de ambiente KUBECONFIG não é especificada.
  • O contexto existe no arquivo KUBECONFIG.

APME2001 UserClusterKubeconfigError

Esse erro indica que o kubeconfig do cluster de usuário não foi encontrado.

Verifique se:

  • O namespace cluster-CLUSTER_NAME existe no cluster de administrador.
  • Os objetos de cluster existem no namespace cluster-CLUSTER_NAME.
  • O secret CLUSTER_NAME-kubeconfig existe no namespace cluster-CLUSTER_NAME.
  • Você tem todas as permissões necessárias para acessar os objetos mencionados acima.

APME2002 ManagementCenterNotSchedulableError

Esse erro indica que a central de gerenciamento do Anthos não pode ser programada para execução nos nós de um cluster.

Esse erro geralmente ocorre quando o cluster de administrador não tem nenhum nó de trabalho e, por padrão, o cluster não programa cargas de trabalho no nó do plano de controle por motivos de segurança.

Para corrigir esse problema:

  1. [Preferencial] Adicione um NodePool de worker ao cluster de administrador.

    KUBECONFIG=${ADMIN_KUBECONFIG} kubectl apply -f <path/to/example-nodepool.yaml>

    Exemplo YAML:

    apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-admin
spec:
  clusterName: admin
  nodes:
  - address: <IP address of the worker node machine. e.g. 10.200.0.4>

  2. Remova o taint do plano de controle dos nós do plano de controle, o que permitirá a execução de cargas de trabalho que não sejam do sistema nos nós do plano de controle.

    OBSERVAÇÃO: considere os pontos negativos dessa solução:

    • Disponibilidade do plano de controle: a execução de cargas de trabalho extras aumenta a entropia nos nós do plano de controle. Se a máquina já está limitada por recursos, configurada incorretamente ou a carga de trabalho tem um comportamento inesperado, ela pode ter um impacto negativo no servidor da API Kubernetes.

    • Segurança: os contêineres não são um forte limite de segurança. Se uma carga de trabalho mal-intencionada sair do contêiner, ela poderá assumir o controle do plano de controle do cluster. Se o cluster estiver gerenciando outros clusters de usuário, o invasor poderá acessar as credenciais no cluster de administrador e ter controle sobre eles também.

    • Custo: o Anthos não cobra pelos nós do plano de controle enquanto o taint node-role.kubernetes.io/master:NoSchedule estiver presente. Depois que você remover o taint e permitir que as cargas de trabalho do usuário sejam executadas nos nós do plano de controle, eles serão cobrados como qualquer outro nó. Consulte a página de preços para informações detalhadas.

    Exemplo de comando para permitir que cargas de trabalho sejam executadas em todos os nós do plano de controle:

    KUBECONFIG=${ADMIN_KUBECONFIG} kubectl taint nodes --all node-role.kubernetes.io/master:NoSchedule-

APME2003 AdminClusterNotUpgradedError

Esse erro indica que é necessário fazer upgrade do cluster de administrador antes de fazer upgrade da Central de gerenciamento.

O centro de gerenciamento na nova versão do Anthos pode exigir a execução na nova versão do cluster de administrador.

Atualize o arquivo de configuração do cluster de administrador e execute o comando actl clusters baremetal upgrade admin para concluir o upgrade. Consulte Como fazer upgrade do cluster de administrador para ver instruções detalhadas.

APME3000 AISLoginClientValidationError

Obsoleto no Anthos 1.9

APME3001 PermissionDeniedError

O erro indica permissões insuficientes para executar a ação.

Para resolver o problema, faça o seguinte:

  • Identifique o papel atribuído.

    • Método 1: como usar o console do Anthos Management Center
      • Abra a guia Identity and Access no Console da Central de gerenciamento.
      • Acesse a guia Access na tela Identity and Access para ver o papel atribuído.
    • Método 2: usando o comando kubectl:
    kubectl get
    rolebinding,clusterrolebinding --all-namespaces -o jsonpath='{range
    .items[?(@.subjects[0].name=="{your
    account}")]}[{.roleRef.kind},{.roleRef.name}]{end}'

Example: kubectl get rolebinding,clusterrolebinding --all-namespaces -o
jsonpath='{range
.items[?(@.subjects[0].name=="foo@bar.com")]}[{.roleRef.kind},{.roleRef.name}]{end}'
[ClusterRole,anthos-platform-admin-read-only]

  • Consulte os papéis de autorização predefinidos e as permissões para ver as permissões disponíveis para os papéis predefinidos.

  • Se um papel de privilégio mais baixo for atribuído e um papel de privilégio mais alto for necessário para executar uma determinada ação ou se o papel for atribuído incorretamente, solicite que os administradores verifiquem se o acesso pode ser concedido.

  • Se o papel tiver permissões suficientes para a ação de acordo com os papéis de autorização predefinidos e as permissões e APME3001-PermissionDeniedError for visto incorretamente, informe um bug em anthos-private-mode-feedback@google.com.

APME3002 AuthMethodPreflightCheckError

O erro indica que a configuração do método de autenticação fornecida não pode passar na verificação de simulação.

Se você tiver fornecido uma configuração do OIDC:

  • Verifique se o URL do provedor OIDC está correto.
  • Verifique se a página de descoberta da configuração do OpenID https://<your OIDC provider URL>/.well-known/openid-configuration está acessível e contém uma configuração válida.
  • Se o provedor OIDC usar um certificado SSL autoassinado, insira-o no campo de certificado do provedor OIDC.

APME3003 UserCredentialNotFoundError

Esse erro indica que a ação solicitada não pode ser realizada sem uma credencial de usuário.

Para executar a solicitação, ative a autenticação ou peça ao administrador para ativar a autenticação. Consulte Como autenticar com o OIDC para configurar a autenticação do OIDC.

APME4001 ObservabilityOperatorUpgradeError

Esse erro indica que uma falha ocorreu durante o upgrade dos componentes de observabilidade (como parte do upgrade do Anthos). A pilha de observabilidade atualizada ainda pode funcionar, apesar do relatório desse erro.

Para verificar se a pilha de observabilidade atualizada funcionará, verifique o status da condição Installed no objeto default do tipo Observability no namespace anthos-management-center:

kubectl get -n anthos-management-center observability default -o jsonpath='
{.status.conditions[?(@..type=="Installed")].status}{"\n"}'

Se status for True, a pilha de observabilidade continuará funcionando. Os procedimentos de mitigação listados no relatório de erros são opcionais. Se o status não for True, execute os procedimentos de mitigação listados no relatório de erros.

A seguir