Resolver problemas do Cloud Run

Nesta página, descrevemos como solucionar erros que podem ocorrer ao usar o Cloud Run. O Personalized Service Health publica todos os incidentes do Cloud Run que surgem da infraestrutura Google Cloud subjacente para identificar Google Cloud interrupções de serviço que afetam seus projetos. Também é recomendável configurar alertas sobre eventos do Personalized Service Health. Para informações sobre incidentes que afetam todos os Google Cloud serviços, consulte o painel Google Cloud Service Health.

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

Para outras mensagens de erro não listadas nesta página, consulte Problemas conhecidos no Cloud Run. Se você continuar encontrando erros mesmo depois de seguir as etapas deste guia, entre em contato com o suporte.

Consulte as seções a seguir para orientações sobre como resolver problemas no Cloud Run:

Erros de implantação

Esta seção descreve os erros comuns de implantação no Cloud Run e os métodos para resolver problemas.

Falha ao iniciar o contêiner

O seguinte erro ocorre quando você tenta implantar:

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

Para resolver o problema, siga estas etapas:

  1. Verifique se é possível executar a imagem do contêiner localmente. Se não for possível executar a imagem do contêiner localmente, será preciso diagnosticar e corrigir o problema localmente primeiro.

  2. Verifique se o contêiner está detectando solicitações na porta correta. O contêiner precisa detectar solicitações de entrada na porta definida pelo Cloud Run e fornecidas na variável de ambiente PORT. Para instruções sobre como especificar a porta,consulte Configurar contêineres para serviços

  3. Verifique se o contêiner está detectando as solicitações em todas as interfaces de rede, normalmente indicadas como 0.0.0.0. É importante que o contêiner não detecte 127.0.0.1.

  4. Verifique se a imagem do contêiner é compilada para o Linux de 64 bits, conforme solicitado no contrato de ambiente de execução do contêiner.

  5. Use o Cloud Logging para procurar erros de aplicativo nos registros stdout ou stderr. Também é possível procurar por falhas capturadas no Error Reporting.

    Talvez seja necessário atualizar o código ou as configurações de revisão para corrigir erros ou falhas. Também é possível resolver problemas do serviço localmente.

Erro de importação de contêiner

O seguinte erro ocorre quando você tenta implantar:

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

Para resolver o problema, siga estas etapas:

  1. Verifique se o sistema de arquivos do contêiner não contém caracteres não utf8.

  2. Algumas imagens do Docker baseadas no Windows usam camadas externas. O plano de controle do Cloud Run não é compatível com camadas externas. Para resolver esse problema, tente definir a flag --allow-nondistributable-artifacts no daemon do Docker.

O recurso não é compatível

Este erro ocorre ao chamar a API Cloud Run Admin:

The feature is not supported in the declared launch stage

Esse erro ocorre quando você chama a API Cloud Run Admin diretamente e usa um recurso Beta sem especificar um campo ou uma anotação da fase de lançamento.

Para resolver esse problema, adicione o campo da fase de lançamento às solicitações.

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

  • Anotação da fase de lançamento em uma solicitação de cliente usando JSON e a API REST v1:

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

  • LaunchStage a uma solicitação de cliente usando JSON e a API REST v2:

    "launchStage": "BETA"

  • Anotação da fase de lançamento a uma solicitação de serviço usando YAML e a API REST v1:

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

O usuário root não foi encontrado

O seguinte erro ocorre quando as chaves de criptografia gerenciadas pelo cliente são especificadas usando um parâmetro --key:

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

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

A conta de serviço padrão do Compute Engine foi excluída

O seguinte erro ocorre durante a implantaçã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).

Esse problema ocorre em um dos seguintes cenários:

Para resolver o problema:

  1. Especifique uma conta de serviço usando a flag --service-account:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Verifique se a conta de serviço especificada tem as permissões necessárias para implantação.

Para verificar se o agente de serviço padrão do Compute Engine existe no projeto Google Cloud , siga estas etapas:

  1. No console Google Cloud , acesse a página Permissões do Gerenciamento de identidade e acesso:

    Ir para permissões

  2. Marque a caixa de seleção Incluir concessões de papel fornecidas pelo Google.

  3. Na lista Principais, localize o ID do agente de 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 erro a seguir ocorre durante implantações de origem quando a conta de serviço do Cloud Build não tem as permissõ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 mudou o comportamento padrão de como ele usa contas de serviço em novos projetos. Isso está detalhado em Mudança na conta de serviço padrão do Cloud Build. Como resultado dessa mudança, os novos projetos que implantam no Cloud Run a partir do código-fonte pela primeira vez podem estar usando uma conta de serviço padrão do Cloud Build com permissões insuficientes para implantar a partir da origem.

Para resolver o problema, siga estas etapas:

  • Revise as orientações do Cloud Build sobre mudanças na conta de serviço padrão e desative essas mudanças.

  • Conceda o papel Criador do Cloud Run (roles/run.builder) à conta de serviço de build.

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

O seguinte erro ocorre quando você tenta implantar de um projeto usando uma imagem armazenada no Artifact Registry, usando o domínio gcr.io em um 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.

Você também pode receber o seguinte erro ao tentar implantar de um projeto usando uma imagem armazenada no Artifact Registry em outro projeto:

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 o problema, siga estas recomendações para solucionar problemas:

  • Siga as instruções para implantar imagens de contêiner de outros projetos do Google Cloud para garantir que seus principais tenham as permissões necessárias.

  • Esse problema também poderá ocorrer se o projeto estiver em um perímetro do VPC Service Controls com uma restrição na API Cloud Storage que proíbe solicitações do agente de serviço do Cloud Run. Para corrigir isso, faça o seguinte:

    1. Abra o Explorador de registros no console do Google Cloud . Não use a página Registros na página do Cloud Run:

      Acessar o Explorador de registros

    2. Digite 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 você vir alguma entrada de registro depois de usar esta consulta, examine-a e determine se é necessário atualizar as políticas do VPC Service Controls. Eles podem indicar que você precisa adicionar service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a uma política de acesso preexistente.

Permissões ausentes para implantações de origem

Os seguintes erros podem ocorrer ao fazer a implantação 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 acessa outros recursos. Essa conta de serviço pode ser a padrão (PROJECT_NUMBER-compute@developer.gserviceaccount.com) ou uma conta gerenciada pelo usuário.

Em ambientes em que vários serviços acessam recursos diferentes, você pode usar identidades por serviço com contas de serviço gerenciadas pelo usuário diferentes em vez da conta de serviço padrão.

Para resolver esse problema, conceda à conta do implantador o papel Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço usada como identidade do serviço. Esse papel predefinido contém a permissão iam.serviceAccounts.actAs, que é necessária para anexar uma conta de serviço ao serviço ou revisão. Um usuário que cria uma conta de serviço gerenciada pelo usuário recebe automaticamente a permissão iam.serviceAccounts.actAs. No entanto, outros implantadores precisam que essa permissão seja concedida pelo usuário que cria a conta de serviço gerenciada pelo usuário.

Para mais informações sobre os requisitos de acesso de novas contas de serviço criadas, consulte Receber recomendações para criar contas de serviço dedicadas.

O usuário não tem permissões suficientes para concluir implantações de origem

O seguinte erro ocorre quando a conta do implantador não tem as permissões necessárias no 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 esse erro, peça ao administrador para conceder a você os seguintes papéis do gerenciamento de identidade e acesso:

Erro ao implantar um serviço do Cloud Run de outros projetos Google Cloud

O seguinte erro ocorre ao implantar um serviço do Cloud Run 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 o problema, siga estas etapas:

  1. Conceda o papel Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço usada como identidade do serviço no projeto de destino.

  2. Conceda o papel Criador de token da conta de serviço (roles/iam.serviceAccountTokenCreator) à conta de serviço do Cloud Run no projeto de destino. Adicione o e-mail 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 instruções detalhadas, consulte Configurar a identidade de serviço para serviços.

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

Ao implantar um serviço do Cloud Run do código-fonte com o ambiente de execução do Python, um dos seguintes erros ocorre:

  • 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 implantação é concluída com códigos de erro HTTP 500 nos registros.

O buildpack do Python define o ponto de entrada padrão para implantações de origem do Cloud Run. Para o Python versão 3.13 e mais recentes, o buildpack do Python define o ponto de entrada com base na configuração do serviço da Web no arquivo requirements.txt. Se você não especificar um servidor da Web ou framework no arquivo requirements.txt ou usar a versão 3.12 ou anterior do Python, o buildpack do Python definirá o ponto de entrada padrão como gunicorn -b :8080 main:app. Para mais informações, consulte Criar um aplicativo em Python.

É possível resolver esse problema de várias maneiras. Por exemplo, é possível especificar um dos seguintes servidores da Web no arquivo 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

Ou siga uma destas etapas para resolver erros de implantação:

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

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

    Substitua:

    • SERVICE: o nome do serviço em que você quer implantar.
    • ENTRYPOINT: o ponto de entrada padrão que você quer usar para o código fonte.

  • Use um Procfile para definir um ponto de entrada.

Erros de veiculação

Nesta seção, listamos problemas de veiculação que você pode encontrar e fornecemos sugestões de como corrigir cada um deles.

HTTP 404: não encontrado

Este problema ocorre durante a veiculação:

`HTTP 404`:Not found

Você pode encontrar erros HTTP 404 nos seguintes cenários:

  1. Um URL de solicitação ou código de aplicativo incorreto retorna erros 404. Para resolver esse problema, siga estas etapas:

    1. Verifique se o URL solicitado está correto. Você pode verificar o URL na página de detalhes do serviço no console Google Cloud ou executando o seguinte comando:

      gcloud run services describe SERVICE_NAME | grep URL

    2. Inspecione onde o app retorna códigos de erro 404. Se o app retornar 404, ele vai aparecer no Cloud Logging. Além disso, verifique se o app não retorna um código de erro 404 quando você o executa localmente.

    3. Verifique se o app não começa a detectar a porta configurada antes de estar pronto para receber solicitações.

  2. A solicitação não chega ao contêiner, resultando em um erro 404 nos seguintes cenários:

    Em ambos os cenários, não é possível encontrar o erro 404 no Cloud Logging, mesmo quando você 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 configurações de entrada, a solicitação pode ser bloqueada pelo VPC Service Controls com base no contexto do autor da chamada, incluindo o projeto e o endereço IP. Para verificar se há uma violação da política do VPC Service Controls:

    1. Abra o Explorador de registros no Google Cloud console:

      Acessar o Explorador de registros

    2. Digite 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 você vir entradas de registro depois de usar essa consulta, examine-as para determinar se é necessário atualizar as políticas do VPC Service Controls.

  4. Acesse o endpoint do serviço com um balanceador de carga usando o ambiente de execução do Python. Para resolver esse problema, verifique a máscara de URL do balanceador de carga e garanta que o caminho do URL especificado para o balanceador de carga corresponda ao caminho no código-fonte do Python.

Nenhuma instância de contêiner disponível

Este erro ocorre durante a veiculaçã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 esse problema, verifique a métrica Contagem de instâncias do contêiner do seu serviço e considere aumentar esse limite se o uso estiver próximo do máximo. Para mais informações, consulte Definir o número máximo de instâncias para serviços e, se precisar de mais instâncias, solicite um aumento de cota.

O Cloud Run não pôde gerenciar a taxa de tráfego

O erro a seguir ocorre durante a veiculação ou quando o serviço não atingiu o limite máximo de instâncias de contêiner:

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

Para resolver o problema, siga estas etapas:

  1. Resolva as seguintes possíveis causas raiz:

    • Um grande aumento repentino no tráfego
    • Um longo tempo de inicialização a frio
    • Um longo tempo de processamento de uma solicitação ou um aumento repentino no tempo de processamento da solicitação.
    • O serviço atinge o limite máximo de instâncias de contêiner (HTTP 429).
    • Fatores temporários atribuídos ao serviço do Cloud Run.

  2. Implemente a espera exponencial e novas tentativas para solicitações que o cliente não pode descartar. Um aumento curto e repentino no tráfego ou no tempo de processamento da solicitação só ficará visível no Cloud Monitoring se você aumentar o zoom para uma resolução de 10 segundos.

  3. Quando a causa raiz do problema for um período de erros temporários maiores atribuíveis exclusivamente ao Cloud Run, entre em contato com o suporte.

A instância do Cloud Run não é iniciada

Este erro ocorre durante a veiculação:

HTTP 500
The request failed because the instance could not start successfully.

Esse erro ocorre quando o contêiner não inicia e não fica íntegro dentro do tempo configurado. Isso pode ter várias causas, mas um motivo comum é a incapacidade do contêiner de acessar um segredo necessário do Secret Manager.

Para resolver esse problema, faça o seguinte:

  1. Verifique as permissões do IAM: confira se a conta de serviço do Cloud Run tem o papel Acessador de secret do Secret Manager (roles/secretmanager.secretAccessor) no secret que você está tentando acessar.

  2. Verifique o caminho secreto: confira se você especificou o nome e a versão corretos do secreto na configuração do aplicativo.

  3. Inspecione a configuração de rede: se você estiver usando um perímetro do VPC Service Controls ou regras de firewall, verifique se permite o tráfego de saída para secretmanager.googleapis.com.

  4. Gere registros eficazes: adicione logging ao processo de inicialização do aplicativo, principalmente ao buscar secrets, para diagnosticar falhas específicas.

A operação não foi implementada.

O seguinte erro ocorre quando você especifica um REGION incorreto ao invocar seu job do Cloud Run, como quando você implanta um job na região asia-southeast1 e invoca o job usando southeast1-asia ou asia-southeast:

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

Para conferir a lista de regiões compatíveis, consulte Locais do Cloud Run.

Credenciais padrão não encontradas

O erro a seguir ocorre quando o aplicativo não é autenticado corretamente devido a arquivos ausentes, 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 o problema:

  1. Instale e inicialize a CLI gcloud.

  2. Configure o Application Default Credentials (ADC) com as credenciais associadas à sua Conta do Google. Configure o ADC usando:

      gcloud auth application-default login

    Uma tela de login é exibida. Após o login, suas credenciais são armazenadas no arquivo de credenciais local, usado pelo ADC.

  3. Use a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS para fornecer o local de um arquivo JSON de credencial no seu projeto Google Cloud .

    Para mais informações, consulte Configurar o Application Default Credentials.

As instâncias de contêiner excedem os limites de memória

O seguinte erro HTTP 500 ou HTTP 503 ocorre durante a veiculaçã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 o problema:

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

No Cloud Run, os arquivos gravados no sistema de arquivos local são contabilizados na memória disponível. Isso também inclui todos os arquivos de registro gravados em locais diferentes de /var/log/* e /dev/log.

Não foi possível processar algumas solicitações devido à alta configuração de simultaneidade

O erro a seguir ocorre quando as instâncias de contêiner estão usando uma carga alta de CPU para processar solicitações e, como resultado, não conseguem processar todas as solicitações:

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

Para resolver o problema, siga estas etapas:

  1. Aumente o número máximo de instâncias de contêiner para o serviço.

  2. Reduzir a simultaneidade do serviço. Para mais informações, consulte Definir o máximo de solicitações simultâneas por instância.

Erros do Cloud Logging relacionados a cancelamentos de solicitações de filas pendentes

Um dos erros a seguir ocorre quando o Cloud Run não consegue escalonar rápido o suficiente para gerenciar 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 o problema, siga estas etapas:

  1. Resolva as causas raiz que podem causar falhas de escalonamento, como:

    • Um grande aumento repentino no tráfego
    • Tempo longo de inicialização a frio.
    • Tempo de processamento de solicitação longo.
    • Alta taxa de erros no código-fonte.
    • Atingir o limite máximo de instâncias e impedir o escalonamento do sistema.
    • Fatores temporários atribuídos ao serviço do Cloud Run.

    Para mais informações sobre como resolver problemas de escalonamento e otimizar o desempenho, consulte Dicas gerais de desenvolvimento.

  2. Para serviços ou funções baseadas em gatilho HTTP, faça com que o cliente implemente a espera exponencial e tente novamente para solicitações que não podem ser descartadas. Se você estiver acionando serviços do Workflows, use a sintaxe try/retry para fazer isso.

  3. Para serviços ou funções em segundo plano ou orientados a eventos, o Cloud Run oferece suporte à entrega pelo menos uma vez. Mesmo sem ativar explicitamente a nova tentativa, o Cloud Run reenvia automaticamente o evento e tenta executar de novo. Consulte Como repetir funções orientadas a eventos para mais informações.

  4. Para problemas relacionados a inicializações a frio, configure instâncias mínimas para reduzir a quantidade de inicializações a frio com uma implicação de faturamento maior.

  5. Quando a causa raiz do problema for um período de erros transitórios elevados atribuídos exclusivamente ao Cloud Run ou se você precisar de ajuda para resolver o problema, entre em contato com o suporte.

Assinatura do token de identidade editada pelo Google

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

SIGNATURE_REMOVED_BY_GOOGLE

Esse erro pode ocorrer nos seguintes cenários:

  • O usuário faz login usando a CLI do Google Cloud ou o Cloud Shell.

  • O usuário gera um token de ID usando comandos gcloud.

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

Esse é o comportamento padrão esperado. O Google remove a assinatura do token devido a questões de segurança para evitar que serviços não públicos do Cloud Run reproduzam tokens de ID gerados dessa forma.

Para resolver esse problema, invoque o seu serviço privado com um novo token de ID. Para mais informações, consulte Testar seu serviço particular.

Aviso do OpenBLAS nos registros

Se você usa bibliotecas baseadas em OpenBLAS, como o NumPy com o ambiente de execução de primeira geração, talvez veja o seguinte aviso nos registros:

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

O aviso do OpenBLAS ocorre quando o sandbox de contêiner usado pelo ambiente de execução de primeira geração não expõe recursos de hardware de baixo nível. Esse aviso não afeta seu serviço. Para evitar entradas de registro de avisos do OpenBLAS, mude para o ambiente de execução de segunda geração.

O Spark falha ao conseguir o endereço IP da máquina a ser vinculado

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

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 esse problema, defina a variável de ambiente SPARK_LOCAL_IP como 127.0.0.1 no Dockerfile. Por exemplo, ENV SPARK_LOCAL_IP="127.0.0.1". Se você não definir a variável de ambiente SPARK_LOCAL_IP, ela vai usar como padrão a contraparte IPv6 em vez de 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 acessar arquivos usando NFS

Erro Solução sugerida
mount.nfs: Protocol not supported Algumas imagens de base, como debian e adoptopenjdk/openjdk11, não têm a dependência nfs-kernel-server.
mount.nfs: Connection timed out Se a conexão expirar, verifique se você está fornecendo o endereço IP correto da instância do Filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Se o acesso tiver sido negado pelo servidor, verifique se o nome do compartilhamento de arquivos está correto.

Não é possível acessar arquivos usando o Cloud Storage FUSE

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

Alta latência quando a utilização da CPU é baixa

Seu serviço pode apresentar latências de solicitação altas ou não ser escalonado verticalmente sob carga, mesmo que o Cloud Monitoring mostre que a utilização média da CPU está bem abaixo da meta de escalonamento típica de 60%.

Possível causa:

Isso pode acontecer se o aplicativo for de uma única linha de execução para tarefas vinculadas à CPU, mas for implantado em uma instância com várias vCPUs. Seu aplicativo pode maximizar um núcleo de vCPU enquanto outros permanecem quase inativos. O escalonador automático do Cloud Run usa a utilização média da CPU em todas as vCPUs. Essa média pode ser baixa nesses casos, o que impede o escalonamento com base na CPU.

Soluções:

  • Para aplicativos com thread único:
    • Prefira configurar o serviço com uma vCPU se os requisitos de memória puderem ser atendidos. Consulte Limites de memória e mínimos de CPU. Isso ajuda as métricas de utilização da CPU a refletir a carga com precisão.
    • Se forem necessárias várias vCPUs devido a necessidades de memória alta que excedam os limites de uma vCPU, o escalonamento automático baseado em CPU provavelmente será menos eficaz. Nesse cenário, diminua a configuração de simultaneidade máxima para incentivar o escalonamento mais cedo com base na capacidade de processamento de solicitações. Consulte Configuração de simultaneidade.
  • Para configurações com várias vCPUs: verifique se o aplicativo foi arquitetado para usar todas as vCPUs alocadas de maneira eficaz (por exemplo, usando vários processos ou linhas de execução de worker).

Erros de conectividade e segurança

Nesta seção, descrevemos os erros comuns de conectividade e segurança no Cloud Run e os métodos para resolver problemas.

O cliente não foi autenticado corretamente

Este erro ocorre durante a veiculação:

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

Para resolver o problema:

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

    • Se você definir o aud como o URL do serviço de recebimento usando o formato https://SERVICE.run.app ou https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, seu serviço precisará exigir autenticação. Invoque o serviço do Cloud Run usando o URL do Cloud Run ou um URL do balanceador de carga. Para exemplos de como enviar solicitações autenticadas, consulte Invocar com uma solicitação HTTPS.

    • Se você definir o aud como o ID do cliente de um ID do cliente OAuth 2.0 com o tipo Aplicativo da Web, usando o formato nnn-xyz.apps.googleusercontent.com, será possível invocar o serviço do Cloud Run por um balanceador de carga HTTPS protegido por IAP. Recomendamos essa abordagem para um balanceador de carga de aplicativo com suporte de vários serviços do Cloud Run em regiões diferentes.

    • Se você definir o aud como 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 declaração de público-alvo também precisará ser https://service.example.com.

  2. Verifique se suas solicitações incluem um cabeçalho Authorization: Bearer ID_TOKEN ou um cabeçalho X-Serverless-Authorization: Bearer ID_TOKEN para autorização personalizada e se o token é um token de ID, não um token de acesso ou de atualização. Um erro 401 pode ocorrer nos seguintes cenários devido a um formato de autorização incorreto:

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

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

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

    • Vários cabeçalhos de autorização estão presentes na solicitação.

    Para verificar declarações em um JWT, use a ferramenta jwt.io.

  3. Se você receber tokens inválidos ao usar o servidor de metadados para buscar tokens de ID e acesso para autenticar solicitações com a identidade do serviço ou job do Cloud Run com um proxy HTTP para rotear o tráfego de saída, adicione os hosts a seguir às exceções de proxy HTTP:

    • 169.254.* ou 169.254.0.0/16

    • *.google.internal

  4. Um erro 401 geralmente ocorre quando as bibliotecas de cliente do Cloud usam o servidor de metadados para buscar o Application Default Credentials e autenticar as invocações REST ou gRPC. Se você não definir as exceções do proxy HTTP, o seguinte comportamento vai ocorrer:

    • Se diferentes Google Cloud workloads hospedarem um serviço ou job do Cloud Run e o proxy HTTP, mesmo que as bibliotecas de cliente do Cloud busquem as credenciais, a conta de serviço atribuída ao workload do proxy HTTP vai gerar os tokens. Os tokens podem não ter as permissões necessárias para realizar as operações pretendidas da Google Cloud API. Isso ocorre porque a conta de serviço busca os tokens na visualização do servidor de metadados da carga de trabalho do proxy HTTP, em vez do serviço ou job do Cloud Run.

    • Se o proxy HTTP não estiver hospedado em Google Cloud, e você rotear as solicitações do servidor de metadados usando o proxy, as solicitações de token vão falhar, e as operações das APIs doGoogle Cloud não serão autenticadas.

  5. Reimplante o serviço para permitir o acesso público se for compatível com a sua organização. Isso é útil para testes.

O cliente não está autorizado a invocar o serviço

Um dos seguintes erros ocorre ao invocar o 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.

Um erro 403 pode ocorrer quando o membro do IAM usado para gerar o token de autorização não tem a permissão run.routes.invoke. Conceda essa permissão ao usuário que está gerando o token.

Além disso, se houver uma entrada para o erro com o formato resource.type = "cloud_run_revision" no Cloud Logging, siga estas etapas para resolver o problema:

  1. Para que seu serviço possa ser chamado por qualquer pessoa, atualize as configurações do IAM e torne o serviço público.

  2. Para que seu serviço possa ser invocado apenas por determinadas identidades, invoque-o com o token de autorização apropriado:

    • Se um desenvolvedor ou um usuário final invocar seu serviço, conceda a permissão run.routes.invoke. É possível conceder essa permissão com os papéis de administrador do Cloud Run (roles/run.admin) e invocador do Cloud Run (roles/run.invoker).

    • Se uma conta de serviço invocar seu serviço, verifique se ela é membro do serviço do Cloud Run e conceda o papel de invocador do Cloud Run (roles/run.invoker).

    • Chamadas sem um token de autenticação podem causar o erro 403. Se as chamadas com um token de autenticação válido ainda resultarem no erro 403, conceda ao membro do IAM que gera o token a permissão run.routes.invoke.

Quando você encontra um erro 403 e não encontra a entrada de registro resource.type = "cloud_run_revision", isso pode ser causado pelo VPC Service Controls, que bloqueia um serviço do Cloud Run com configurações de entrada definidas como All. Para mais informações sobre como solucionar problemas de negações do VPC Service Controls, consulte erros 404.

Erro ao acessar o serviço em um navegador da Web

O problema a seguir ocorre quando você acessa um serviço do Cloud Run em um navegador da Web:

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

Quando você invoca um serviço do Cloud Run em um navegador da Web, ele envia uma solicitação GET para o serviço. No entanto, a solicitação não contém o token de autorização do usuário que faz a chamada. Para resolver esse problema, siga estas etapas:

  1. Use o Identity-Aware Proxy (IAP) com o Cloud Run. Com o IAP, é possível estabelecer uma camada de autorização central para aplicativos acessados por HTTPS. Com o IAP, é possível usar um modelo de controle de acesso no nível do aplicativo em vez de firewalls no nível da rede. Para mais detalhes sobre como configurar o Cloud Run com o IAP, consulte Como ativar o Identity-Aware Proxy para o Cloud Run.

  2. Como solução temporária, acesse seu serviço em um navegador da Web usando o proxy do Cloud Run na Google Cloud CLI. Para fazer proxy de um serviço localmente, execute o seguinte comando:

    gcloud run services proxy SERVICE --project PROJECT-ID

    O Cloud Run redireciona o serviço particular para http://localhost:8080 (ou para a porta especificada com --port), fornecendo o token da conta ativa ou outro token especificado. Essa é a maneira recomendada de testar de forma particular um site ou uma API no seu navegador. Para mais informações, consulte Como testar serviços privados.

  3. Permitir acesso público ao seu serviço. Isso é útil para testes ou quando o serviço é uma API ou site público.

Conexão redefinida pelo par

Um dos seguintes erros ocorre quando um peering na rede fecha inesperadamente a conexão TCP estabelecida pelo aplicativo:

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 o problema, siga estas etapas:

  • Se você estiver tentando executar o trabalho em segundo plano com a limitação de CPU, use a configuração de faturamento baseado em instâncias.

  • Verifique se você está dentro dos tempos limite das solicitações de saída. Se o aplicativo mantiver qualquer conexão em um estado inativo além desse limite, o gateway precisará conseguir a conexão.

  • Por padrão, a opção de soquete TCP keepalive está desativada para o Cloud Run. Não há uma maneira direta de configurar a opção keepalive no nível do serviço. Para ativar a opção keepalive em cada conexão de soquete, forneça as opções de soquete necessárias ao abrir uma nova conexão de soquete TCP, dependendo da biblioteca de cliente que você está usando para essa conexão no aplicativo.

  • Às vezes, conexões de saída são redefinidas devido a atualizações de infraestrutura. Se o aplicativo reutilizar conexões de longa duração, recomendamos configurá-lo para restabelecer as conexões e evitar a reutilização de uma conexão inativa.

  • Se você estiver usando um proxy HTTP para rotear o tráfego de saída de jobs ou serviços do Cloud Run, e o proxy aplicar a duração máxima da conexão, o proxy poderá descartar silenciosamente as conexões TCP de longa duração, como as estabelecidas usando pools de conexão. Isso faz com que clientes HTTP falhem ao reutilizar uma conexão já fechada. Se você pretende rotear o tráfego de saída por um proxy HTTP, implemente validação de conexão, novas tentativas e espera exponencial. Para pools de conexões, configure os valores máximos de idade da conexão, conexões inativas e tempo limite de inatividade da conexão.

Tempos limite de conexão

Os erros a seguir ocorrem quando um aplicativo tenta criar uma nova conexão TCP com um host remoto e a conexão demora muito para ser estabelecida:

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 tempo limite de conexão, siga estas etapas:

  1. Se você estiver roteando todo o tráfego de saída por uma rede VPC, usando conectores de VPC ou saída direta da VPC, siga estas etapas:

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

    • As regras de firewall da VPC precisam permitir o tráfego de entrada dos conectores da VPC ou da sub-rede de saída da VPC direta para alcançar o host ou a sub-rede de destino.

    • Verifique se você tem todas as rotas necessárias para permitir o roteamento correto do tráfego para os hosts de destino e de volta. Isso é importante ao rotear o tráfego de saída por meio de peering de rede VPC ou conectividade de nuvem híbrida, já que os pacotes atravessam várias redes antes de chegar ao host remoto.

  2. Se você estiver usando um proxy HTTP para rotear todo o tráfego de saída dos serviços ou jobs do Cloud Run, os hosts remotos precisam ser acessíveis usando o proxy.

    Dependendo da utilização dos recursos do proxy, o tráfego roteado por um proxy HTTP pode atrasar. Se você estiver roteando o tráfego de saída HTTP usando um proxy, implemente novas tentativas, espera exponencial ou disjuntores.

Configurar exceções de proxy HTTP

Ao usar um proxy HTTP para rotear o tráfego de saída de jobs ou serviços do Cloud Run, adicione exceções para APIs do Cloud e outros hosts e sub-redes sem proxy para evitar latência, tempos limite de conexão, redefinições de conexão e erros de autenticação.

Hosts e sub-redes sem proxy precisam incluir, no mínimo, o seguinte:

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

Como opção, os hosts 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. Essa propriedade do sistema se aplica a HTTP e HTTPS.

    • A propriedade do sistema http.nonProxyHosts não é compatível com a notação CIDR. É necessário usar expressões de correspondência de padrões.

Resposta incorreta ou problema de conexão da instância do contêiner

O seguinte erro ocorre quando há um problema de conexão da instância do contêiner:

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

Para resolver o problema, siga estas etapas:

  1. Verifique o Cloud Logging para os seguintes erros:

    • Erros de falta de memória. Se os registros contiverem mensagens de erro relacionadas a instâncias de contêiner que excedem os limites de memória, consulte as recomendações na seção As instâncias de contêiner estão excedendo os limites de memória.

    • Falhas na sondagem de atividade com o seguinte erro nos registros:

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

      Quando a instância não responde à sondagem dentro do período de tempo limite, siga estas etapas:

  2. Se as solicitações forem encerradas com o código de erro 503 antes de atingir o tempo limite da solicitação definido no Cloud Run, atualize a configuração de tempo limite da solicitação para o framework da linguagem:

  3. Em alguns cenários, um código de erro 503 pode ocorrer devido a um gargalo de rede downstream, como durante o teste de carga. Por exemplo, se o serviço direciona o tráfego por um conector de acesso VPC sem servidor, siga estas etapas para garantir que o conector não exceda o limite de capacidade:

    1. Abra o acesso VPC sem servidor no console Google Cloud :

      Página do console sobre o acesso VPC sem servidor

    2. Verifique se há barras vermelhas no histograma do gráfico de capacidade. Se houver uma barra vermelha, considere aumentar o número máximo de instâncias ou o tipo de instância que seu conector usa. Como alternativa, compacte o tráfego enviado por um conector de acesso VPC sem servidor.

  4. Se uma instância de contêiner receber mais de 800 solicitações por segundo, os soquetes TCP disponíveis poderão ser esgotados. Para resolver isso, ative o HTTP/2 no seu serviço e faça as mudanças necessárias para que ele seja compatível com o HTTP/2.

Erro de tempo limite do gateway

O erro a seguir ocorre quando o serviço não retorna uma resposta dentro de um tempo especificado, e a solicitação é encerrada:

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

Para mais informações sobre esse erro, consulte o contrato do ambiente de execução do contêiner.

Para solucionar esse problema, siga estas etapas:

  • Se o serviço estiver processando solicitações longas, aumente o tempo limite da solicitação.

  • Instrumente a geração de registros e o rastreamento para entender onde seu app está passando tempo antes de exceder o tempo limite configurado da solicitação.

  • As conexões de saída são redefinidas às vezes devido a atualizações de infraestrutura. Se o aplicativo reutilizar conexões de longa duração, recomendamos configurá-lo para restabelecer as conexões e evitar a reutilização de uma conexão inativa.

    Dependendo da lógica do app ou do tratamento de erros, um erro 504 pode ser um sinal de que seu app está tentando reutilizar uma conexão inativa e que a solicitação bloqueia até o tempo limite configurado da solicitação. Use uma sondagem de atividade para encerrar uma instância que retorna erros persistentes.

  • Erros de falta de memória que acontecem no código do app, por exemplo, java.lang.OutOfMemoryError, não necessariamente encerram uma instância de contêiner. Se o uso da memória não exceder o limite de memória do contêiner, o Cloud Run não vai encerrar a instância. Dependendo de como o app trata erros de memória insuficiente, as solicitações podem não ser processadas até excederem o tempo limite configurado.

    Para encerrar a instância de contêiner, siga estas etapas:

    • Configure o limite de memória no nível do app para ser maior que o limite de memória do contêiner.

    • Use uma sondagem de atividade para ajudar a encerrar uma instância que retorna erros persistentes.

Domínio personalizado travado durante o provisionamento do certificado

Um dos seguintes erros ocorre ao mapear 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 o problema:

  1. Aguarde pelo menos 24 horas. O provisionamento do certificado SSL geralmente leva cerca de 15 minutos, mas pode levar até 24 horas.

  2. Verifique se você atualizou corretamente os registros DNS no registrador de domínios usando a ferramenta de escavação do Google Admin Toolbox. Os registros DNS no registrador de domínios precisam corresponder ao que o console doGoogle Cloud solicita a adicionar.

  3. Verifique a raiz do domínio na sua conta usando um destes métodos:

  4. Verifique se o certificado do domínio não expirou. Para encontrar os limites de expiração, use este 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 é propagada para o Cloud Run

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

Para resolver esse problema, use Websockets ou HTTP/2.0, que propagam desconexões do cliente.