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.
A listagem de gateways retorna vazia
Sintoma: quando você lista Gateways usando kubectl get gateway --all-namespaces
após criar um gateway do Anthos Service Mesh, o comando retorna
No resources found
.
Esse problema pode acontecer no GKE 1.20 e posterior porque o controlador de gateway do GKE
instala automaticamente o recurso Gateway.networking.x-k8s.io/v1alpha1
do GKE
nos clusters. Para solucionar o problema, siga estas etapas:
Verifique se há vários recursos personalizados de gateway no cluster:
kubectl api-resources | grep gateway
Exemplo de saída:
gateways gw networking.istio.io/v1beta1 true Gateway gatewayclasses gc networking.x-k8s.io/v1alpha1 false GatewayClass gateways gtw networking.x-k8s.io/v1alpha1 true Gateway
Se a lista mostrar entradas diferentes de Gateways com
apiVersion
networking.istio.io/v1beta1
, use o nome completo do recurso ou os nomes curtos distintivos no comandokubectl
. Por exemplo, executekubectl get gw
oukubectl get gateways.networking.istio.io
em vez dekubectl get gateway
para verificar se os gateways do istio estão listados.
Para mais informações sobre esse problema, consulte Gateways do Kubernetes e gateways do Istio.