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

Nesta seção, explicamos problemas comuns do Cloud Service Mesh e como resolver para resolvê-los com rapidez. 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

Se você provisionou o Cloud Service Mesh gerenciado, entre em contato com o suporte.

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 deveriam ter arquivos secundários injetados nunca aparecem ao usar kubectl get pods, mas o conjunto de réplicas correspondente da kubectl get replicaset já 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, planos de controle etc.), verifique se o namespace ou a especificação do pod o rótulo istio.io/rev=REVISION apropriado, em que REVISION é o número de revisão do Cloud Service Mesh em istiod que corresponda à versão do Cloud Service Mesh selecionada. Para mais informações sobre rótulos de revisão, consulte Como injetar proxies sidecar.

  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 inclui istio-sidecar-injector-asm-1225-1, que é específica 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-1225-1 -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 vai enviar configurações aos proxies envoy quando houver problemas, como 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ê vê registros que mencionam gRPC config stream closed, no healthy upstream, verifique se o endereço de descoberta na malha ProxyConfig está correta 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 cluster (que informa 1 atualização enviada de istiod) e lds é o serviço de descoberta do listener (indica que uma atualização foi rejeitada de istiod). Muitas vezes, você verá um 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 O Cloud Service Mesh que foi desinstalado pode estar interferindo em uma fazer o upgrade ou a 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.