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 emkubectl 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 emistiod
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 malhaProxyConfig
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 olds
é 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. |