Como resolver problemas de proxy/webhook do sidecar no Cloud Service Mesh

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

O Cloud 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.

  1. 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=REVISION apropriado, em que REVISION é o número de revisão do Cloud Service Mesh em istiod que corresponde à versão selecionada do Cloud Service Mesh. Para mais informações sobre rótulos de revisão, consulte Como injetar proxies secundários.

  2. 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. O comando inclui istio-sidecar-injector-asm-1187-26, que é específico para esta versão do Cloud Service Mesh. Use a revisão real se ela for diferente.

    kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1187-26 -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 verifique novamente o webhook e reinstale o pacote de CA.

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

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

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

  2. O endereço de descoberta está incorreto (erros "no healthy upstream")

  3. O endereço de descoberta fornecido ao injetor de arquivo secundário está incorreto. Se você encontrar 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 istiod.

  4. 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 informa uma atualização enviada do istiod) e lds é o serviço de descoberta de listener (que informa uma atualização rejeitada do 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 algo 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.
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 interferindo em um upgrade ou instalação. Verifique se todos os webhooks ainda estão no cluster e remova os webhooks que fazem referência a versões que não estão mais 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 particulares, a porta 15017 precisa estar aberta. Essa mensagem de erro indica que a porta 15017 pode não estar aberta. Verifique se as regras de firewall fornecem conectividade com o Istiod na porta 15017. Para mais informações, consulte Como abrir uma porta em um cluster particular.