Resolva problemas do Cloud Run

Esta página descreve como resolver problemas que pode encontrar ao usar o Cloud Run. O Personalized Service Health publica todos os incidentes do Cloud Run que resultam da infraestrutura Google Cloud subjacente para identificar Google Cloud interrupções do serviço que afetam os seus projetos. Também deve considerar configurar alertas sobre eventos do Personalized Service Health. Para ver informações sobre incidentes que afetam todos os Google Cloud serviços, consulte o painel de controlo Google Cloud Estado do serviço.

Verifique se existem problemas ou abra novos problemas nos rastreadores de problemas públicos.

Para outras mensagens de erro não listadas nesta página, consulte Problemas conhecidos no Cloud Run. Se continuar a encontrar erros mesmo depois de seguir os passos neste guia, contacte o apoio técnico.

Consulte as secções seguintes para ver orientações sobre como resolver problemas no Cloud Run:

Erros de implementação

Esta secção descreve os erros de implementação comuns no Cloud Run e os métodos para os resolver.

Falha ao iniciar o contentor

Ocorre o seguinte erro quando tenta implementar:

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Para resolver este problema, siga estes passos:

  1. Confirme que pode executar a imagem do contentor localmente. Se a imagem do contentor não puder ser executada localmente, tem de diagnosticar e corrigir o problema localmente primeiro.

  2. Verifique se o seu contentor está a ouvir pedidos na porta correta. O contentor tem de detetar pedidos recebidos na porta definida pelo Cloud Run e fornecida na variável de ambiente PORT. Para ver instruções sobre como especificar a porta,consulte o artigo Configurar contentores para serviços

  3. Verifique se o seu contentor está a ouvir em todas as interfaces de rede, normalmente indicadas como 0.0.0.0. Em particular, o seu contentor não deve ouvir em 127.0.0.1.

  4. Verifique se a imagem do contentor está compilada para Linux de 64 bits, conforme exigido pelo contrato de tempo de execução do contentor.

  5. Use o Cloud Logging para procurar erros de aplicação nos registos do stdout ou do stderr. Também pode procurar falhas capturadas nos Relatórios de erros.

    Pode ter de atualizar o código ou as definições de revisão para corrigir erros ou falhas. Também pode resolver problemas do seu serviço localmente.

Erro de importação do contentor

Ocorre o seguinte erro quando tenta implementar:

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Para resolver este problema, siga estes passos:

  1. Certifique-se de que o sistema de ficheiros do contentor não contém carateres que não sejam UTF-8.

  2. Algumas imagens do Docker baseadas no Windows usam camadas externas. O plano de controlo do Cloud Run não suporta camadas externas. Para resolver este problema, experimente definir a flag --allow-nondistributable-artifacts no daemon do Docker.

A funcionalidade não é suportada

O seguinte erro ocorre quando chama a API Cloud Run Admin:

The feature is not supported in the declared launch stage

Este erro ocorre quando chama a Cloud Run Admin API diretamente e usa uma funcionalidade beta sem especificar uma anotação ou um campo de fase de lançamento.

Para resolver este problema, adicione o campo de fase de lançamento aos pedidos.

Consulte os seguintes exemplos para adicionar referências da fase de lançamento quando usar a API REST v1 ou v2:

  • Anotação da fase de lançamento a um pedido do cliente através de JSON e da API REST v1:

      "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

  • Referência LaunchStage a um pedido do cliente através de JSON e da API REST v2:

    "launchStage": "BETA"

  • Anotação da fase de lançamento a um pedido de serviço através de YAML e da API REST v1:

    kind: Service
metadata:
annotations:
  run.googleapis.com/launch-stage: BETA

O utilizador root não foi encontrado

O seguinte erro ocorre quando as chaves de encriptação geridas pelo cliente são especificadas através de um parâmetro --key:

ERROR: "User \"root\""not found in /etc/passwd

Para resolver este problema, especifique USER 0 em vez de USER root no Dockerfile.

A conta de serviço predefinida do Compute Engine é eliminada

Ocorre o seguinte erro durante a implementação:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Este problema ocorre num dos seguintes cenários:

  • A conta de serviço predefinida do Compute Engine não existe no projeto e não é especificada uma conta de serviço com a flag --service-account no momento da implementação.

  • O programador ou o principal que implementa o serviço não tem as autorizações necessárias para a conta de serviço predefinida do Compute Engine para implementar.

Para resolver este problema:

  1. Especifique uma conta de serviço através da flag --service-account:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Verifique se a conta de serviço que especificar tem as autorizações necessárias para a implementação.

Para verificar se o agente de serviço do Compute Engine predefinido existe no seu Google Cloud projeto, siga estes passos:

  1. Na Google Cloud consola, aceda à página Autorizações da gestão de identidade e acesso:

    Aceda a Autorizações

  2. Selecione a caixa de verificação Incluir concessões de funções fornecidas pela Google.

  3. Na lista Principais, localize o ID do agente do serviço do Compute Engine, que segue o formato PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Problemas com a conta de serviço do Cloud Build

O seguinte erro ocorre durante as implementações de origem quando a conta de serviço do Cloud Build não tem as autorizações necessárias ou está desativada:

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

O Cloud Build alterou o comportamento predefinido da forma como o Cloud Build usa as contas de serviço em novos projetos. Isto está detalhado no artigo Alteração da conta de serviço predefinida do Cloud Build. Como resultado desta alteração, os novos projetos implementados no Cloud Run a partir do código-fonte pela primeira vez podem estar a usar uma conta de serviço do Cloud Build predefinida com autorizações insuficientes para a implementação a partir da origem.

Para resolver este problema, siga estes passos:

  • Reveja as orientações do Cloud Build sobre as alterações à conta de serviço predefinida e desative estas alterações.

  • Conceda a função Cloud Run Builder (roles/run.builder) à conta de serviço de compilação.

O agente do serviço do Cloud Run não tem autorização para ler a imagem

O seguinte erro ocorre quando tenta implementar a partir de um projeto usando uma imagem armazenada no Artifact Registry, usando o domínio gcr.io num projeto diferente:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

Também pode ver o seguinte erro quando tenta implementar a partir de um projeto usando uma imagem armazenada no Artifact Registry num projeto diferente:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

Para resolver este problema, siga estas recomendações de resolução de problemas:

  • Siga as instruções para implementar imagens de contentores de outros Google Cloud projetos para garantir que os seus principais têm as autorizações necessárias.

  • Este problema também pode ocorrer se o projeto estiver num perímetro dos VPC Service Controls com uma restrição na API Cloud Storage que proíbe pedidos do agente do serviço Cloud Run. Para corrigir este problema:

    1. Abra o Explorador de registos na Google Cloud consola. (Não use a página Registos na página do Cloud Run):

      Aceda ao Explorador de registos

    2. Introduza o seguinte texto no campo de consulta:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Se vir entradas de registo depois de usar esta consulta, examine as entradas de registo para determinar se tem de atualizar as políticas dos VPC Service Controls. Podem indicar que tem de adicionar service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a uma política de acesso preexistente.

Autorizações em falta para implementações de origem

Podem ocorrer os seguintes erros quando fizer a implementação a partir da origem:

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

Cada serviço do Cloud Run está associado a uma conta de serviço que serve como identidade quando o serviço acede a outros recursos. Esta conta de serviço pode ser a conta de serviço predefinida (PROJECT_NUMBER-compute@developer.gserviceaccount.com) ou uma conta de serviço gerida pelo utilizador.

Em ambientes onde vários serviços estão a aceder a recursos diferentes, pode usar identidades por serviço com contas de serviço geridas pelo utilizador diferentes em vez da conta de serviço predefinida.

Para resolver este problema, conceda à conta do implementador a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço que é usada como identidade de serviço. Esta função predefinida contém a autorização iam.serviceAccounts.actAs, que é necessária para anexar uma conta de serviço ao serviço ou à revisão. A um utilizador que cria uma conta de serviço gerida pelo utilizador é concedida automaticamente a autorização iam.serviceAccounts.actAs. No entanto, outros implementadores têm de ter esta autorização concedida pelo utilizador que cria a conta de serviço gerida pelo utilizador.

Para mais informações acerca dos requisitos de acesso de quaisquer novas contas de serviço que criar, consulte o artigo Receba recomendações para criar contas de serviço dedicadas.

O utilizador não tem autorizações suficientes para concluir implementações de origens

O seguinte erro ocorre quando a conta do implementador não tem as autorizações necessárias no seu projeto:

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

Para resolver este erro, peça ao seu administrador que lhe conceda as seguintes funções de gestão de identidade e acesso:

Erro ao implementar um serviço do Cloud Run a partir de outros projetos do Google Cloud

O seguinte erro ocorre quando implementa um serviço do Cloud Run a partir de um projeto de origem para um projeto de destino:

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

Para resolver este problema, siga estes passos:

  1. Conceda a função Utilizador da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço que usa como identidade de serviço no projeto de destino.

  2. Conceda a função Criador de tokens de contas de serviço (roles/iam.serviceAccountTokenCreator) à conta de serviço do Cloud Run no projeto de destino. Adicione o email do agente de serviço do Cloud Run (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) como o principal do projeto de origem.

  3. Desative a política da organização iam.disableCrossProjectServiceAccountUsage.

Para ver instruções detalhadas, consulte o artigo Configure a identidade do serviço para serviços.

Erros ao implementar o seu código-fonte Python no Cloud Run

Quando implementa um serviço do Cloud Run a partir do código fonte com o tempo de execução do Python, ocorre um dos seguintes erros:

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • A implementação é bem-sucedida com códigos de erro HTTP 500 nos registos.

O buildpack do Python define o ponto de entrada predefinido para implementações de origem do Cloud Run. Para a versão 3.13 do Python e posteriores, o buildpack do Python define o ponto de entrada com base na configuração do serviço Web no seu ficheiro requirements.txt. Se não especificar um servidor Web ou uma framework no ficheiro requirements.txt, ou usar a versão 3.12 e anteriores do Python, o buildpack do Python define o ponto de entrada predefinido como gunicorn -b :8080 main:app. Para mais informações, consulte o artigo Criar uma aplicação Python.

Pode resolver este problema de várias formas. Por exemplo, pode especificar um dos seguintes servidores Web no seu ficheiro requirements.txt:

  • gunicorn:

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi e uvicorn:

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

Em alternativa, pode seguir qualquer um destes passos para resolver erros de implementação:

  • Especifique o ponto de entrada executando o seguinte comando de implementação de origem:

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    Substitua o seguinte:

    • SERVICE: o nome do serviço para o qual quer fazer a implementação.
    • ENTRYPOINT: o ponto de entrada predefinido que quer usar para o seu código fonte.

  • Use um Procfile para definir um ponto de entrada.

Erros de publicação

Esta secção lista os problemas que pode encontrar com a publicação e fornece sugestões sobre como corrigir cada um deles.

HTTP 404: não encontrado

O seguinte problema ocorre durante a publicação:

`HTTP 404`:Not found

Pode encontrar erros HTTP 404 nos seguintes cenários:

  1. Um URL de pedido ou um código de aplicação incorreto devolve erros 404. Para resolver este problema, siga estes passos:

    1. Verifique se o URL que pediu está correto. Pode validar o URL na página de detalhes do serviço na Google Cloud consola ou executando o seguinte comando:

      gcloud run services describe SERVICE_NAME | grep URL

    2. Inspeccione onde a sua app devolve códigos de erro 404. Se a sua app devolver 404, pode encontrá-la no Cloud Logging. Além disso, verifique se a app não devolve um código de erro 404 quando a executa localmente.

    3. Certifique-se de que a sua app não começa a ouvir na porta configurada antes de estar pronta para receber pedidos.

  2. O pedido não chega ao contentor, o que gera um erro 404 nos seguintes cenários:

    Em ambos os cenários, não consegue encontrar o erro 404 no Cloud Logging, mesmo quando aplica o seguinte filtro:

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. Com as mesmas definições de entrada, o pedido pode ser bloqueado pelos VPC Service Controls com base no contexto do autor da chamada, incluindo o projeto e o endereço IP. Para verificar se existe uma violação da política dos VPC Service Controls:

    1. Abra o Explorador de registos na Google Cloud consola:

      Aceda ao Explorador de registos

    2. Introduza o seguinte texto no campo de consulta:

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. Se vir entradas de registo depois de usar esta consulta, examine as entradas de registo para determinar se precisa ou não de atualizar as políticas do VPC Service Controls.

  4. Aceda ao seu ponto final de serviço com um balanceador de carga através do tempo de execução do Python. Para resolver este problema, valide a máscara de URL do equilibrador de carga e certifique-se de que o caminho do URL especificado para o equilibrador de carga corresponde ao caminho no código fonte Python.

Nenhuma instância de contentor disponível

Ocorre o seguinte erro durante a publicação:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Para resolver este problema, verifique a métrica Contagem de instâncias de contentores do seu serviço e pondere aumentar este limite se a sua utilização estiver a aproximar-se do máximo. Para mais informações, consulte o artigo Defina o número máximo de instâncias para serviços e, se precisar de mais instâncias, peça um aumento da quota.

O Cloud Run não conseguiu gerir a taxa de tráfego

O erro seguinte ocorre durante a publicação ou quando o serviço não atingiu o respetivo limite máximo de instâncias de contentores:

HTTP 500
The request was aborted because there was no available instance

Para resolver este problema, siga estes passos:

  1. Resolva as seguintes possíveis origens dos problemas:

    • Um aumento súbito e enorme no tráfego.
    • Um tempo de início a frio longo.
    • Um longo tempo de processamento de pedidos ou um aumento súbito no tempo de processamento de pedidos.
    • O serviço atingir o limite máximo de instâncias de contentores (HTTP 429).
    • Fatores transitórios atribuídos ao serviço do Cloud Run.

  2. Implemente o recuo exponencial e as novas tentativas para pedidos que o cliente não deve rejeitar. Um aumento curto e súbito no tráfego ou no tempo de processamento de pedidos só pode ser visível no Cloud Monitoring se aumentar o zoom para uma resolução de 10 segundos.

  3. Quando a causa principal do problema é um período de erros transitórios intensificados atribuíveis exclusivamente ao Cloud Run, contacte o apoio técnico.

A operação não foi implementada

O seguinte erro ocorre quando especifica um REGION incorreto ao invocar a sua tarefa do Cloud Run, como quando implementa uma tarefa na região asia-southeast1 e invoca a tarefa através de southeast1-asia ou asia-southeast:

HTTP 501
Operation is not implemented, or supported, or enabled.

Para ver a lista de regiões suportadas, consulte o artigo Localizações do Cloud Run.

Credenciais predefinidas não encontradas

O erro seguinte ocorre quando a sua aplicação não é autenticada corretamente devido a ficheiros em falta, caminhos de credenciais inválidos ou atribuições de variáveis de ambiente incorretas:

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

Para resolver este problema:

  1. Instale e inicialize a CLI gcloud.

  2. Configure as Credenciais predefinidas da aplicação (ADC) com as credenciais associadas à sua Conta Google. Configure o ADC através de:

      gcloud auth application-default login

    É apresentado um ecrã de início de sessão. Depois de iniciar sessão, as suas credenciais são armazenadas no ficheiro de credenciais local, usado pelo ADC.

  3. Use a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para fornecer a localização de um ficheiro JSON de credenciais no seu projeto Google Cloud .

    Para mais informações, consulte o artigo Configure as Credenciais padrão da aplicação.

As instâncias de contentores excedem os limites de memória

Ocorre o seguinte erro HTTP 500 ou HTTP 503 durante a publicação no Cloud Logging:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

Para resolver este problema:

  1. Determine se as instâncias de contentores estão a exceder a memória disponível. Procure erros relacionados nos varlog/system registos.
  2. Se as instâncias estiverem a exceder a memória disponível, considere aumentar o limite de memória.

No Cloud Run, os ficheiros escritos no sistema de ficheiros local contam para a memória disponível. Isto também inclui quaisquer ficheiros de registo escritos em localizações diferentes de /var/log/* e /dev/log.

Não é possível processar alguns pedidos devido à definição de simultaneidade elevada

O seguinte erro ocorre quando as instâncias do contentor estão a usar uma carga elevada da CPU para processar pedidos e, como resultado, não conseguem processar todos os pedidos:

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Para resolver este problema, siga estes passos:

  1. Aumente o número máximo de instâncias de contentores para o seu serviço.

  2. Diminuir a concorrência do serviço. Para mais informações, consulte o artigo Defina o número máximo de pedidos simultâneos por instância.

Erros do Cloud Logging relacionados com anulações de pedidos de filas pendentes

Ocorre um dos seguintes erros quando o Cloud Run não consegue aumentar a escala com rapidez suficiente para gerir o tráfego:

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

Para resolver este problema, siga estes passos:

  1. Resolva as causas principais que podem provocar falhas de escalabilidade, como:

    • Um aumento súbito e enorme no tráfego.
    • Tempo de início a frio longo.
    • Tempo de processamento de pedidos longo.
    • Taxa de erros de código-fonte elevada.
    • Atingir o limite máximo de instâncias e impedir o sistema de ser dimensionado.
    • Fatores transitórios atribuídos ao serviço do Cloud Run.

    Para mais informações sobre a resolução de problemas de escalabilidade e a otimização do desempenho, consulte as Sugestões de desenvolvimento gerais.

  2. Para serviços ou funções baseados em acionadores HTTP, o cliente deve implementar o recuo exponencial e as novas tentativas para pedidos que não podem ser ignorados. Se estiver a acionar serviços a partir dos fluxos de trabalho, pode usar a sintaxe try/retry para o fazer.

  3. Para serviços ou funções de segundo plano ou acionados por eventos, o Cloud Run suporta a entrega, pelo menos, uma vez. Mesmo sem ativar explicitamente a nova tentativa, o Cloud Run volta a enviar automaticamente o evento e tenta novamente a execução. Consulte o artigo Voltar a tentar funções acionadas por eventos para mais informações.

  4. Para problemas relacionados com inícios a frio, configure o número mínimo de instâncias para reduzir a quantidade de inícios a frio com uma implicação de faturação mais elevada.

  5. Quando a causa principal do problema é um período de erros transitórios intensificados atribuídos exclusivamente ao Cloud Run ou se precisar de assistência com o seu problema, contacte o apoio técnico.

Assinatura do token de identidade ocultada pela Google

O seguinte erro ocorre durante as fases de desenvolvimento e teste:

SIGNATURE_REMOVED_BY_GOOGLE

Este erro pode ocorrer nos seguintes cenários:

  • O utilizador inicia sessão através da CLI do Google Cloud ou do Cloud Shell.

  • O utilizador gera um token de ID através de comandos gcloud.

  • O utilizador tenta usar o token de ID para invocar um serviço do Cloud Run não público.

Este é o comportamento predefinido esperado. A Google remove a assinatura do token devido a preocupações de segurança para impedir que qualquer serviço do Cloud Run não público reproduza tokens de ID gerados desta forma.

Para resolver este problema, invoque o seu serviço privado com um novo token de ID. Para mais informações, consulte o artigo Teste o seu serviço privado.

Aviso do OpenBLAS nos registos

Se usar bibliotecas baseadas em OpenBLAS, como o NumPy, com o ambiente de execução de primeira geração, pode ver o seguinte aviso nos seus registos:

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

O aviso do OpenBLAS ocorre quando a sandbox do contentor usada pelo ambiente de execução de primeira geração não expõe funcionalidades de hardware de baixo nível. Este aviso não afeta o seu serviço. Para evitar entradas de registo de avisos do OpenBLAS, mude para o ambiente de execução de segunda geração.

O Spark falha ao obter o endereço IP da máquina à qual se associar

Quando o Spark falha ao obter o endereço IP da máquina de associação, ocorre um dos seguintes erros:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Para resolver este problema, defina a variável de ambiente SPARK_LOCAL_IP como 127.0.0.1 no seu ficheiro Docker, por exemplo, ENV SPARK_LOCAL_IP="127.0.0.1". Se não definir a variável de ambiente SPARK_LOCAL_IP, esta usa a respetiva contrapartida IPv6 em vez do localhost. Além disso, o Spark não reconhece a variável de ambiente definida como RUN export SPARK_LOCAL_IP="127.0.0.1".

Não é possível aceder a ficheiros através do NFS

Erro Solução sugerida
mount.nfs: Protocol not supported Algumas imagens base, como debian e adoptopenjdk/openjdk11, não têm a dependência nfs-kernel-server.
mount.nfs: Connection timed out Se a ligação expirar, certifique-se de que está a fornecer o endereço IP correto da instância do arquivo de ficheiros.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Se o acesso tiver sido recusado pelo servidor, certifique-se de que o nome da partilha de ficheiros está correto.

Não é possível aceder a ficheiros através do Cloud Storage FUSE

Consulte o guia de resolução de problemas do Cloud Storage FUSE.

Latência elevada quando a utilização da CPU é baixa

O seu serviço pode sofrer latências de pedidos elevadas ou não conseguir aumentar a escala sob carga, mesmo que o Cloud Monitoring mostre que a utilização média da CPU está bem abaixo do objetivo de escalabilidade típico de 60%.

Potencial causa:

Isto pode ocorrer se a sua aplicação for de thread único para tarefas limitadas pela CPU, mas for implementada numa instância com várias CPUs virtuais. A sua aplicação pode atingir o limite máximo de um núcleo de CPU virtual, enquanto os outros núcleos permanecem praticamente inativos. O escalador automático do Cloud Run usa a utilização média da CPU em todas as CPUs virtuais. Esta média pode ser baixa nestes casos, o que impede o escalamento baseado na CPU.

Soluções:

  • Para aplicações de thread único:
    • É preferível configurar o serviço com 1 vCPU se os respetivos requisitos de memória puderem ser cumpridos (consulte Limites de memória e mínimos de CPU). Isto ajuda as métricas de utilização da CPU a refletirem com precisão a carga.
    • Se forem necessárias várias vCPUs devido a necessidades de memória elevadas que excedam os limites de 1 vCPU, o ajuste de escala automático baseado na CPU é provavelmente menos eficaz. Neste cenário, diminua a definição de simultaneidade máxima para incentivar o dimensionamento mais cedo com base no débito de pedidos. Consulte a Configuração de simultaneidade.
  • Para configurações com várias vCPUs: certifique-se de que a sua aplicação está arquitetada para usar eficazmente todas as vCPUs atribuídas (por exemplo, usando vários processos ou threads de trabalho).

Erros de conetividade e segurança

Esta secção descreve os erros de conetividade e segurança comuns no Cloud Run e os métodos para os resolver.

O cliente não está autenticado corretamente

Ocorre o seguinte erro durante a publicação:

HTTP 401: The request was not authorized to invoke this service

Para resolver este problema:

  1. Se uma conta de serviço invocar o seu serviço do Cloud Run, defina a reivindicação de público-alvo (aud) do token de ID assinado pela Google para o seguinte:

    • Se definir o aud para o URL do serviço de receção através do formato https://SERVICE.run.app ou https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, o seu serviço tem de exigir autenticação. Invoque o seu serviço do Cloud Run através do URL do Cloud Run ou de um URL do balanceador de carga. Para ver exemplos sobre o envio de pedidos autenticados, consulte o artigo Invocar com um pedido HTTPS.

    • Se definir o aud para o ID de cliente de um ID de cliente OAuth 2.0 com o tipo Aplicação Web, usando o formato nnn-xyz.apps.googleusercontent.com, pode invocar o seu serviço do Cloud Run através de um equilibrador de carga HTTPS protegido pelo IAP. Recomendamos esta abordagem para um balanceador de carga de aplicações suportado por vários serviços do Cloud Run em diferentes regiões.

    • Se definir o aud para um público-alvo personalizado configurado, use os valores exatos fornecidos. Por exemplo, se o público-alvo personalizado for https://service.example.com, o valor da reivindicação do público-alvo também tem de ser https://service.example.com.

  2. Certifique-se de que os seus pedidos incluem um cabeçalho Authorization: Bearer ID_TOKEN ou um cabeçalho X-Serverless-Authorization: Bearer ID_TOKEN para autorização personalizada e que o token é um token de ID e não um token de acesso ou de atualização. Pode ocorrer um erro 401 nos seguintes cenários devido ao formato de autorização incorreto:

    • O token de autorização usa um formato inválido.

    • O cabeçalho de autorização não é um símbolo da Web JSON (JWT) com uma assinatura válida.

    • O cabeçalho de autorização contém vários JWTs.

    • Existem vários cabeçalhos de autorização no pedido.

    Para verificar as reivindicações num JWT, use a ferramenta jwt.io.

  3. Se receber tokens inválidos quando usar o servidor de metadados para obter tokens de ID e de acesso para autenticar pedidos com a identidade do serviço ou da tarefa do Cloud Run com um proxy HTTP para encaminhar o tráfego de saída, adicione os seguintes anfitriões às exceções do proxy HTTP:

    • 169.254.* ou 169.254.0.0/16

    • *.google.internal

  4. Normalmente, ocorre um erro 401 quando as bibliotecas de cliente da nuvem usam o servidor de metadados para obter credenciais predefinidas da aplicação para autenticar invocações REST ou gRPC. Se não definir as exceções de proxy HTTP, o comportamento resultante é o seguinte:

    • Se diferentes Google Cloud cargas de trabalho alojarem um serviço ou uma tarefa do Cloud Run e o proxy HTTP, mesmo que as bibliotecas de cliente Google Cloud obtenham as credenciais, a conta de serviço atribuída à carga de trabalho do proxy HTTP gera os tokens. Os tokens podem não ter as autorizações necessárias para realizar as operações da Google Cloud API pretendidas. Isto deve-se ao facto de a conta de serviço obter os tokens da vista do servidor de metadados da carga de trabalho do proxy HTTP, em vez do serviço ou da tarefa do Cloud Run.

    • Se o proxy HTTP não estiver alojado em Google Cloude encaminhar pedidos do servidor de metadados através do proxy, os pedidos de tokens falham e as operações das Google Cloud APIs não são autenticadas.

  5. Volte a implementar o seu serviço para permitir o acesso público, se a sua organização o suportar. Isto é útil para testes.

O cliente não tem autorização para invocar o serviço

Ocorre um dos seguintes erros ao invocar o seu serviço:

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

Pode ocorrer um erro 403 quando o membro do IAM usado para gerar o token de autorização não tem a autorização run.routes.invoke. Conceda esta autorização ao utilizador que está a gerar o token.

Além disso, se existir uma entrada para o erro com o formato resource.type = "cloud_run_revision" no Cloud Logging, siga estes passos para resolver o erro:

  1. Para tornar o seu serviço invocável por qualquer pessoa, atualize as definições do IAM e torne o serviço público.

  2. Para tornar o seu serviço invocável apenas por determinadas identidades, invoque o seu serviço com o token de autorização adequado:

    • Se um programador ou um utilizador final invocar o seu serviço, conceda a autorização run.routes.invoke. Pode conceder esta autorização através das funções de administrador do Cloud Run (roles/run.admin) e invocador do Cloud Run (roles/run.invoker).

    • Se uma conta de serviço invocar o seu serviço, certifique-se de que a conta de serviço é membro do serviço do Cloud Run e conceda a função de invocador do Cloud Run (roles/run.invoker).

    • As chamadas que não tenham um token de autorização podem causar o erro 403. Se as chamadas com um token de autorização válido continuarem a gerar o erro 403, conceda ao membro do IAM que gera o token a autorização run.routes.invoke.

Quando encontra um erro 403 e não encontra a entrada de registo resource.type = "cloud_run_revision", pode dever-se ao facto de os VPC Service Controls estarem a bloquear um serviço do Cloud Run que tem definições de entrada configuradas para All. Para mais informações sobre a resolução de problemas de recusas do VPC Service Controls, consulte erros 404.

Erro ao aceder ao serviço a partir de um navegador de Internet

O seguinte problema ocorre quando acede a um serviço do Cloud Run a partir de um navegador de Internet:

403 Forbidden
Your client does not have permission to get URL from this server.

Quando invoca um serviço do Cloud Run a partir de um navegador de Internet, o navegador envia um pedido GET para o serviço. No entanto, o pedido não contém o token de autorização do utilizador que está a fazer a chamada. Para resolver este problema, siga estes passos:

  1. Use o Identity-Aware Proxy (IAP) com o Cloud Run. A IAP permite-lhe estabelecer uma camada de autorização central para aplicações acedidas através de HTTPS. Com o IAP, pode usar um modelo de controlo de acesso ao nível da aplicação em vez de firewalls ao nível da rede. Para mais detalhes sobre a configuração do Cloud Run com o IAP, consulte o artigo Ativar o Identity-Aware Proxy para o Cloud Run.

  2. Como solução alternativa temporária, aceda ao seu serviço através de um navegador de Internet com o proxy do Cloud Run na CLI do Google Cloud. Para usar um proxy de um serviço localmente, execute o seguinte comando:

    gcloud run services proxy SERVICE --project PROJECT-ID

    O Cloud Run encaminha o serviço privado para http://localhost:8080 (ou para a porta que especificar com --port), fornecendo o token da conta ativa ou outro token que especificar. Esta é a forma recomendada de testar um Website ou uma API de forma privada no seu navegador. Para mais informações, consulte o artigo Testar serviços privados.

  3. Permita o acesso público ao seu serviço. Isto é útil para testes ou quando o seu serviço é uma API ou um Website público.

Ligação reposta por par

Ocorre um dos seguintes erros quando um par na rede fecha inesperadamente a ligação TCP estabelecida pela aplicação:

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

Para resolver este problema, siga estes passos:

  • Se estiver a tentar realizar trabalho em segundo plano com limitação da CPU, use a definição de faturação baseada em instâncias.

  • Certifique-se de que está dentro dos tempos limite de pedidos de saída. Se a sua aplicação mantiver alguma ligação num estado inativo para além deste limite, a gateway tem de recolher a ligação.

  • Por predefinição, a opção de socket TCP keepalive está desativada para o Cloud Run. Não existe uma forma direta de configurar a opção keepalive ao nível do serviço. Para ativar a opção keepalive para cada ligação de socket, forneça as opções de socket necessárias quando abrir uma nova ligação de socket TCP, consoante a biblioteca de cliente que estiver a usar para esta ligação na sua aplicação.

  • Ocasionalmente, as ligações de saída são repostas devido a atualizações da infraestrutura. Se a sua aplicação reutilizar ligações de longa duração, recomendamos que a configure para restabelecer as ligações de forma a evitar a reutilização de uma ligação inativa.

  • Se estiver a usar um proxy HTTP para encaminhar o tráfego de saída dos seus serviços ou tarefas do Cloud Run, e o proxy aplicar uma duração máxima da ligação, o proxy pode rejeitar silenciosamente ligações TCP de longa duração, como as estabelecidas através da partilha de ligações. Isto faz com que os clientes HTTP falhem quando reutilizam uma ligação já fechada. Se pretender encaminhar o tráfego de saída através de um proxy HTTP, tem de implementar a validação de ligações, as novas tentativas e o recuo exponencial. Para conjuntos de ligações, configure os valores máximos para a antiguidade das ligações, as ligações inativas e o limite de tempo de inatividade das ligações.

Limites de tempo da ligação

Os seguintes erros ocorrem quando uma aplicação tenta criar uma nova ligação TCP com um anfitrião remoto e a ligação demora demasiado tempo a estabelecer-se:

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

Para resolver problemas de limite de tempo de ligação, siga estes passos:

  1. Se estiver a encaminhar todo o tráfego de saída através de uma rede VPC, quer esteja a usar conetores de VPC ou saída direta de VPC, siga estes passos:

    • Defina todas as regras de firewall necessárias para permitir o tráfego de entrada para os conetores de VPC.

    • As regras de firewall da VPC têm de permitir o tráfego de entrada dos conetores da VPC ou da sub-rede de saída da VPC direta para alcançar o anfitrião ou a sub-rede de destino.

    • Certifique-se de que tem todas as rotas necessárias para permitir o encaminhamento correto do tráfego para os anfitriões de destino e vice-versa. Isto é importante quando encaminha o tráfego de saída através do VPC Network Peering ou da conetividade da nuvem híbrida, uma vez que os pacotes atravessam várias redes antes de chegarem ao anfitrião remoto.

  2. Se estiver a usar um proxy HTTP para encaminhar todo o tráfego de saída dos seus serviços ou tarefas do Cloud Run, os anfitriões remotos têm de ser acessíveis através do proxy.

    O tráfego encaminhado através de um proxy HTTP pode sofrer atrasos consoante a utilização de recursos do proxy. Se estiver a encaminhar tráfego de saída HTTP através de um proxy, implemente novas tentativas, retirada exponencial ou disjuntores.

Configure exceções de proxy HTTP

Quando usar um proxy HTTP para encaminhar o tráfego de saída dos seus serviços ou tarefas do Cloud Run, adicione exceções para as APIs Google Cloud e outros anfitriões e sub-redes não encaminhados por proxy para evitar a latência, os limites de tempo de ligação, as reposições de ligação e os erros de autenticação.

Os anfitriões e as sub-redes não representados por proxy têm de incluir, no mínimo, o seguinte:

  • 127.0.0.1
  • 169.254.* ou 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Opcionalmente, os anfitriões sem proxy podem incluir:

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

Para definir exceções de proxy HTTP para redes de saída, configure o seguinte:

  • Variáveis de ambiente: NO_PROXY ou no_proxy.

  • Flag da máquina virtual Java http.nonProxyHosts:

    • A propriedade do sistema https.nonProxyHosts não está definida. Esta propriedade do sistema aplica-se a HTTP e HTTPS.

    • A propriedade do sistema http.nonProxyHosts não suporta a notação CIDR. Tem de usar expressões de correspondência de padrões.

Resposta com formato incorreto ou problema de ligação da instância do contentor

O seguinte erro ocorre quando existe um problema de ligação da instância do contentor:

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Para resolver este problema, siga estes passos:

  1. Verifique o Cloud Logging para os seguintes erros:

    • Erros de falta de memória. Se os registos contiverem mensagens de erro relativas a instâncias de contentores que excedem os limites de memória, consulte as recomendações na secção As instâncias de contentores estão a exceder os limites de memória.

    • Falhas da sondagem de atividade com o seguinte erro nos registos:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      Quando a sua instância não responde com êxito à sondagem dentro do período de tempo limite, siga estes passos:

  2. Se os pedidos terminarem com o código de erro 503 antes de atingirem o tempo limite do pedido definido no Cloud Run, atualize a definição do tempo limite do pedido para a sua framework de linguagem:

  3. Em alguns cenários, pode ocorrer um código de erro 503 devido a um estrangulamento da rede a jusante, como durante os testes de carga. Por exemplo, se o seu serviço encaminhar tráfego através de um conector de acesso VPC sem servidor, certifique-se de que o conector não excede o respetivo limite de débito seguindo estes passos:

    1. Abra o Acesso a VPC sem servidor na Google Cloud consola:

      Aceda ao Acesso a VPC sem servidor

    2. Verifique se existem barras vermelhas no histograma do gráfico de débito. Se existir uma barra vermelha, considere aumentar o número máximo de instâncias ou o tipo de instância que o conetor usa. Em alternativa, comprima o tráfego enviado através de um conetor de acesso a VPC sem servidor.

  4. Se uma instância de contentor receber mais de 800 pedidos por segundo, os soquetes TCP disponíveis podem ficar esgotados. Para resolver este problema, ative o HTTP/2 para o seu serviço e faça as alterações necessárias ao serviço para suportar o HTTP/2.

Erro de limite de tempo do gateway

O seguinte erro ocorre quando o seu serviço não devolve uma resposta dentro de um período especificado e o pedido termina:

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Para mais informações sobre este erro, consulte o contrato de tempo de execução do contentor.

Para resolver este problema, siga estes passos:

  • Se o seu serviço estiver a processar pedidos longos, aumente o limite de tempo do pedido.

  • Instrumente o registo e a monitorização para compreender onde a sua app está a gastar tempo antes de exceder o limite de tempo da solicitação configurado.

  • As ligações de saída são repostas ocasionalmente devido a atualizações da infraestrutura. Se a sua aplicação reutilizar ligações de longa duração, recomendamos que a configure para restabelecer as ligações de forma a evitar a reutilização de uma ligação inativa.

    Consoante a lógica ou o processamento de erros da sua app, um erro 504 pode ser um sinal de que a sua aplicação está a tentar reutilizar uma ligação inativa e o pedido é bloqueado até ao limite de tempo configurado para o pedido. Use uma sondagem de atividade para terminar uma instância que devolve erros persistentes.

  • Os erros de falta de memória que ocorrem no código da app, por exemplo, java.lang.OutOfMemoryError, não terminam necessariamente uma instância do contentor. Se a utilização de memória não exceder o limite de memória do contentor, o Cloud Run não termina a instância. Consoante a forma como a app processa os erros de falta de memória ao nível da app, os pedidos podem não ser processados até excederem o limite de tempo configurado para os pedidos.

    Para terminar a instância do contentor, siga estes passos:

    • Configure o limite de memória ao nível da app para que seja superior ao limite de memória do contentor.

    • Use uma sonda de atividade para ajudar a terminar uma instância que devolve erros persistentes.

Domínio personalizado bloqueado durante o aprovisionamento do certificado

Ocorre um dos seguintes erros quando mapeia um domínio personalizado:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

Para resolver este problema:

  1. Aguarde, pelo menos, 24 horas. Normalmente, o aprovisionamento do certificado SSL demora cerca de 15 minutos, mas pode demorar até 24 horas.

  2. Verifique se atualizou corretamente os registos DNS no registador de domínios através da ferramenta dig da Caixa de ferramentas do administrador. Os registos DNS na entidade de registo de domínio têm de corresponder ao que a Google Cloud consola lhe pede para adicionar.

  3. Valide a raiz do domínio na sua conta através de um dos seguintes métodos:

  4. Verifique se o certificado do domínio não expirou. Para encontrar os limites de validade, use o seguinte comando:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

A desconexão do cliente não se propaga ao Cloud Run

Quando usa o HTTP/1.1 no Cloud Run, os eventos de desconexão do cliente não são propagados para o contentor do Cloud Run.

Para resolver este problema, use WebSockets ou HTTP/2.0, que propagam as desconexões do cliente.