Solução de problemas

Nesta página, fornecemos estratégias de solução de problemas e também soluções para alguns erros comuns.

Ao solucionar problemas de fornecimento do Knative, primeiro confirme se é possível executar a imagem do contêiner localmente.

Se o aplicativo não estiver sendo executado localmente, será preciso diagnosticar e corrigir isso. Use o Cloud Logging para ajudar a depurar um projeto implantado.

Ao solucionar problemas de veiculação do Knative, consulte as seções a seguir para possíveis soluções.

Como verificar a saída da linha de comando

Se você usar a Google Cloud CLI, verifique a resposta ao comando para ver se foi bem-sucedida. Por exemplo, se sua implementação foi finalizada sem sucesso, haverá uma mensagem de erro descrevendo o motivo da falha.

As falhas de implantação são provavelmente causadas por um manifesto mal configurado ou um comando incorreto. Por exemplo, a saída a seguir diz que você precisa configurar o percentual de tráfego de rota para somar 100.

Error from server (InternalError): error when applying patch:</p><pre>{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"serving.knative.dev/v11\",\"kind\":\"Route\",\"metadata\":{\"annotations\":{},\"name\":\"route-example\",\"namespace\":\"default\"},\"spec\":{\"traffic\":[{\"configurationName\":\"configuration-example\",\"percent\":50}]}}\n"}},"spec":{"traffic":[{"configurationName":"configuration-example","percent":50}]}}
to:
&{0xc421d98240 0xc421e77490 default route-example STDIN 0xc421db0488 264682 false}
for: "STDIN": Internal error occurred: admission webhook "webhook.knative.dev" denied the request: mutation failed: The route must have traffic percent sum equal to 100.
ERROR: Non-zero return code '1' from command: Process exited with status 1

Como verificar os registros do serviço

É possível usar o Cloud Logging ou a página do Knative serving no Console do Google Cloud para verificar registros de solicitações e de contêineres. Para detalhes completos, leia Como gerar e visualizar registros.

Se você usa o Cloud Logging, o recurso que você precisa filtrar é o Kubernetes Container.

Como verificar o status do serviço

Execute o seguinte comando para receber o status de um serviço do Knative serving implantado:

gcloud run services describe SERVICE

É possível adicionar --format yaml(status) ou --format json(status) para ver o status completo. Por exemplo:

gcloud run services describe SERVICE --format 'yaml(status)'

As condições em status podem ajudar a localizar a causa da falha. As condições podem incluir True, False ou Unknown:

Para ver mais detalhes sobre as condições de status, consulte Forma de erro em Knative.

Como verificar o status da rota

Cada serviço de veiculação do Knative gerencia uma rota que representa o estado de roteamento atual em relação às revisões do serviço.

Você pode verificar o status geral do trajeto observando o status do serviço:

gcloud run services describe SERVICE --format 'yaml(status)'

A condição RoutesReady em status fornece o status da rota.

Você pode diagnosticar melhor o status da rota executando o seguinte comando:

kubectl get route SERVICE -o yaml

As condições em status fornecem o motivo da falha. nas situações a seguir.

  • Ready indica se o serviço está configurado e tem back-ends disponíveis. Se for true, a rota estará configurada corretamente.

  • AllTrafficAssigned indica se o serviço está configurado corretamente e tem back-ends disponíveis. Se o status desta condição não for True:

  • IngressReady indica se o Ingress está pronto. Se status dessa condição não for True, tente verificar o status de entrada.

  • CertificateProvisioned indica se os certificados Knative foram provisionados. Se o status dessa condição não for True, tente solucionar problemas de TLS gerenciado.

Para ver mais detalhes sobre as condições de status, consulte Condições e relatórios de erros do Knative.

Como verificar o status de ingresso

O Knative serving usa um serviço de balanceador de carga chamado istio-ingressgateway, responsável por gerenciar o tráfego de entrada de fora do cluster.

Para conseguir o IP externo do balanceador de carga, execute o seguinte comando:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Substitua ASM-INGRESS-NAMESPACE pelo namespace em que a entrada do Cloud Service Mesh está localizada. Especifique istio-system se você instalou o Cloud Service Mesh usando a configuração padrão.

A resposta resultante será semelhante a:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

em que o valor EXTERNAL-IP é o endereço IP externo do balanceador de carga.

Se o EXTERNAL-IP for pending, consulte EXTERNAL-IP é pending por um longo tempo abaixo.

Como verificar o status da revisão

Para receber a revisão mais recente do serviço de fornecimento Knative, execute o seguinte comando:

gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'

Execute o seguinte comando para conferir o status de uma revisão específica de veiculação do Knative:

gcloud run revisions describe REVISION

Adicione --format yaml(status) ou --format json(status) para ver o status completo:

gcloud run revisions describe REVISION --format yaml(status)

As condições em status fornecem os motivos de uma falha. nas situações a seguir.

  • Ready indica se os recursos do ambiente de execução estão prontos. Se for true, a revisão será configurada corretamente.
  • ResourcesAvailable indica se os recursos subjacentes do Kubernetes foram provisionados. Se o status desta condição não for True, tente verificar o status do pod.
  • ContainerHealthy indica se a verificação de prontidão da revisão foi concluída. Se o status desta condição não for True, tente verificar o status do pod.
  • Ativo indica se a revisão está recebendo tráfego.

Se status de qualquer uma dessas condições não for True, tente verificar o status do pod.

Como verificar o status do pod

Para conseguir os pods para todas as suas implantações:

kubectl get pods

Isso listará todos os Pods com status breve. Por exemplo:

NAME                                                      READY     STATUS             RESTARTS   AGE
configuration-example-00001-deployment-659747ff99-9bvr4   2/2       Running            0          3h
configuration-example-00002-deployment-5f475b7849-gxcht   1/2       CrashLoopBackOff   2          36s

Escolha um e use o comando a seguir para ver informações detalhadas sobre o status. Alguns campos úteis são conditions e containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP está como <pending> há muito tempo

Às vezes, não é possível ter um endereço IP externo logo depois de criar um cluster. Em vez disso, você verá o IP externo como pending. Por exemplo, você talvez consiga ver isso invocando o comando:

Para conseguir o IP externo do balanceador de carga, execute o seguinte comando:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Substitua ASM-INGRESS-NAMESPACE pelo namespace em que a entrada do Cloud Service Mesh está localizada. Especifique istio-system se você instalou o Cloud Service Mesh usando a configuração padrão.

A resposta resultante será semelhante a:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

em que o valor EXTERNAL-IP é o endereço IP externo do balanceador de carga.

Isso pode significar que você ficou sem cota de endereços IP externos no Google Cloud. Verifique a possível causa invocando:

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE
 em que INGRESS_NAMESPACE é o namespace da entrada do ASM, que, por padrão, é "istio-system". Isso gera uma saída semelhante a esta: 
Name:                     istio-ingressgateway
Namespace:                INGRESS_NAMESPACE
Labels:                   app=istio-ingressgateway
                          istio=ingressgateway
                          istio.io/rev=asm-1102-3
                          operator.istio.io/component=IngressGateways
                          operator.istio.io/managed=Reconcile
                          operator.istio.io/version=1.10.2-asm.3
                          release=istio
Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","app":"istio-ingressgateway","...
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     LoadBalancer
IP:                       10.XX.XXX.XXX
LoadBalancer Ingress:     35.XXX.XXX.188
Port:                     http2  80/TCP
TargetPort:               80/TCP
NodePort:                 http2  31380/TCP
Endpoints:                XX.XX.1.6:80
Port:                     https  443/TCP
TargetPort:               443/TCP
NodePort:                 https  3XXX0/TCP
Endpoints:                XX.XX.1.6:XXX
Port:                     tcp  31400/TCP
TargetPort:               3XX00/TCP
NodePort:                 tcp  3XX00/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-pilot-grpc-tls  15011/TCP
TargetPort:               15011/TCP
NodePort:                 tcp-pilot-grpc-tls  32201/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-citadel-grpc-tls  8060/TCP
TargetPort:               8060/TCP
NodePort:                 tcp-citadel-grpc-tls  31187/TCP
Endpoints:                XX.XX.1.6:XXXX
Port:                     tcp-dns-tls  853/TCP
TargetPort:               XXX/TCP
NodePort:                 tcp-dns-tls  31219/TCP
Endpoints:                10.52.1.6:853
Port:                     http2-prometheus  15030/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-prometheus  30944/TCP
Endpoints:                10.52.1.6:15030
Port:                     http2-grafana  15031/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-grafana  31497/TCP
Endpoints:                XX.XX.1.6:XXXXX
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age                  From                Message
  ----    ------                ----                 ----                -------
  Normal  EnsuringLoadBalancer  7s (x4318 over 15d)  service-controller  Ensuring load balancer

Se a saída contiver uma indicação de que a cota IN_USE_ADDRESSES foi excedida, será possível solicitar uma cota extra navegando até a página IAM e Admin no Console do Google Cloud para solicitar uma cota extra.

O gateway continuará tentando até que um endereço IP externo seja atribuído. Isso pode levar alguns minutos.

Solução de problemas de domínios personalizados e TLS gerenciado

Use as etapas listadas abaixo para resolver problemas gerais de domínios personalizados e do recurso de certificados TLS gerenciados.

Domínios personalizados para redes internas e particulares

Se você associou um domínio personalizado ao cluster ou aos serviços do Knative serving em um rede privada e interna, você precisa desativar certificados TLS gerenciados Caso contrário, a configuração do seu domínio não atingirá o estado ready. Por padrão, o balanceador de carga interno não pode se comunicar externamente com a autoridade de certificação.

Verificar o status de um mapeamento de domínio específico

Para verificar o status de um mapeamento de domínio específico:

  1. Execute o comando:

    gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE

    Substituir

    • DOMAIN pelo nome do domínio que você está usando;
    • NAMESPACE pelo namespace usado para o mapeamento de domínio.

  2. Nos resultados yaml desse comando, examine a condição do campo CertificateProvisioned para determinar a natureza do erro.

  3. Se um erro for exibido, ele deverá corresponder a um dos erros nas tabelas abaixo. Siga as sugestões contidas nelas para resolver o problema.

Erros de configuração do usuário

Código do erro Detalhes
DNSErrored Mensagem: O registro DNS não está configurado corretamente. É necessário mapear o domínio [XXX] para o IP XX.XX.XX.XX

Siga as instruções fornecidas para configurar o Registro DNS corretamente.

RateLimitExceeded Mensagem: acme: urn:ietf:params:acme:error:rateLimited: erro ao criar um novo pedido
:: muitos certificados já foram emitidos para o conjunto exato de domínios:
test.your-domain.com:
consulte https://letsencrypt.org/docs/rate-limits/ (link em inglês)

A cota da Let's Encrypt foi excedida. Você precisa aumentar a cota de certificado Let's Encrypt para esse host.

InvalidDomainMappingName Mensagem: DomainMapping name %s não pode ser igual ao Route URL host %s.

O nome de DomainMapping não pode ser exatamente igual ao host da rota para o qual ele é mapeado. Use um domínio diferente para o nome de DomainMapping.

ChallengeServingErrored Mensagem: O sistema não conseguiu atender à solicitação HTTP01.

Esse erro pode ocorrer se o serviço istio-ingressgateway não conseguir atender à solicitação da Let's Encrypt para validar a propriedade do domínio.

  1. Verifique se o serviço istio-ingressgateway pode ser acessado pela Internet pública sem usar a nuvem privada virtual.
  2. Verifique se o serviço istio-ingressgateway aceita solicitações do URL http://DOMAIN/.well-known/acme-challenge/... em que DOMAIN é o domínio que está sendo validado.

Erros do sistema

Código do erro Detalhes
OrderErrored

AuthzErrored

ChallengeErrored

Esses três tipos de erros ocorrerão se a verificação de propriedade do domínio pela Let's Encrypt falhar.

Esses erros geralmente são temporários e serão tentados novamente pelo serviço Knative.

O atraso de novas tentativas é exponencial, com no mínimo 8 segundos e no máximo 8 horas.

Se você quiser repetir a ação manualmente, exclua o pedido com falha.

kubectl delete order DOMAIN -n NAMESPACE

ACMEAPIFailed Esse tipo de erro ocorre quando a veiculação do Knative falha ao chamar a Let's Encrypt. Esse geralmente é um erro temporário, então o serviço Knative vai tentar novamente.

Se você quiser repetir a ação manualmente, exclua o pedido com falha.

kubectl delete order DOMAIN -n NAMESPACE

UnknownErrored Esse erro indica um problema desconhecido no sistema, o que acontece muito raramente no Cluster do GKE. Se isso ocorrer, entre em contato com o suporte do Cloud para receber ajuda relacionada à depuração.

Verificar status do pedido

O status do pedido registra o processo de interação com a Let's Encrypt e, portanto, pode ser usado para depurar os problemas relacionados à Let's Encrypt. Se necessário, verifique o status do pedido executando este comando:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Substituir

  • DOMAIN pelo nome do domínio que você está usando;
  • NAMESPACE pelo namespace usado para o mapeamento de domínio.

Os resultados conterão os certificados emitidos e outras informações se o pedido foi bem-sucedido.

Tempo limite do pedido

Um objeto Order será expirado após 20 minutos se ainda não for possível conseguir os certificados.

  1. Verifique o status de mapeamento do domínio. Para um tempo limite, procure uma mensagem de erro como esta na saída de status:

    order (test.your-domain.com) timed out (20.0 minutes)

  2. Uma causa comum do problema de tempo limite é que seu registro DNS não está configurado corretamente para mapear o domínio que você está usando para o endereço IP do serviço de entrada. Execute o seguinte comando para verificar o registro DNS:

    host DOMAIN

  3. Verifique o endereço IP externo do balanceador de carga de entrada:

    Para conseguir o IP externo do balanceador de carga, execute o seguinte comando:

    kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

    Substitua ASM-INGRESS-NAMESPACE pelo namespace em que a entrada do Cloud Service Mesh está localizada. Especifique istio-system se você instalou o Cloud Service Mesh usando a configuração padrão.

    A resposta resultante será semelhante a:

    NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

    em que o valor EXTERNAL-IP é o endereço IP externo do balanceador de carga.

    Se o endereço IP externo do seu domínio não corresponder ao endereço IP de entrada, reconfigure o registro DNS para mapear para o endereço IP correto.

  4. Depois que o registro DNS (atualizado) entrar em vigor, execute o seguinte comando para excluir o objeto Order e acionar novamente o processo de solicitação de um certificado TLS:

    kubectl delete order DOMAIN -n NAMESPACE

    Substituir

    • DOMAIN pelo nome do domínio que você está usando;
    • NAMESPACE pelo namespace que você usa.

Falhas de autorização

As falhas de autorização podem ocorrer quando um registro DNS não é propagado globalmente a tempo. Como resultado, a Let's Encrypt não verifica a propriedade do domínio.

  1. Verifique o status do pedido. Encontre o link de autenticação no campo acmeAuthorizations do status. O URL terá esta aparência:

    https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827

  2. Abra o link. Se você vir uma mensagem semelhante a: 

    urn:ietf:params:acme:error:dns

    o problema ocorre devido à propagação de DNS incompleta.

  3. Para resolver o erro de propagação de DNS:

    1. Verifique o endereço IP externo do balanceador de carga de entrada:

      Para conseguir o IP externo do balanceador de carga, execute o seguinte comando:

      kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

      Substitua ASM-INGRESS-NAMESPACE pelo namespace em que a entrada do Cloud Service Mesh está localizada. Especifique istio-system se você instalou o Cloud Service Mesh usando a configuração padrão.

      A resposta resultante será semelhante a:

      NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

      em que o valor EXTERNAL-IP é o endereço IP externo do balanceador de carga.

    2. Verifique o registro DNS do domínio executando o seguinte comando: 

      host DOMAIN

      Se o endereço IP do registro DNS não corresponder ao IP externo do balanceador de carga de entrada, configure o registro DNS para mapear o domínio do usuário ao IP externo.

    3. Depois que o registro DNS (atualizado) entrar em vigor, execute o seguinte comando para excluir o objeto Order e reativar o processo de solicitação de um certificado TLS:

      kubectl delete order DOMAIN -n NAMESPACE

    Substituir

    • DOMAIN pelo nome do domínio que você está usando;
    • NAMESPACE pelo namespace usado para o mapeamento de domínio.

Falha na implantação no cluster particular: falha ao chamar o erro webhook

O firewall pode não estar configurado corretamente, se a implantação em um cluster particular falhar com a mensagem:

Error: failed calling webhook "webhook.serving.knative.dev": Post
https://webhook.knative-serving.svc:443/?timeout=30s: context deadline exceeded (Client.Timeout
exceeded while awaiting headers)

Para informações sobre as alterações de firewall necessárias para dar suporte à implantação em um cluster particular, consulte ativação de implantações em um cluster particular.

Status do relatório de serviços de IngressNotConfigured

Se IngressNotConfigured aparecer no status do serviço, talvez seja necessário reiniciar a implantação istiod no namespace istio-system se você estiver usando o plano de controle de cluster Cloud Service Mesh. Esse erro, que foi observado com mais frequência no 1.14 do Kubernetes, pode ocorrer se os serviços forem criados antes que o istiod esteja pronto para começar o trabalho de reconciliação do VirtualServices e envio da configuração do envoy para os gateways de entrada.

Para corrigir esse problema, reduza o escalonamento horizontal da implantação e tente novamente usando comandos semelhantes aos seguintes:

kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1

Contagem de solicitações e métricas de latência de solicitação ausentes

O serviço poderá não informar a contagem de solicitações de revisão e as métricas de latência de solicitação se você tiver a Federação de Identidade da Carga de Trabalho para GKE ativada e não tiver concedido determinadas permissões à conta de serviço usada pelo serviço.

É possível corrigir isso seguindo as etapas na seção Como ativar métricas em um cluster com a federação de identidade da carga de trabalho para o GKE.