Como resolver problemas de proxy/webhook do arquivo secundário no Anthos Service Mesh

Nesta seção, explicamos problemas comuns do Anthos Service Mesh e como resolvê-los. Se você precisar de mais ajuda, consulte Como receber suporte.

O Anthos Service Mesh contém dois webhooks:

O webhook de validação garante que a configuração do Istio aplicada seja válida.
O webhook de mutação define a injeção automática de sidecar em novos pods.

Um problema de configuração em um desses webhooks pode fazer com que novos pods falhem ou kubectl apply gere mensagens de erro.

Problemas de injeção de arquivo secundário

A injeção de arquivo secundário não está funcionando corretamente quando você se depara com uma das seguintes situações:

Pods que estão programando sem arquivos secundários
Pods que precisam ter arquivos secundários injetados e nunca aparecem ao usar kubectl get pods, mas a réplica correspondente definida em kubectl get replicaset existe

Siga estas etapas para resolver problemas na injeção de arquivos secundários.

Verifique se o namespace ou pod tem o rótulo de injeção correto.

Se você estiver executando o Istio de única visualização (padrão), verifique se o namespace do pod ou pod tem o rótulo istio-injection=enabled.

Se você estiver executando o Istio de várias revisões (para migrações sem inatividade, vários planos de controle etc.), verifique se o namespace ou a especificação do pod têm o rótulo istio.io/rev=<var>REVISION</var> apropriado, em que REVISION é o número de revisão do Anthos Service Mesh em istiod que corresponde à versão selecionada do Anthos Service Mesh. Para mais informações sobre rótulos de revisão, consulte Como injetar proxies secundários.
Verifique se o webhook de injeção de arquivo secundário do istio está presente e tem um pacote de CA.

O webhook do injetor de arquivo secundário (usado para injeção automática de arquivo secundário) requer um pacote de CA para estabelecer conexões seguras com o servidor de API e o Istiod. Esse pacote de CA é reparado na configuração pelo Istiod, mas às vezes pode ser substituído (por exemplo, se você aplicar novamente a configuração do webhook).

É possível verificar a presença do pacote de CAs usando o seguinte comando:
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
Se a saída não estiver vazia, o pacote de CA estará configurado. Se o pacote de CA estiver ausente, reinicie o Istiod para que ele faça uma nova verificação do webhook e reinstale-o.
Verifique se há falhas de injeção do sidecar.

Se você tiver a injeção ativada, mas não estiver vendo a programação de pods, verifique o status do próximo nível de abstração mais alto. Por exemplo, se você estiver executando uma implantação, mas nenhum pod estiver programando, verifique o status dos conjuntos de réplicas correspondentes usando o seguinte comando:
```
kubectl -n my-namespace describe replicaset your-deployment-name
```
Se o conjunto de réplicas estiver presente, verifique se há erros no log de eventos na parte inferior da descrição. Se o erro estiver relacionado à injeção de arquivo secundário, verifique os registros do Istiod para saber o que está causando o erro.
Se o problema persistir, o problema pode ser um dos seguintes:
- Configuração incorreta passada para o injetor
- Problemas de configuração do firewall
- Um problema no próprio código do Istio
Consulte Solução de problemas do Istio (em inglês) para mais etapas de diagnóstico.

Proxies Envoy não recebem configuração do Istiod

Há vários problemas que podem impedir que os proxies recebam a configuração do Istiod.

O Istiod não enviará configurações aos proxies envoy quando houver problemas. Por exemplo, um problema do RBAC que impede que ele leia o recurso de configuração.
O endereço de descoberta está incorreto (erros "no healthy upstream")
O endereço de descoberta fornecido ao injetor de arquivo secundário está incorreto. Se você vir registros que mencionam gRPC config stream closed, no healthy upstream, verifique se o endereço de descoberta na malha ProxyConfig está correto e aponta para o serviço do Istiod.
Uma configuração inválida sendo enviada ao proxy. Nesse caso, a configuração é enviada ao proxy com sucesso, mas a configuração é inválida. Você verá mensagens repetidas como as seguintes:
```
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
```
Neste exemplo, cds é o serviço de descoberta de clusters (que relata uma atualização enviada do Istiod) e o lds é o serviço Listener Discovery, que informa uma atualização rejeitada por Istiod. Muitas vezes, você verá uma mensagem de erro anterior que explica o motivo da rejeição, que geralmente começa com um aviso sobre a configuração do envoy ou outro semelhante.

Para corrigir o problema, investigue a causa da configuração rejeitada. Uma causa comum são recursos EnvoyFilter inválidos. Se nenhum motivo for óbvio, envie um relatório do bug com um dump de configuração do proxy.

Falha na criação do pod

Se você observar que os pods não estão sendo criados com sucesso, procure mensagens de erro que indiquem pistas para o problema raiz usando o seguinte comando:

kubectl describe replicaset YOUR_REPLICA_SET

Mensagens de erro comuns do webhook

As mensagens de erro enviadas pelo comando kubectl apply podem fornecer uma dica sobre a causa raiz. Consulte a tabela a seguir para ver mensagens de erro comuns, as causas e possíveis resoluções.

Mensagem de erro	Causa	Resolução
`net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	Isso pode ser um problema de conectividade de rede.	Verifique se as regras de firewall fornecem conectividade com o Istiod na porta 15017.
`no endpoints available for service 'istiod'`	Isso pode ocorrer se o pod do Istiod não estiver disponível ou não estiver pronto.	Verifique se os pods do Istiod estão funcionando e prontos para funcionar.
`Service "istiod" not found`	Isso pode ocorrer se o serviço Istiod não existir.	Verifique se a instalação do Istio foi concluída e está correta.
`x509: certificate signed by unknown authority`	Talvez esse seja um problema de certificado do webhook.	Verifique se `caBundle` está configurado corretamente no webhook.