Esta é a versão Arquivada da documentação. O período de avaliação gratuita terminou em 30 de setembro de 2021.

Consulte a documentação de versão do GA para detalhes sobre como instalar o Cloud Run for Anthos como um componente da frota do Anthos com o Anthos Service Mesh.

Versões disponíveis

Mais recente
Arquivar

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 do Cloud Run for Anthos, 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 do Cloud Run for Anthos, consulte as seções a seguir para possíveis soluções para o problema.

Consulte também a página de problemas conhecidos para ver detalhes sobre os problemas conhecidos no Cloud Run para Anthos e como resolvê-los.

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

Use o Cloud Logging ou a página do Cloud Run for Anthos no Console do Google Cloud para verificar os registros de solicitação e de contêiner. 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 ver o status de um serviço do Cloud Run for Anthos 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. Para False ou "Desconhecido", você precisa ver o status da revisão mais recente.
RoutesReady: True indica que a rota subjacente está pronta. Para False ou "Desconhecido", você deve ver 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 do Cloud Run for Anthos 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:
- 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 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 Cloud Run for Anthos usa um serviço do Kubernetes do balanceador de carga chamado istio-ingress que é responsável por processar o tráfego de entrada vindo de fora do cluster.

Para conseguir o endereço IP externo do Ingress, use

kubectl get svc istio-ingress -n gke-system

Se EXTERNAL-IP for pending, consulte EXTERNAL-IP é pending por muito tempo abaixo.

Como verificar o status da revisão

Para receber a revisão mais recente do serviço do Cloud Run for Anthos, execute o seguinte comando:

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

Execute o seguinte comando para ver o status de uma revisão específica do Cloud Run for Anthos:

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.
ContainerHealth 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. 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 receber o IP externo do gateway de entrada do Istio:

kubectl get svc istio-ingress -n gke-system

A saída resultante é algo semelhante a:

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

O EXTERNAL-IP do balanceador de carga é o endereço IP que você precisa usar.

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-ingress -n gke-system

Isso gera uma saída semelhante a esta:

Name:                     istio-ingress
Namespace:                gke-system
Labels:                   addonmanager.kubernetes.io/mode=Reconcile
                          app=istio-ingress
                          chart=gateways-1.0.3
                          heritage=Tiller
                          istio=ingress-gke-system
                          k8s-app=istio
                          kubernetes.io/cluster-service=true
                          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=ingressgateway,istio=ingress-gke-system,release=istio
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. Talvez isso leve alguns minutos.

Como solucionar problemas de TLS

Use as etapas listadas abaixo para resolver problemas gerais do recurso de certificados TLS gerenciados.

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 campo CertificateProvisioned 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	Mensagem detalhada	Instruções para solução de problemas
DNSErrored	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	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.example.com: consulte https://letsencrypt.org/docs/rate-limits/	Entre em contato com a Let's Encrypt (em inglês) para aumentar sua cota de certificados desse host.
InvalidDomainMappingName	As porcentagens do nome de DomainMapping não podem ser iguais às do host de URL da rota.	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	O sistema não conseguiu atender à solicitação HTTP01.	Esse erro pode ocorrer se o serviço `istio-ingress` não conseguir exibir a solicitação da Let's Encrypt para validar a propriedade do domínio.	Verifique se o serviço `istio-ingress` pode ser acessado pela Internet pública sem usar a nuvem privada virtual. Verifique se o serviço `istio-ingress` 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	Mensagem detalhada	Instruções para solução de problemas
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. Esse geralmente é um erro temporário, então o Cloud Run repetirá a ação. 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 o Cloud Run for Anthos não chama o Let's Encrypt. Esse geralmente é um erro temporário, então o Cloud Run repetirá a ação. 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

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.

Exceder a cota Let's Encrypt

Verifique o status do DomainMapping. Se você exceder a cota da Let's Encrypt, você verá uma mensagem de erro no DomainMapping parecida com esta:

acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
:: too many certificates already issued for exact set of domains:
test.example.com:
see https://letsencrypt.org/docs/rate-limits/'

Consulte a documentação da Let's Encrypt sobre limites de taxa para aumentar a cota de certificados.

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.example.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 istio-ingress em gke-system. Execute o seguinte comando para verificar o registro DNS:
```
host DOMAIN
```
Execute o seguinte comando para verificar o endereço IP externo do serviço istio-ingress em gke-system:
```
kubectl get svc istio-ingress -n gke-system
```
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:
1. Consiga o IP externo do serviço istio-ingress em gke-system executando o seguinte comando:
```
kubectl get svc istio-ingress -n gke-system
```
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 serviço istio-ingress em gke-system, 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
```
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 do istio-pilot no namespace gke-system. 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 istio_pilot 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 istio-pilot -n gke-system --replicas=0
kubectl scale deployment istio-pilot -n gke-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.

Como usar WebSockets com domínios personalizados

Por padrão, os WebSockets estão desativados para mapeamentos de domínios personalizados.

Para ativar Websockets nos seus domínios personalizados, execute o comando a seguir para criar um objeto Istio EnvoyFilter com allow_connect: true:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: allowconnect-cluster-local-gateway-tb
  namespace: gke-system
spec:
  workloadSelector:
    labels:
      istio: ingress-gke-system
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      listener:
        portNumber: 8081
        filterChain:
          filter:
            name: "envoy.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager"
          http2_protocol_options:
            allow_connect: true
EOF