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 integridadeistio-proxy
é:http://localhost:15020/healthz/ready
Adicione um mecanismo de solicitação de nova tentativa à sua carga de trabalho do aplicativo.