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
:
- Pronto:
True
indica que o serviço está configurado e pronto para receber o tráfego. - ConfigurationReady:
True
indica que a Configuração subjacente está pronta. ParaFalse
ouUnknown
, veja o status da revisão mais recente. - RoutesReady:
True
indica que a rota subjacente está pronta. EmFalse
ouUnknown
, veja o status da rota.
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 forTrue
:Verifique se a divisão de tráfego entre revisões do seu serviço corresponde a 100%:
gcloud run services describe SERVICE
Caso contrário, ajuste a divisão de tráfego usando o comando
gcloud run services update-traffic
.Tente verificar o status da revisão para as revisões que recebem tráfego.
IngressReady indica se o Ingress está pronto. Se
status
dessa condição não forTrue
, tente verificar o status de entrada.CertificateProvisioned indica se os certificados Knative foram provisionados. Se o
status
dessa condição não forTrue
, 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 forTrue
, 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 forTrue
, 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. 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_NAMESPACEem 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:
Execute o comando:
gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE
Substitua:
- DOMAIN pelo nome do domínio que você está usando;
- NAMESPACE pelo namespace usado para o mapeamento de domínio.
Nos resultados
yaml
desse comando, examine a condição do campoCertificateProvisioned
para determinar a natureza do erro.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
|
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.
|
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.
|
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
Substitua:
- 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.
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)
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
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.
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
Substitua:
- 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.
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
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.
Para resolver o erro de propagação de DNS:
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.
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.
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
Substitua:
- 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 identidade da carga de trabalho 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 Identidade da carga de trabalho.