Como resolver problemas de gerenciamento de tráfego no Cloud Service Mesh
Esta seção explica problemas comuns do Cloud Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.
Erros de conexão do servidor de API em registros 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 de iptables do pod não são aplicadas ao pod o mesmo namespace da rede. Isso pode ser causado por:
- Uma instalação incompleta do istio-cni
- Permissões insuficientes do pod da carga de trabalho (permissão
CAP_NET_ADMIN
ausente)
Se você usa o plug-in CNI do Istio, verifique se seguiu as instruções.
completamente. 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
e procure os comandos nsenter
nos registros do nó para verificar se há algum erro.
Se você não usar o plug-in da CNI do Istio, verifique se o pod da carga de trabalho
Permissão CAP_NET_ADMIN
, que é definida automaticamente pelo injetor do sidecar.
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:ao listar gateways usando kubectl get gateway --all-namespaces
depois de criar um gateway do Cloud 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.