Resolva problemas de proxy/webhook sidecar no Cloud Service Mesh

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

O Cloud Service Mesh contém dois webhooks:

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

Um problema de configuração num destes webhooks pode fazer com que os novos pods não sejam iniciados ou kubectl apply gerem mensagens de erro.

Problemas de injeção de Sidecar

Se tiver aprovisionado o Cloud Service Mesh gerido, contacte o apoio técnico.

A injeção de sidecar não está a funcionar corretamente se vir alguma das seguintes situações:

pods que estão a agendar sem sidecars
Os pods que devem ter sidecars injetados nunca aparecem quando usam kubectl get pods, mas o conjunto de réplicas correspondente de kubectl get replicaset existe.

Siga os passos abaixo para resolver problemas de injeção de sidecar.

Verifique se o seu espaço de nomes ou pod tem a etiqueta de injeção correta.

Se estiver a executar o Istio de revisão única (predefinição), verifique se o seu espaço de nomes ou especificação de pod têm a etiqueta istio-injection=enabled.

Se estiver a executar o Istio de várias revisões (para migrações sem tempo de inatividade, vários planos de controlo, etc.), verifique se a especificação do seu espaço de nomes ou pod tem a etiqueta istio.io/rev=REVISION adequada, em que REVISION é o número de revisão do Cloud Service Mesh em istiod que corresponde à versão do Cloud Service Mesh selecionada. Para mais informações sobre as etiquetas de revisão, consulte o artigo Injetar proxies sidecar.
Verifique se o webhook de injeção do sidecar do Istio está presente e tem um pacote de CA.

O webhook do injetor de sidecar (que é usado para a injeção automática de sidecar) requer um pacote de AC para estabelecer ligações seguras com o servidor da API e istiod. Este pacote de AC é corrigido na configuração por istiod, mas, por vezes, pode ser substituído (por exemplo, se reaplicar a configuração do webhook).

Pode validar a presença do pacote de AC através do seguinte comando. O comando inclui istio-sidecar-injector-asm-1246-12, que é específico desta versão do Cloud Service Mesh. Certifique-se de que usa a revisão real, se for diferente.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1246-12 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
Se o resultado não estiver vazio, o pacote de AC está configurado. Se o pacote de AC estiver em falta, reinicie o istiod para que volte a analisar o webhook e reinstale o pacote de AC.
Verifique se existem falhas de injeção de sidecar.

Se tiver a injeção ativada, mas não estiver a ver o agendamento de pods, verifique o estado do nível de abstração seguinte. Por exemplo, se estiver a executar uma implementação, mas não estiver a agendar pods, verifique o estado dos conjuntos de réplicas correspondentes através do seguinte comando:
```
kubectl -n my-namespace describe replicaset your-deployment-name
```
Se o conjunto de réplicas estiver presente, verifique se existem erros no registo de eventos na parte inferior da descrição. Se o erro estiver relacionado com a injeção de sidecar, verifique os registos istiod para ver uma indicação do que está a causar o erro.
Se o problema persistir, o problema pode dever-se a uma das seguintes situações:
- Configuração incorreta transmitida ao injetor
- Problemas de configuração da firewall
- Um problema no próprio código do Istio
Consulte o artigo Resolva problemas do Istio para ver passos de diagnóstico adicionais.

Os proxies Envoy não recebem configuração de `istiod`

Existem vários problemas que podem impedir os proxies de receberem a configuração de istiod.

istiod não envia a configuração para os proxies do Envoy se tiver problemas, como um problema de RBAC que o impeça de ler o respetivo recurso de configuração.
O endereço de descoberta está incorreto (erros "no healthy upstream")
O endereço de descoberta fornecido ao injetor sidecar está incorreto. Se vir registos que mencionam gRPC config stream closed, no healthy upstream, verifique se o endereço de deteção na malha ProxyConfig está correto e aponta para o seu serviço istiod.
Configuração inválida enviada para o proxy. Neste caso, a configuração é enviada com êxito para o proxy, mas é inválida. Vai ver mensagens repetidas semelhantes às 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 deteção de clusters (que comunica 1 atualização enviada a partir de istiod) e lds é o serviço de deteção de ouvintes (que comunica 1 atualização rejeitada a partir de istiod). Muitas vezes, é apresentada uma mensagem de erro anterior que explica o motivo da rejeição, que normalmente começa com um aviso sobre a configuração do Envoy ou semelhante.

Para corrigir o problema, investigue a causa da configuração rejeitada. Uma causa comum são os recursos EnvoyFilter incorretos. Se não houver um motivo óbvio, envie um relatório de erro com uma descarga da configuração do proxy.

Falhas na criação de agrupamentos

Se observar que os pods não estão a ser criados com êxito, procure mensagens de erro que possam dar pistas sobre o problema principal através do seguinte comando:

kubectl describe replicaset YOUR_REPLICA_SET

Mensagens de erro de webhook comuns

As mensagens de erro geradas pelo comando kubectl apply podem dar uma pista sobre a respetiva causa principal. Consulte a tabela seguinte para ver mensagens de erro comuns, as respetivas causas e potenciais resoluções.

Mensagem de erro	Causa	Resolução
`net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	Este problema pode estar relacionado com a ligação de rede.	Certifique-se de que as regras da firewall fornecem conetividade ao `istiod` na porta 15017.
`no endpoints available for service 'istiod'`	Isto pode ocorrer se o pod `istiod` não estiver disponível ou não estiver pronto.	Verifique os pods `istiod` para garantir que estão em execução e prontos.
`Service "istiod" not found`	Isto pode ocorrer se o serviço `istiod` não existir.	Verifique se a instalação do Istio foi bem-sucedida e está correta.
`x509: certificate signed by unknown authority`	Este problema pode estar relacionado com o certificado de webhook.	Verifique se o `caBundle` está definido corretamente no webhook.
`Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again.`	Um webhook de validação de uma versão antiga do Istio ou do Cloud Service Mesh que foi desinstalado pode estar a interferir com uma atualização ou uma instalação.	Verifique se todos os webhooks ainda estão no cluster e remova todos os webhooks que referenciam versões que já não estão instaladas.
`Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded`	Para clusters privados, a porta 15017 tem de estar aberta. Esta mensagem de erro indica que a porta 15017 pode não estar aberta.	Certifique-se de que as regras da firewall fornecem conetividade ao Istiod na porta 15017. Para mais informações, consulte o artigo Abrir uma porta num cluster privado.