Resolver problemas de gestão de tráfego na malha de serviço na nuvem

Esta secção explica os problemas comuns do Cloud Service Mesh e como os resolver. Se precisar de assistência adicional, consulte o artigo Receber apoio técnico.

Erros de ligação ao servidor da API nos registos do Istiod

O Istiod não consegue contactar o apiserver se 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

Pode usar a string de expressão regular /error.*cannot list resource/ para encontrar este erro nos registos.

Normalmente, este erro é temporário e, se acedeu aos registos do proxy através de kubectl, o problema já pode estar resolvido. Normalmente, este erro é causado por eventos que tornam o servidor da API temporariamente indisponível, como quando um servidor da API que não está numa configuração de alta disponibilidade é reiniciado para uma atualização ou uma alteração da escalabilidade automática.

O contentor istio-init falha

Este problema pode ocorrer quando as regras iptables do pod não são aplicadas ao espaço de nomes de rede do pod. Isto pode dever-se a:

  • Uma instalação do istio-cni incompleta
  • Autorizações de pod de carga de trabalho insuficientes (autorização CAP_NET_ADMIN em falta)

Se usar o plug-in CNI do Istio, verifique se seguiu as instruções na íntegra. Verifique se o contentor istio-cni-node está pronto e consulte os registos. Se o problema persistir, estabeleça uma shell segura (SSH) no nó anfitrião e pesquise nos registos do nó comandos nsenter para ver se existem erros.

Se não usar o plug-in CNI do Istio, verifique se o pod de carga de trabalho tem autorização CAP_NET_ADMIN, que é definida automaticamente pelo injetor de sidecar.

Ligação recusada após o início do pod

Quando um pod é iniciado e connection refusedtenta estabelecer ligação a um ponto final, o problema pode ser que o contentor da aplicação tenha sido iniciado antes do contentor isto-proxy. Neste caso, o contentor da aplicação envia o pedido para istio-proxy, mas a ligação é recusada porque istio-proxy ainda não está a ouvir na porta.

Neste caso, pode:

  • Modifique o código de arranque da sua aplicação para fazer pedidos contínuos ao ponto final de verificação de estado istio-proxy até que a aplicação receba um código 200. O ponto final de funcionamento istio-proxy é:

    http://localhost:15020/healthz/ready

  • Adicione um mecanismo de pedido de repetição à carga de trabalho da aplicação.

A listagem de gateways devolve um resultado vazio

Sintoma: quando lista gateways através de kubectl get gateway --all-namespaces depois de criar com êxito um gateway de malha de serviços na nuvem, o comando devolve No resources found.

Este problema pode ocorrer no GKE 1.20 e posterior porque o controlador do GKE Gateway instala automaticamente o recurso Gateway.networking.x-k8s.io/v1alpha1 do GKE nos clusters. Para contornar o problema:

  1. Verifique se existem 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 apresentar entradas que não sejam gateways com o apiVersion networking.istio.io/v1beta1, use o nome completo do recurso ou os nomes abreviados distinguíveis no comando kubectl. Por exemplo, execute kubectl get gw ou kubectl get gateways.networking.istio.io em vez de kubectl get gateway para se certificar de que os gateways do Istio são apresentados.

Para mais informações sobre este problema, consulte o artigo Kubernetes Gateways e Istio Gateways.