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

Nesta seção, explicamos problemas comuns do Cloud Service Mesh e como resolver para resolvê-los com rapidez. 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 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 e procure os comandos nsenter nos registros do nó para verificar se há algum erro.

Se você não usar o plug-in CNI do Istio, verifique se o pod de carga de trabalho tem a permissão CAP_NET_ADMIN, que é definida automaticamente pelo injetor de 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 integridade istio-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 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:

  1. 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

  2. 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 comando kubectl. Por exemplo, execute kubectl get gw ou kubectl get gateways.networking.istio.io em vez de kubectl 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.