Resolva problemas de eventos CrashLoopBackOff

Se os seus pods no Google Kubernetes Engine (GKE) estiverem bloqueados num estado CrashLoopBackOff, significa que um ou mais contentores estão a ser iniciados repetidamente e, em seguida, a serem terminados. Este comportamento está provavelmente a tornar as suas apps instáveis ou completamente indisponíveis.

Use esta página para diagnosticar e resolver as causas subjacentes, que se enquadram frequentemente em categorias como limitações de recursos, problemas com sondagens de atividade, erros de apps ou erros de configuração. A resolução destes problemas ajuda a garantir que as suas apps são executadas de forma fiável e permanecem disponíveis para os seus utilizadores.

Estas informações são importantes para os programadores de aplicações que querem identificar e corrigir problemas ao nível da app, como erros de programação, pontos de entrada incorretos, problemas com ficheiros de configuração ou problemas de ligação a dependências. Os administradores e os operadores da plataforma podem identificar e resolver problemas relacionados com a plataforma, como esgotamento de recursos (OOMKilled), interrupções de nós ou sondas de atividade mal configuradas. Para mais informações sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

Compreenda um evento CrashLoopBackOff

Quando o seu pod está bloqueado num estado CrashLoopBackOff, um contentor no mesmo está a ser iniciado e a falhar ou a ser terminado repetidamente. Este CrashLoop aciona o Kubernetes para tentar reiniciar o contentor seguindo o respetivo restartPolicy. Com cada reinício falhado, o atraso de BackOff antes da próxima tentativa aumenta exponencialmente (por exemplo, 10 s, 20 s, 40 s) até um máximo de cinco minutos.

Embora este evento indique um problema no seu contentor, também é um sinal de diagnóstico valioso. Um evento CrashLoopBackOff confirma que muitos passos fundamentais da criação de pods, como a atribuição a um nó e a obtenção da imagem do contentor, já foram concluídos. Este conhecimento permite-lhe focar a sua investigação na app ou na configuração do contentor, em vez de na infraestrutura do cluster.

O estado CrashLoopBackOff ocorre devido à forma como o Kubernetes, especificamente o kubelet, processa o encerramento do contentor com base na política de reinício do pod. Normalmente, o ciclo segue este padrão:

  1. O contentor é iniciado.
  2. O contentor é terminado.
  3. O kubelet observa o contentor parado e reinicia-o de acordo com o restartPolicy do pod.
  4. Este ciclo repete-se, com o contentor reiniciado após um atraso de retirada exponencial cada vez maior.

O restartPolicy do Pod é a chave para este comportamento. A política predefinida, Always, é a causa mais comum deste ciclo, porque reinicia um contentor se este for terminado por qualquer motivo, mesmo após uma saída bem-sucedida. É menos provável que a política OnFailure cause um ciclo porque só é reiniciada em códigos de saída diferentes de zero, e a política Never evita completamente um reinício.

Identifique os sintomas de um evento CrashLoopBackOff

Um Pod com o estado CrashLoopBackOff é a indicação principal de um evento CrashLoopBackOff.

No entanto, pode sentir alguns sintomas menos óbvios de um CrashLoopBackOff evento:

  • Zero réplicas em bom estado para uma carga de trabalho.
  • Uma diminuição acentuada nas réplicas em bom estado.
  • As cargas de trabalho com a escala automática horizontal de pods ativada estão a ser dimensionadas lentamente ou não estão a ser dimensionadas.

Se uma carga de trabalho system (por exemplo, um agente de registo ou de métricas) tiver o estado CrashLoopBackOff, também pode reparar nos seguintes sintomas:

  • Algumas métricas do GKE não são comunicadas.
  • Alguns painéis de controlo e gráficos do GKE têm lacunas.
  • Problemas de conetividade na rede ao nível do pod.

Se observar algum destes sintomas menos óbvios, o passo seguinte deve ser confirmar se ocorreu um evento CrashLoopBackOff.

Confirme um evento CrashLoopBackOff

Para confirmar e investigar um evento CrashLoopBackOff, recolha provas dos eventos do Kubernetes e dos registos da app do contentor. Estas duas fontes oferecem vistas diferentes, mas complementares do problema:

  • Os eventos do Kubernetes confirmam que um Pod está a falhar.
  • Os registos da app do contentor podem mostrar-lhe o motivo pelo qual o processo no contentor está a falhar.

Para ver estas informações, selecione uma das seguintes opções:

Consola

Para ver eventos do Kubernetes e registos de apps, faça o seguinte:

  1. Na Google Cloud consola, aceda à página Workloads.

    Aceda a Cargas de trabalho

  2. Selecione a carga de trabalho que quer investigar. O separador Vista geral ou Detalhes apresenta mais informações sobre o estado da carga de trabalho.

  3. Na secção Pods geridos, clique no nome do pod com problemas.

  4. Na página Detalhes do pod, investigue o seguinte:

    • Para ver detalhes sobre eventos do Kubernetes, aceda ao separador Eventos.
    • Para ver os registos da app do contentor, aceda ao separador Registos. É nesta página que encontra mensagens de erro ou rastreios de pilha específicos da app.

kubectl

Para ver eventos do Kubernetes e registos de apps, faça o seguinte:

  1. Veja o estado de todos os pods em execução no cluster:

    kubectl get pods

    O resultado é semelhante ao seguinte:

    NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

    No resultado, reveja as seguintes colunas:

    • Ready: reveja quantos contentores estão prontos. Neste exemplo, 0/1 indica que zero de um contentor esperado está num estado pronto. Este valor é um sinal claro de um problema.
    • Status: procure agrupamentos com o estado CrashLoopBackOff.
    • Restarts: um valor elevado indica que o Kubernetes está a tentar iniciar o contentor repetidamente e não está a conseguir.

  2. Depois de identificar um pod com falhas, descreva-o para ver eventos ao nível do cluster relacionados com o estado do pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Substitua o seguinte:

    • POD_NAME: o nome do pod que identificou no resultado do comando kubectl get.
    • NAMESPACE_NAME: o espaço de nomes do Pod.

    O resultado é semelhante ao seguinte:

    Containers:
container-name:
...
  State:          Waiting
    Reason:       CrashLoopBackOff
  Last State:     Terminated
    Reason:       StartError
    Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
    Exit Code:    128
    Started:      Thu, 01 Jan 1970 00:00:00 +0000
    Finished:     Fri, 27 Jun 2025 16:20:03 +0000
  Ready:          False
  Restart Count:  3459
...
Conditions:
Type                        Status
PodReadyToStartContainers   True
Initialized                 True
Ready                       False
ContainersReady             False
PodScheduled                True
...
Events:
Type     Reason   Age                     From     Message
----     ------   ----                    ----     -------
Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)

    Na saída, reveja os seguintes campos para detetar sinais de um evento CrashLoopBackOff:

    • State: o estado do contentor mostra provavelmente Waiting com o motivo CrashLoopBackOff.
    • Last State: o estado do contentor terminado anteriormente. Procure um estado Terminated e reveja o código de saída para ver se houve uma falha (código de saída diferente de zero) ou uma saída bem-sucedida inesperada (código de saída zero).
    • Events: ações tomadas pelo próprio cluster. Procure mensagens sobre o início do contentor, seguidas de falhas de sondagem de atividade ou avisos de recuo, como Back-off restarting failed container.

  3. Para saber mais sobre o motivo pelo qual o pod falhou, veja os registos da app:

    kubectl logs POD_NAME --previous

    A flag --previous obtém registos do contentor anterior terminado, que é onde pode encontrar o rastreio de pilha específico ou a mensagem de erro que revela a causa da falha do sistema. O contentor atual pode ser demasiado recente para ter registado registos.

    No resultado, procure erros específicos da app que fariam com que o processo fosse terminado. Se usar uma app personalizada, os programadores que a escreveram são os mais bem equipados para interpretar estas mensagens de erro. Se usar uma app pré-criada, estas apps oferecem frequentemente as suas próprias instruções de depuração.

Use o manual interativo de pods em ciclo de falhas

Depois de confirmar um evento CrashLoopBackOff, comece a resolver problemas com o seguinte manual interativo:

  1. Na Google Cloud consola, aceda à página GKE Interactive Playbook - Crashlooping Pods.

    Aceda a Crashlooping Pods

  2. Na lista Cluster, selecione o cluster que quer resolver. Se não conseguir encontrar o cluster, introduza o nome do cluster no campo Filtro.

  3. Na lista Espaço de nomes, selecione o espaço de nomes que quer resolver. Se não conseguir encontrar o seu espaço de nomes, introduza-o no campo Filtro.

  4. Trabalhe em cada secção para ajudar a responder às seguintes perguntas:

    1. Identifique erros da app: que contentores estão a ser reiniciados?
    2. Investigue problemas de falta de memória: existe uma configuração incorreta ou um erro relacionado com a app?
    3. Investigue interrupções de nós: as interrupções no recurso de nó estão a causar reinícios de contentores?
    4. Investigue falhas de sondagem de atividade: as sondagens de atividade estão a parar os seus contentores?
    5. Correlacionar eventos de alteração: o que aconteceu por volta da altura em que os contentores começaram a falhar?

  5. Opcional: para receber notificações sobre eventos CrashLoopBackOff futuros, na secção Sugestões de mitigação futuras, selecione Criar um alerta.

Se o problema persistir após usar o manual de soluções, leia o resto do guia para mais informações sobre a resolução de eventos CrashLoopBackOff.

Resolva um evento CrashLoopBackOff

As secções seguintes ajudam a resolver as causas mais comuns dos eventos CrashLoopBackOff:

Resolva o esgotamento de recursos

Um evento CrashLoopBackOff é frequentemente causado por um problema de falta de memória (OOM). Pode confirmar se esta é a causa se o resultado de kubectl describe mostrar o seguinte:

Last State: Terminated
  Reason: OOMKilled

Para obter informações sobre como diagnosticar e resolver eventos OOM, consulte o artigo Resolva problemas de eventos OOM.

Resolva falhas de sondagem de atividade

Uma sondagem de atividade é uma verificação do estado periódica realizada pelo kubelet. Se a sondagem falhar um número especificado de vezes (o número predefinido é três), o kubelet reinicia o contentor, o que pode causar um evento CrashLoopBackOff se as falhas de sondagem continuarem.

Confirme se a causa é uma sonda de atividade

Para confirmar se as falhas da sondagem de atividade estão a acionar o evento, consulte os registos do kubelet.CrashLoopBackOff Estes registos contêm frequentemente mensagens explícitas que indicam falhas de sondagem e reinícios subsequentes.

  1. Na Google Cloud consola, aceda à página Explorador de registos.

    Aceda ao Explorador de registos

  2. No painel de consulta, filtre os reinícios relacionados com a sondagem de atividade introduzindo a seguinte consulta:

    resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"

    Substitua CLUSTER_NAME pelo nome do seu cluster.

  3. Reveja o resultado. Se uma falha da sondagem de atividade for a causa dos seus eventos CrashLoopBackOff, a consulta devolve mensagens de registo semelhantes às seguintes:

    Container probe failed liveness probe, will be restarted

Depois de confirmar que as sondas de atividade são a causa do evento CrashLoopBackOff, avance para a resolução de problemas de causas comuns:

Reveja a configuração da sonda de atividade

As sondas configuradas incorretamente são uma causa frequente de eventos CrashLoopBackOff. Verifique as seguintes definições no manifesto da sua sondagem:

  • Verifique o tipo de teste: a configuração do teste tem de corresponder à forma como a sua app comunica o respetivo estado. Por exemplo, se a sua app tiver um URL de verificação de estado (como /healthz), use o tipo de sonda httpGet. Se o estado for determinado pela execução de um comando, use o tipo de sonda exec. Por exemplo, para verificar se uma porta de rede está aberta e a escutar, use o tipo de sondagem tcpSocket.
  • Verifique os parâmetros da sondagem:
    • Caminho (para o tipo de teste de sondagem httpGet): certifique-se de que o caminho HTTP está correto e que a sua app publica verificações de estado no mesmo.
    • Porta: verifique se a porta configurada na sondagem é realmente usada e exposta pela app.
    • Comando (para o tipo de sonda exec): certifique-se de que o comando existe no contentor, devolve um código de saída de 0 para êxito e é concluído no período timeoutSeconds configurado.
    • Tempo limite: certifique-se de que o valor timeoutSeconds é suficiente para a app responder, especialmente durante o arranque ou sob carga.
    • Atraso inicial (initialDelaySeconds): verifique se o atraso inicial é suficiente para a app ser iniciada antes do início das sondagens.

Para mais informações, consulte o artigo Configure Liveness, Readiness and Startup Probes na documentação do Kubernetes.

Inspecione a utilização da CPU e de I/O do disco

A contenção de recursos resulta em limites de tempo excedidos da sondagem, o que é uma das principais causas de falhas da sondagem de atividade. Para ver se a utilização de recursos é a causa da falha da sondagem de atividade, experimente as seguintes soluções:

  • Analisar a utilização da CPU: monitorize a utilização da CPU do contentor afetado e do nó no qual está a ser executado durante os intervalos de sondagem. Uma métrica importante a acompanhar é kubernetes.io/container/cpu/core_usage_time. A utilização elevada da CPU no contentor ou no nó pode impedir que a app responda à sondagem a tempo.
  • Monitorize a E/S do disco: verifique as métricas de E/S do disco para o nó. Pode usar a métrica compute.googleapis.com/guest/disk/operation_time para avaliar a quantidade de tempo gasto nas operações de disco, que são categorizadas por leituras e escritas. A E/S de disco elevada pode abrandar significativamente o início do contentor, a inicialização da app ou o desempenho geral da app, o que leva a limites de tempo de sondagem.

Abordar implementações grandes

Em cenários em que um grande número de pods é implementado em simultâneo (por exemplo, por uma ferramenta de CI/CD como o ArgoCD), um aumento súbito de novos pods pode sobrecarregar os recursos do cluster, o que leva à exaustão dos recursos do plano de controlo. Esta falta de recursos atrasa o arranque da app e pode fazer com que as sondas de atividade falhem repetidamente antes de as apps estarem prontas.

Para resolver este problema, experimente as seguintes soluções:

  • Implemente implementações faseadas: implemente estratégias para implementar pods em lotes ou durante um período mais longo para evitar sobrecarregar os recursos dos nós.
  • Reconfigure ou dimensione os nós: se as implementações faseadas não forem viáveis, considere atualizar os nós com discos mais rápidos ou maiores, ou Persistent Volume Claims, para lidar melhor com o aumento da procura de E/S. Certifique-se de que o ajuste automático do cluster está configurado corretamente.
  • Aguarde e observe: em alguns casos, se o cluster não tiver recursos insuficientes, as cargas de trabalho podem ser implementadas após um atraso significativo (por vezes, 30 minutos ou mais).

Resolva erros temporários

A app pode ter erros temporários ou abrandamentos durante o arranque ou a inicialização que fazem com que a sondagem falhe inicialmente. Se a app recuperar, considere aumentar os valores definidos nos campos initialDelaySeconds ou failureThreshold no manifesto da sua sondagem de atividade.

Resolva o consumo de recursos da sonda de endereço

Em casos raros, a execução da sondagem de atividade pode consumir recursos significativos, o que pode acionar restrições de recursos que podem levar à terminação do contentor devido a uma eliminação por falta de memória. Certifique-se de que os comandos de sondagem são simples. É mais provável que uma análise simples seja executada de forma rápida e fiável, o que lhe dá uma maior fidelidade na comunicação precisa do verdadeiro estado da sua app.

Resolva configurações incorretas de apps

As configurações incorretas da app causam muitos eventos CrashLoopBackOff. Para compreender por que motivo a sua app está a parar, o primeiro passo é examinar o respetivo código de saída. Este código determina o caminho de resolução de problemas:

  • O código de saída 0 indica uma saída bem-sucedida, o que é inesperado para um serviço de execução prolongada e aponta para problemas com o ponto de entrada do contentor ou o design da app.
  • Um código de saída diferente de zero indica uma falha da app, direcionando a sua atenção para erros de configuração, problemas de dependência ou erros no código.

Encontre o código de saída

Para encontrar o código de saída da sua app, faça o seguinte:

  1. Descreva o Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Substitua o seguinte:

    • POD_NAME: o nome do pod problemático.
    • NAMESPACE_NAME: o espaço de nomes do Pod.

  2. Na saída, reveja o campo Exit Code localizado na secção Last State para o contentor relevante. Se o código de saída for 0, consulte o artigo Resolva problemas de saídas bem-sucedidas (código de saída 0). Se o código de saída for um número diferente de 0, consulte o artigo Resolva problemas de falhas da app (código de saída diferente de zero).

Resolva problemas com saídas bem-sucedidas (código de saída 0)

Um código de saída de 0 significa normalmente que o processo do contentor terminou com êxito. Embora este seja o resultado pretendido para uma tarefa baseada em trabalhos, pode indicar um problema para um controlador de execução prolongada, como uma implementação, um StatefulSet ou um ReplicaSet.

Estes controladores funcionam para garantir que um Pod está sempre em execução, pelo que tratam qualquer saída como uma falha a corrigir. O kubelet aplica este comportamento ao seguir o restartPolicy do pod (que é Always por predefinição), reiniciando o contentor mesmo após uma saída bem-sucedida. Esta ação cria um ciclo que, em última análise, aciona o estado CrashLoopBackOff.

Os motivos mais comuns para saídas bem-sucedidas inesperadas são os seguintes:

  • O comando do contentor não inicia um processo persistente: um contentor permanece em execução apenas enquanto o respetivo processo inicial (command ou entrypoint) o fizer. Se este processo não for um serviço de execução prolongada, o contentor é terminado assim que o comando for concluído. Por exemplo, um comando como ["/bin/bash"] sai imediatamente porque não tem nenhum script para executar. Para resolver este problema, certifique-se de que o processo inicial do contentor inicia um processo que é executado continuamente.

  • A app de trabalho é fechada quando uma fila de trabalho está vazia: muitas apps de trabalho são concebidas para verificar se existe uma tarefa numa fila e sair corretamente se a fila estiver vazia. Para resolver este problema, pode usar um Job controller (concebido para tarefas que são executadas até à conclusão) ou modificar a lógica da app para ser executada como um serviço persistente.

  • A app é fechada devido a uma configuração em falta ou inválida: a sua app pode ser fechada imediatamente se lhe faltarem instruções de arranque obrigatórias, como argumentos de linha de comandos, variáveis de ambiente ou um ficheiro de configuração crítico.

    Para resolver este problema, inspecione primeiro os registos da sua app para ver mensagens de erro específicas relacionadas com o carregamento da configuração ou parâmetros em falta. Em seguida, verifique o seguinte:

    • Argumentos ou ambiente da app: certifique-se de que todos os argumentos da linha de comandos e variáveis de ambiente necessários são transmitidos corretamente ao contentor, conforme esperado pela sua app.
    • Presença do ficheiro de configuração: confirme se os ficheiros de configuração necessários estão nos caminhos esperados no contentor.
    • Conteúdo do ficheiro de configuração: valide o conteúdo e o formato dos seus ficheiros de configuração quanto a erros de sintaxe, campos obrigatórios em falta ou valores incorretos.

    Um exemplo comum deste problema é quando uma app está configurada para ler a partir de um ficheiro montado com um volume ConfigMap. Se o ConfigMap não estiver anexado, estiver vazio ou tiver chaves com nomes incorretos, uma app concebida para terminar quando a respetiva configuração estiver em falta pode parar com um código de saída de 0. Nestes casos, valide as seguintes definições: - O nome ConfigMap na definição de volume do Pod corresponde ao respetivo nome real. - As chaves no ConfigMap correspondem ao que a sua app espera encontrar como nomes de ficheiros no volume montado.

Resolva problemas de falhas de apps (código de saída diferente de zero)

Quando um contentor termina com um código diferente de zero, o Kubernetes reinicia-o. Se o problema subjacente que causou o erro for persistente, a app volta a falhar e o ciclo repete-se, culminando num estado CrashLoopBackOff.

O código de saída diferente de zero é um sinal claro de que ocorreu um erro na própria app, o que direciona os seus esforços de depuração para o respetivo funcionamento interno e ambiente. Os seguintes problemas causam frequentemente esta rescisão:

  • Erros de configuração: um código de saída diferente de zero aponta frequentemente para problemas com a configuração da app ou o ambiente em que está a ser executada. Verifique se a sua app tem estes problemas comuns:

    • Ficheiro de configuração em falta: a app pode não conseguir localizar ou aceder a um ficheiro de configuração necessário.
    • Configuração inválida: o ficheiro de configuração pode conter erros de sintaxe, valores incorretos ou definições incompatíveis, o que faz com que a app falhe.
    • Problemas de autorizações: a app pode não ter as autorizações necessárias para ler ou escrever o ficheiro de configuração.
    • Variáveis de ambiente: as variáveis de ambiente incorretas ou em falta podem fazer com que a app não funcione corretamente ou não seja iniciada.
    • entrypoint ou command inválido: o comando especificado no campo entrypoint ou command do contentor pode estar incorreto. Este problema pode ocorrer com imagens implementadas recentemente quando o caminho para o ficheiro executável está incorreto ou o próprio ficheiro não está presente na imagem do contentor. Esta configuração incorreta resulta frequentemente no código de saída 128.

    • Atualizações de imagens não controladas (etiqueta :latest): se as imagens da sua carga de trabalho usarem a etiqueta :latest, os novos pods podem extrair uma versão de imagem atualizada que introduza alterações significativas.

      Para ajudar a garantir a consistência e a reprodutibilidade, use sempre etiquetas de imagens específicas e imutáveis (por exemplo, v1.2.3) ou resumos SHA (por exemplo, sha256:45b23dee08...) em ambientes de produção. Esta prática ajuda a garantir que o conteúdo de imagem exato é extraído sempre.

  • Problemas de dependência: a sua app pode falhar se não conseguir estabelecer ligação aos outros serviços dos quais depende ou se não conseguir autenticar ou tiver autorizações insuficientes para aceder aos mesmos.

    • Serviço externo indisponível: a app pode depender de serviços externos (por exemplo, bases de dados ou APIs) que estão inacessíveis devido a problemas de conetividade de rede ou interrupções de serviço. Para resolver este problema, ligue-se ao Pod. Para mais informações, consulte o artigo Depurar pods em execução na documentação do Kubernetes.

      Depois de estabelecer ligação ao Pod, pode executar comandos para verificar o acesso a ficheiros, bases de dados ou testar a rede. Por exemplo, pode usar uma ferramenta como curl para tentar alcançar o URL de um serviço. Esta ação ajuda a determinar se um problema é causado por políticas de rede, DNS ou pelo próprio serviço.

    • Falhas de autenticação: a app pode não conseguir autenticar-se com serviços externos devido a credenciais incorretas. Inspeccione os registos do contentor para ver mensagens como 401 Unauthorized(credenciais inválidas) ou 403 Forbidden (autorizações insuficientes), que indicam frequentemente que a conta de serviço do pod não tem as funções do IAM necessárias para fazer chamadas de serviço Google Cloudexternas.

      Se usar a Federação de identidades de cargas de trabalho do GKE, verifique se o identificador principal tem as autorizações necessárias para a tarefa. Para mais informações sobre a concessão de funções de IAM a responsáveis através da Workload Identity Federation do GKE, consulte o artigo Configure a autorização e os responsáveis. Também deve verificar se a utilização de recursos do servidor de metadados do GKE não excedeu os respetivos limites.

    • Tempos limite: a app pode sofrer tempos limite quando aguarda respostas de serviços externos, o que provoca falhas de sistema.

  • Erros específicos da app: se a configuração e as dependências externas parecerem corretas, o erro pode estar no código da app. Inspecione os registos da app para verificar a existência destes erros internos comuns:

    • Exceções não processadas: os registos da app podem conter rastreios de pilha ou mensagens de erro que indicam exceções não processadas ou outros erros relacionados com o código.
    • Impasses ou bloqueios em direto: a app pode estar bloqueada num impasse, em que vários processos estão a aguardar a conclusão uns dos outros. Neste cenário, a app pode não sair, mas deixa de responder indefinidamente.
    • Conflitos de portas: a app pode não ser iniciada se tentar associar-se a uma porta que já esteja a ser usada por outro processo.
    • Bibliotecas incompatíveis: a app pode depender de bibliotecas ou dependências em falta ou incompatíveis com o ambiente de tempo de execução.

    Para encontrar a causa principal, inspecione os registos do contentor para ver uma mensagem de erro ou um rastreio de pilha específicos. Estas informações ajudam a decidir se deve corrigir o código da app, ajustar os limites de recursos ou corrigir a configuração do ambiente. Para mais informações sobre registos, consulte o artigo Acerca dos registos do GKE.

O que se segue?