Solução de problemas do App Mesh para o Kubernetes

Este tópico detalha problemas comuns que podem ser enfrentados ao usar o App Mesh com o Kubernetes.

Os recursos do App Mesh criados no Kubernetes não podem ser encontrados no App Mesh

Sintomas

Você criou os recursos do App Mesh usando a definição personalizada de recursos (CRD) do Kubernetes, mas os recursos que você criou não são visíveis no App Mesh quando você usa as APIs ou. AWS Management Console

Resolução

A causa provável é um erro no controlador Kubernetes para o App Mesh. Para obter mais informações, consulte Solução de problemas em GitHub. Verifique se há erros ou avisos nos logs do controlador que indiquem que o controlador não conseguiu criar nenhum recurso.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

Os pods estão falhando nas verificações de prontidão e liveness depois que o sidecar do Envoy é injetado

Sintomas

Anteriormente, o pod do seu aplicativo foi executado com êxito, mas depois que o sidecar do Envoy é injetado em um pod, as verificações de prontidão e liveness começam a falhar.

Resolução

Certifique-se de que o contêiner Envoy que foi injetado no pod tenha sido inicializado com o serviço de gerenciamento Envoy do App Mesh. É possível verificar quaisquer erros referenciando os códigos de erro em Envoy desconectado do serviço de gerenciamento do App Mesh Envoy com texto de erro. É possível usar o comando a seguir para inspecionar os logs do Envoy para o pod relevante.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

Os pods não estão se registrando ou cancelando o registro como instâncias do AWS Cloud Map

Sintomas

Seus pods do Kubernetes não estão sendo registrados ou cancelados AWS Cloud Map como parte de seu ciclo de vida. Um pod pode iniciar com sucesso e estar pronto para atender ao tráfego, mas não receber nenhum. Quando um pod é encerrado, os clientes ainda podem reter seu endereço IP e tentar enviar tráfego para ele, falhando.

Resolução

Esse é um problema conhecido. Para obter mais informações, consulte o problema em que os pods não são registrados/cancelados automaticamente no Kubernetes. AWS Cloud Map GitHub Devido à relação entre pods, nós virtuais do App Mesh e AWS Cloud Map recursos, o controlador do App Mesh para Kubernetes pode ficar dessincronizado e perder recursos. Por exemplo, isso pode acontecer se um recurso de nó virtual for excluído do Kubernetes antes de encerrar os pods associados.

Para mitigar esse problema:

• Verifique se está executando a versão mais recente do controlador do App Mesh para Kubernetes.

• Verifique se AWS Cloud Map namespaceName e serviceName estão corretos na definição do nó virtual.

• Certifique-se de excluir todos os pods associados antes de excluir a definição do nó virtual. Se precisar de ajuda para identificar quais pods estão associados a um nó virtual, consulte Não é possível determinar onde um pod para um recurso do App Mesh está em execução.

• Se o problema persistir, execute o comando a seguir para inspecionar os logs do controlador em busca de erros que possam ajudar a revelar o problema subjacente.

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• Considere usar o comando a seguir para reiniciar os pods do controlador. Isso pode corrigir problemas de sincronização.

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

Não é possível determinar onde um pod para um recurso do App Mesh está em execução

Sintomas

Ao executar o App Mesh em um cluster do Kubernetes, um operador não pode determinar onde uma workload, ou pod, está sendo executada para um determinado recurso do App Mesh.

Resolução

Os recursos do pod do Kubernetes são anotados com a malha e o nó virtual aos quais estão associados. É possível consultar quais pods estão sendo executados para um determinado nome de nó virtual com o comando a seguir.

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

Não é possível determinar em qual recurso do App Mesh um pod está sendo executado

Sintomas

Ao executar o App Mesh em um cluster Kubernetes, um operador não pode determinar com qual recurso do App Mesh um determinado pod está sendo executado.

Resolução

Os recursos do pod do Kubernetes são anotados com a malha e o nó virtual aos quais estão associados. É possível gerar os nomes da malha e do nó virtual consultando o pod diretamente usando o comando a seguir.

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

Os Envoys do cliente não conseguem se comunicar com o serviço de gerenciamento do App Mesh Envoy com o IMDSv1 desativado

Sintomas

Quando o IMDSv1 está desativado, os Envoys do cliente não conseguem se comunicar com o ambiente de gerenciamento do App Mesh (Envoy Management Service). O suporte IMDSv2 não está disponível na versão do App Mesh Envoy anterior a v1.24.0.0-prod.

Resolução

Para resolver esse problema, você pode realizar uma das três seguintes ações.

• Atualize para a versão App Mesh Envoy v1.24.0.0-prod ou posterior, que tem suporte IMDSv2.

• Reative o IMDSv1 na instância em que o Envoy está sendo executado. Para obter instruções sobre restauração IMDSv1, consulte Configurar as opções de metadados da instância.

• Se seus serviços estiverem em execução no Amazon EKS, é recomendável usar perfis do IAM para contas de serviço (IRSA) para obter credenciais. Para obter instruções sobre como ativar o IRSA, consulte Perfis do IAM para contas de serviço.

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.

O IRSA não funciona no contêiner da aplicação quando o App Mesh está ativado e o Envoy é injetado

Sintomas

Quando o App Mesh é habilitado em um cluster do Amazon EKS com a ajuda do controlador App Mesh para o Amazon EKS, o Envoy e os contêineres proxyinit são injetados no pod da aplicação. A aplicação não é capaz de assumir o IRSA e, em vez disso, assume o node role. Ao descrevemos os detalhes do pod, percebemos que tanto a variável de ambiente AWS_WEB_IDENTITY_TOKEN_FILE quanto a AWS_ROLE_ARN não estão incluídas no contêiner do aplicação.

Resolução

Se uma variáveis de ambiente AWS_WEB_IDENTITY_TOKEN_FILE ou AWS_ROLE_ARN forem definidas, o webhook ignorará o pod. Não forneça nenhuma dessas variáveis e o webhook se encarregará de injetá-las para você.

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

Se o problema ainda não tiver sido resolvido, considere abrir um GitHub problema ou entre em contato com o AWS Support.