Como resolver problemas de gerenciamento de tráfego no Anthos Service Mesh

Nesta seção, explicamos problemas comuns do Anthos Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

Erros de conexão do servidor da API nos registros do Istiod

O Istiod não consegue entrar em contato com apiserver se você vir erros semelhantes aos seguintes:

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

Use a string de expressão regular /error.*cannot list resource/ para encontrar esse erro nos registros.

Esse erro geralmente é transitório e, se você alcançou os registros de proxy usando kubectl, o problema pode já ter sido resolvido. Esse erro geralmente é causado por eventos que tornam o servidor da API temporariamente indisponível, como quando um servidor de API que não está em uma configuração de alta disponibilidade é reinicializado para uma atualização ou upgrade.

Falha do contêiner istio-init

Esse problema pode ocorrer quando as regras iptables do pod não são aplicadas ao namespace de rede do pod. Isso pode ser causado por:

  • Política de segurança de pods (PSP, na sigla em inglês) excessivamente restritiva
  • Uma instalação incompleta do istio-cni
  • Permissões insuficientes do pod da carga de trabalho (permissão CAP_NET_ADMIN ausente)

Se você usar uma política de segurança de pods que restrinja a permissão do CAP_NET_ADMIN, troque para usar o plug-in da CNI do Istio (em inglês).

Se você usa o plug-in CNI do Istio, verifique se seguiu as instruções por completo. Verifique se o contêiner istio-cni-node está pronto e confira os registros. Se o problema persistir, estabeleça um shell seguro (SSH) no nó host, procure os registros do nó para os comandos nsenter e veja se há algum erro.

Se você não usar o plug-in da CNI do Istio ou uma política de segurança de pods, verifique se o pod da carga de trabalho tem a permissão CAP_NET_ADMIN, que é definida automaticamente pelo injetor de arquivo secundário.

Conexão recusada após o início do pod

Quando um pod é iniciado e recebe connection refused ao tentar se conectar a um endpoint, o problema pode ser que o contêiner do aplicativo foi iniciado antes do contêiner isto-proxy. Nesse caso, o contêiner do aplicativo envia a solicitação para istio-proxy, mas a conexão é recusada porque istio-proxy ainda não está detectando na porta.

Nesse caso, você pode:

  • Modifique o código de inicialização do seu aplicativo para fazer solicitações contínuas ao endpoint de integridade istio-proxy até que o aplicativo receba um código 200. O endpoint de integridade istio-proxy é:

    http://localhost:15020/healthz/ready

  • Adicione um mecanismo de solicitação de nova tentativa à sua carga de trabalho do aplicativo.