Resolva problemas de registos em falta no GKE

Os problemas com o pipeline de registo no Google Kubernetes Engine (GKE) podem impedir que os registos do cluster sejam apresentados no Cloud Logging, o que dificulta os seus esforços de monitorização e depuração.

Use este documento para saber como validar configurações e autorizações, resolver problemas de recursos e desempenho, investigar filtros e o comportamento das aplicações, e resolver problemas de plataformas ou serviços que afetam os seus registos.

Estas informações são importantes para os administradores e os operadores da plataforma que mantêm a observabilidade do cluster e para qualquer pessoa que use o Cloud Logging para resolver problemas de operações do GKE. Para mais informações sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções de utilizador comuns do GKE e tarefas. Google Cloud

Para mais informações sobre como usar os registos para resolver problemas das suas cargas de trabalho e clusters, consulte o artigo Realize análises do histórico com o Cloud Logging.

Encontre a sua solução por sintoma

Se identificou um sintoma específico relacionado com os registos em falta, use a tabela seguinte para encontrar sugestões de resolução de problemas:

Categoria Sintoma ou observação Potencial causa Passos de resolução de problemas
Configuração Não são visíveis registos de nenhum cluster no projeto. A API Cloud Logging está desativada para o projeto. Verifique o estado da Cloud Logging API
Os registos estão em falta num cluster específico ou apenas determinados tipos de registos estão em falta. O registo ao nível do cluster está desativado para os tipos de registos necessários. Valide a configuração do registo de clusters
Faltam registos nos nós de um node pool específico. Os nós do conjunto de nós não têm o âmbito de acesso necessário. Valide os âmbitos de acesso do conjunto de nós
Os erros de autorização (401 ou 403) aparecem nos registos do agente de registo. A conta de serviço do nó não tem a autorização necessária. Valide as autorizações da conta de serviço do nó
Recursos e desempenho Os registos estão em falta intermitentemente ou vê erros RESOURCE_EXHAUSTED. O projeto está a exceder a quota de gravação da API Cloud Logging. Investigue a utilização da quota da Cloud Logging API
Faltam alguns registos de um nó específico, frequentemente durante um tráfego ou um carregamento elevado. O nó está a exceder os limites de débito do agente de registo ou não tem recursos (CPU ou memória) para processar registos. Investigue o débito do nó e a utilização de recursos
Filtragem e comportamento da aplicação Faltam sempre registos específicos que correspondem a um determinado padrão. Um filtro de exclusão de registos no Cloud Logging está a rejeitar os registos involuntariamente. Investigue os filtros de exclusão de registos
Os registos de um contentor estão significativamente atrasados ou aparecem apenas depois de o contentor sair. A saída da aplicação está totalmente em buffer, muitas vezes devido a piping stdout. Investigue o armazenamento em buffer e os atrasos nos registos do contentor
Os registos esperados não aparecem nos resultados da pesquisa. Os filtros de consultas no Explorador de registos podem ser demasiado restritivos. Investigue consultas do Explorador de registos
Não são visíveis registos de um pod de aplicação específico, mas estão presentes outros registos do cluster. A aplicação no contentor não está a escrever em stdout nem stderr. Investigue o comportamento de registo específico da aplicação
Plataforma e serviço Os registos anteriores a uma determinada data não são apresentados. Os registos ultrapassaram o período de retenção e foram eliminados pelo Cloud Logging. Investigue os períodos de retenção de registos
Perda ou atrasos generalizados de registos em projetos ou clusters. Problema do serviço Cloud Logging ou atraso na carregamento. Investigue problemas e atrasos do serviço Cloud Logging
Os problemas de registo coincidem com as limitações da versão do cluster. Versão do GKE não suportada. Investigue a versão do cluster

Use ferramentas de diagnóstico automáticas

As secções seguintes abordam ferramentas que podem inspecionar automaticamente o cluster para verificar se existem configurações incorretas comuns e ajudar a investigar problemas complexos.

Depure problemas de registo do GKE com o gcpdiag

Se estiverem em falta ou receber registos incompletos do seu cluster do GKE, use a ferramenta gcpdiag para a resolução de problemas.

gcpdiag é uma ferramenta de código aberto. Não é um produto Google Cloud suportado oficialmente. Pode usar a ferramenta gcpdiag para ajudar a identificar e corrigir Google Cloud problemas do projeto. Para mais informações, consulte o projeto gcpdiag no GitHub.

Quando os registos do cluster do GKE estão em falta ou incompletos, investigue as potenciais causas concentrando-se nas seguintes definições de configuração principais:

  • Registo ao nível do projeto: garante que o projeto que aloja o cluster do GKE tem a API Cloud Logging ativada. Google Cloud
  • Registo ao nível do cluster: verifica se o registo está explicitamente ativado na configuração do cluster do GKE.
  • Autorizações do conjunto de nós: confirma que os nós nos conjuntos de nós do cluster têm o âmbito Cloud Logging Write ativado, o que lhes permite enviar dados de registo.
  • Autorizações da conta de serviço: valida se a conta de serviço usada pelos conjuntos de nós tem as autorizações do IAM necessárias para interagir com o Cloud Logging. Especificamente, a função roles/logging.logWriter é normalmente necessária.
  • Quotas de gravação da API Cloud Logging: verifica se as quotas de gravação da API Cloud Logging não foram excedidas no período especificado.

Google Cloud consola

  1. Conclua e, em seguida, copie o seguinte comando. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Abra a Google Cloud consola e ative o Cloud Shell.
    3. Abra a Cloud Console
  3. Cole o comando copiado.
  4. Execute o comando gcpdiag, que transfere a imagem do Docker gcpdiag e, em seguida, faz verificações de diagnóstico. Se aplicável, siga as instruções de saída para corrigir as verificações com falhas.

Docker

Pode executar o gcpdiag usando um wrapper que inicia o gcpdiag num contentor do Docker. O Docker ou o Podman têm de estar instalados.

  1. Copie e execute o seguinte comando na sua estação de trabalho local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Execute o comando gcpdiag. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Veja os parâmetros disponíveis para este manual de procedimentos.

Substitua o seguinte:

  • PROJECT_ID: o ID do projeto que contém o recurso.
  • CLUSTER_NAME: o nome do cluster do GKE.
  • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.

Sinalizações úteis:

Para ver uma lista e uma descrição de todas as flags da ferramenta gcpdiag, consulte as gcpdiag instruções de utilização.

Use as investigações do Gemini Cloud Assist

Pondere usar investigações do Gemini Cloud Assist para obter mais estatísticas sobre os seus registos e resolver problemas. Para mais informações sobre as diferentes formas de iniciar uma investigação através do Logs Explorer, consulte o artigo Resolva problemas com as investigações do Gemini Cloud Assist na documentação do Gemini.

Valide a configuração e as autorizações de registo

As definições incorretas são um motivo comum para a falta de registos do GKE. Use as secções seguintes para validar a configuração do Cloud Logging.

Valide o estado da Cloud Logging API

Para que os registos sejam recolhidos de qualquer cluster no seu projeto, a API Cloud Logging tem de estar ativa.

Sintomas:

Não são visíveis registos de recursos do GKE no seu projeto no Cloud Logging.

Causa:

A API Cloud Logging está desativada para o projeto Google Cloud , o que impede o agente de registo nos nós de enviar registos.

Resolução:

Para verificar se a API Cloud Logging está ativada e ativá-la, se necessário, selecione uma das seguintes opções:

Consola

  1. Na Google Cloud consola, aceda à página APIs e serviços ativados.

    Aceda a APIs e serviços ativados

  2. No campo Filtrar, introduza Cloud Logging API e prima Enter.

  3. Se a API estiver ativada, vê-la listada. Se a API não estiver listada, ative-a:

    1. Clique em Ativar APIs e serviços.
    2. No campo Pesquisar, escreva Cloud Logging API e prima Enter.
    3. Clique no resultado Cloud Logging API.
    4. Clique em Ativar.

gcloud

  1. Verifique se a API está ativada:

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    O resultado deve ser o seguinte:

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Se a API não estiver listada nos serviços ativados, ative-a:

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Substitua PROJECT_ID pelo seu Google Cloud ID do projeto.

Valide a configuração do registo de clusters

O GKE permite-lhe configurar os tipos de registos (como SYSTEM ou WORKLOAD) que são recolhidos de um cluster.

Sintomas:

Não são apresentados registos no Cloud Logging de um cluster do GKE específico ou faltam apenas determinados tipos de registos (como SYSTEM).

Causa:

O registo ao nível do cluster está desativado para os tipos de registos necessários. Se estiver a usar um cluster do Autopilot, esta não é a causa dos seus problemas de registo. Esta definição é configurável para clusters padrão, mas está sempre ativada por predefinição em clusters do Autopilot e não pode ser desativada.

Resolução:

Para verificar e atualizar a configuração de registo do cluster, selecione uma das seguintes opções:

Consola

  1. Na Google Cloud consola, aceda à página Clusters do Kubernetes.

    Aceda aos clusters do Kubernetes

  2. Clique no nome do cluster que quer investigar.

  3. Clique no separador Detalhes e navegue para a secção Funcionalidades.

  4. Na linha Registo, reveja os tipos de registos, como Sistema ou Cargas de trabalho, que estão ativados.

  5. Se os tipos de registos que quer recolher estiverem desativados ou incorretos, clique em Editar registo.

  6. Na lista Componentes, selecione as caixas de verificação dos tipos de registos que quer recolher e clique em OK. Para mais informações acerca dos tipos de registos disponíveis, consulte o artigo Acerca dos registos do GKE.

  7. Clique em Guardar alterações.

gcloud

  1. Para verificar a configuração de registo, descreva o cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do seu cluster.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

    Se o registo estiver ativado, o resultado é semelhante ao seguinte:

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Se o resultado for NONE, o registo está desativado.

  2. Se os tipos de registos pretendidos estiverem desativados ou incorretos, atualize a configuração de registo:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Substituir LOGGING_TYPE por SYSTEM, WORKLOAD ou ambos. Para recolher registos, a opção SYSTEM tem de estar ativada. Não é possível recolher os registos do WORKLOAD de forma independente. Para mais informações acerca dos tipos de registos disponíveis, consulte Acerca dos registos do GKE.

Valide os âmbitos de acesso do conjunto de nós

Os nós num cluster do GKE usam âmbitos de acesso OAuth para obter autorização para interagir com Google Cloud APIs, incluindo o Cloud Logging.

Sintomas:

Faltam registos nos nós de um conjunto de nós específico.

Causa:

Os nós no conjunto de nós não têm o âmbito de acesso OAuth necessário. Um dos seguintes âmbitos é necessário para que os nós escrevam registos no Cloud Logging:

  • https://www.googleapis.com/auth/logging.write: concede autorização para escrever registos. Este é o âmbito mínimo necessário.
  • https://www.googleapis.com/auth/logging.admin: concede acesso total à API Cloud Logging, que inclui as autorizações de logging.write.
  • https://www.googleapis.com/auth/cloud-platform: concede acesso total a todas as APIs ativadas Google Cloud , o que inclui as autorizações de logging.write.

Resolução:

Para validar as autorizações e conceder as funções necessárias, se estiverem em falta, selecione uma das seguintes opções:

Consola

  1. Valide os âmbitos de acesso do conjunto de nós:

    1. Na Google Cloud consola, aceda à página Clusters do Kubernetes.

      Aceda aos clusters do Kubernetes

    2. Para abrir a página de detalhes do cluster, clique no nome do cluster que quer investigar.

    3. Clique no separador Nós.

    4. Na secção Conjuntos de nós, clique no nome do conjunto de nós que quer investigar.

    5. Navegue para a secção Segurança.

    6. Reveja os âmbitos indicados no campo Âmbitos de acesso. Certifique-se de que, pelo menos, um dos âmbitos necessários está presente:

      • Stackdriver Logging API – Apenas escrita
      • Stackdriver Logging API - Full
      • Cloud Platform – Ativado

      Se os âmbitos necessários estiverem em falta, recrie o conjunto de nós. Não pode alterar os âmbitos de acesso num conjunto de nós existente.

  2. Se necessário, crie um novo node pool com o âmbito necessário:

    1. Navegue novamente para a página de detalhes do cluster que quer modificar.
    2. Clique no separador Nós.
    3. Clique em Criar pool de nós gerido pelo utilizador.
    4. Preencha a secção Detalhes do conjunto de nós.
    5. Na navegação do lado esquerdo, clique em Segurança.
    6. Na secção Âmbitos de acesso, selecione as funções que quer adicionar:
      • Para adicionar âmbitos específicos, selecione Definir acesso para cada API.
      • Para permitir o acesso total, selecione Permitir acesso total a todas as APIs Cloud.
    7. Configure outras secções conforme necessário.
    8. Clique em Criar.

  3. Migre as suas cargas de trabalho para o novo conjunto de nós. Depois de migrar as cargas de trabalho para o novo conjunto de nós, as suas aplicações são executadas em nós que têm os âmbitos necessários para enviar registos para o Cloud Logging.

  4. Elimine o node pool antigo:

    1. Navegue novamente para a página de detalhes do cluster e selecione o separador Nodes.
    2. Na secção Conjuntos de nós, encontre o conjunto de nós antigo.
    3. Junto ao conjunto de nós, clique em Eliminar .
    4. Quando lhe for pedido, confirme a eliminação escrevendo o nome do conjunto de nós e clique em Eliminar.

gcloud

  1. Valide os âmbitos de acesso do conjunto de nós:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do seu cluster.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

    Reveja o resultado de cada conjunto de nós. Certifique-se de que, pelo menos, um dos âmbitos obrigatórios (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform ou https://www.googleapis.com/auth/logging.admin) está listado. Se os âmbitos necessários estiverem em falta, recrie o conjunto de nós. Não pode alterar os âmbitos de acesso num conjunto de nós existente.

  2. Se necessário, crie um novo node pool com o âmbito necessário:

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Substitua o seguinte:

    • NEW_NODE_POOL_NAME: um nome para o novo conjunto de nós.
    • OTHER_SCOPES: uma lista separada por vírgulas de quaisquer outros âmbitos que os seus nós exijam. Se não precisar de outros âmbitos, omita este marcador de posição e a vírgula anterior.

  3. Migre as suas cargas de trabalho para o novo conjunto de nós. Depois de migrar as cargas de trabalho para o novo conjunto de nós, as suas aplicações são executadas em nós que têm os âmbitos necessários para enviar registos para o Cloud Logging.

  4. Elimine o node pool antigo:

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Valide as autorizações da conta de serviço do nó

Os nós usam uma conta de serviço para fazer a autenticação com os Google Cloud serviços, e esta conta precisa de autorizações de IAM específicas para escrever registos.

Sintomas:

  • Faltam registos nos nós.
  • A inspeção dos registos do agente de registo (por exemplo, Fluent Bit) pode mostrar erros relacionados com permissões, como códigos 401 ou 403 ao tentar escrever no Cloud Logging.
  • Pode ver uma Grant Critical Permissions to Node Service Account notificação para o cluster na Google Cloud consola.

Causa:

A conta de serviço usada pelos nós do conjunto de nós não tem as autorizações IAM necessárias para escrever registos no Cloud Logging. Os nós requerem uma conta de serviço com a função logging.logWriter, que inclui a autorização logging.logEntries.create.

Além disso, para as versões 1.33 ou posteriores do GKE, o agente do serviço de nós predefinido do GKE (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) tem de ter, no mínimo, a função de agente do serviço de nós predefinido do Kubernetes (roles/container.defaultNodeServiceAgent). Esta função permite que o GKE faça a gestão dos recursos e das operações dos nós, incluindo os componentes de registo.

Resolução:

Para validar as autorizações e conceder as funções necessárias, se estiverem em falta, faça o seguinte:

  • Valide a autorização da conta de serviço do nó.
  • Verifique se o agente do serviço do GKE tem a função necessária.

Valide a autorização da conta de serviço do nó

A conta de serviço do nó é a conta que o nó usa para autenticar e enviar registos. Para identificar esta conta de serviço e verificar se tem a autorização roles/logging.logWriter necessária, faça o seguinte:

  1. Para identificar a conta de serviço usada pelo conjunto de nós, selecione uma das seguintes opções:

    Consola

    1. Na Google Cloud consola, aceda à página Clusters do Kubernetes.

      Aceda aos clusters do Kubernetes

    2. Na lista de clusters, clique no nome do cluster que quer inspecionar.

    3. Consoante o modo de funcionamento do cluster, faça uma das seguintes ações:

      • Para clusters padrão, faça o seguinte:

        1. Clique no separador Nós.
        2. Na tabela Conjuntos de nós, clique no nome de um conjunto de nós. É apresentada a página de detalhes do conjunto de nós.
        3. Na secção Segurança, encontre o campo Conta de serviço.

      • Para clusters do Autopilot, faça o seguinte:

        1. Aceda ao separador Detalhes.
        2. Na secção Segurança, encontre o campo Conta de serviço.

      Se o valor no campo Conta de serviço for default, os seus nós usam a conta de serviço predefinida do Compute Engine. Se o valor neste campo não for default, os seus nós usam uma conta de serviço personalizada. Para conceder a função necessária a uma conta de serviço personalizada, consulte o artigo Use contas de serviço IAM com o menor número de privilégios.

    gcloud

    Execute o seguinte comando, consoante o tipo de cluster que usa:

    Clusters padrão 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Substitua o seguinte:

    • NODE_POOL_NAME: o nome do conjunto de nós.
    • CLUSTER_NAME: o nome do seu cluster padrão.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

    Se o resultado for default, o conjunto de nós usa a conta de serviço predefinida do Compute Engine. Se o valor não for default, os seus nós usam uma conta de serviço personalizada. Para conceder a função necessária a uma conta de serviço personalizada, consulte o artigo Use contas de serviço IAM com o menor número possível de privilégios.

    Clusters do Autopilot 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do seu cluster do Autopilot.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.
    • PROJECT_ID: o ID do Google Cloud projeto.

    Se o resultado for default, o conjunto de nós usa a conta de serviço predefinida do Compute Engine. Se o valor não for default, os seus nós usam uma conta de serviço personalizada. Para conceder a função necessária a uma conta de serviço personalizada, consulte o artigo Use contas de serviço IAM com o menor número possível de privilégios.

    Para ver scripts mais detalhados para identificar autorizações em falta, consulte o artigo Identifique todas as contas de serviço de nós com autorizações em falta.

  2. O GKE procura automaticamente autorizações em falta e fornece recomendações. Para usar recomendações para verificar autorizações em falta, selecione uma das seguintes opções:

    Consola

    1. Na página Clusters do Kubernetes, localize a coluna Notificações.
    2. Verifique a coluna Notificações para ver a recomendação Conceder autorizações críticas. Esta recomendação significa que a verificação NODE_SA_MISSING_PERMISSIONS falhou.
    3. Se a recomendação estiver presente, clique nela. É aberto um painel de detalhes, que explica as autorizações em falta e indica os passos para corrigir a situação.

    gcloud

    1. Apresente recomendações para autorizações de contas de serviço em falta:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analise o resultado do comando:

      • Se o comando devolver uma lista vazia, significa que o motor de recomendações não encontrou recomendações NODE_SA_MISSING_PERMISSIONS ativas. As contas de serviço verificadas parecem ter as autorizações necessárias.

      • Se o comando devolver um ou mais blocos YAML, significa que o recomendador identificou um problema de autorização. Reveja o resultado para os seguintes campos principais:

        • description: fornece um resumo do problema, como especificar que a conta de serviço do nó não tem a função roles/logging.logWriter ou que o agente do serviço do GKE não tem a função roles/container.defaultNodeServiceAgent.
        • resource: especifica o cluster afetado.
        • content.operations: contém a resolução recomendada. Esta secção fornece o comando gcloud projects add-iam-policy-binding exato necessário para conceder a função específica em falta.

    O motor de recomendações pode demorar até 24 horas a refletir as alterações recentes.

  3. Se quiser validar as autorizações imediatamente, para verificar as autorizações e conceder a função, selecione uma das seguintes opções:

    Consola

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

      Aceda ao IAM

    2. Encontre a conta de serviço usada pelo conjunto de nós.

    3. Na coluna Função, verifique se a conta de serviço tem a função Gravador de registos (roles/logging.logWriter).

    4. Se a autorização estiver em falta, adicione-a:

      1. Clique em Editar principal
      2. Clique em Adicionar outra função.
      3. No campo de pesquisa, introduza Logs Writer.
      4. Selecione a caixa de verificação Logs Writer e clique em Aplicar.
      5. Clique em Guardar.

    gcloud

    1. Verifique as funções atuais da conta de serviço do nó:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Se estiver em falta, conceda a função logging.logWriter:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Valide as autorizações do agente de serviço do GKE

Se os registos continuarem em falta e usar a versão 1.33 ou posterior, verifique se o agente gerido pela Google que o GKE usa para gerir os componentes dos nós tem a autorização necessária:

  1. Para identificar o endereço de email do agente de serviço, obtenha o número do seu projeto:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    Substitua PROJECT_ID pelo ID do seu projeto. Tome nota do resultado.

    O email do agente do serviço GKE é: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Para usar recomendações para verificar autorizações em falta, selecione uma das seguintes opções:

    Consola

    1. Na página Clusters do Kubernetes, encontre a coluna Notificações.
    2. Verifique a coluna da recomendação Conceder autorizações críticas.
    3. Se a recomendação estiver presente, clique nela. É aberto um painel de detalhes, que explica as autorizações em falta e indica os passos para corrigir o problema.

    gcloud

    1. Apresente recomendações para autorizações de contas de serviço em falta:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analise o resultado do comando. Reveja o resultado para ver uma descrição que especifica que o agente do serviço do GKE (gcp-sa-gkenode) não tem a função roles/container.defaultNodeServiceAgent.

  3. Para verificar imediatamente as autorizações e conceder a função, selecione uma das seguintes opções:

    Consola

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

      Aceda ao IAM

    2. No campo Filtro, introduza o endereço de email do agente de serviço do GKE e prima Enter.

    3. Na lista filtrada, verifique se o agente de serviço tem, pelo menos, a função Agente de serviço do nó predefinido do Kubernetes (roles/container.defaultNodeServiceAgent).

    4. Se a função estiver em falta, conceda-a:

      1. Clique em Editar principal junto ao agente de serviço.
      2. Clique em Adicionar funções.
      3. No campo de pesquisa, introduza Kubernetes Default Node Service Agent e selecione a função.
      4. Clique em Guardar.

    gcloud

    1. Verifique se a função roles/container.defaultNodeServiceAgent está associada ao agente do serviço:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      No resultado, procure roles/container.defaultNodeServiceAgent.

    2. Se a função estiver em falta, conceda a função de agente do serviço de nó predefinido do Kubernetes:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Resolva problemas de recursos e desempenho

Se os registos estiverem em falta intermitentemente ou forem ignorados em nós com tráfego elevado, a causa pode não ser uma configuração incorreta, mas sim um problema de desempenho. Use as secções seguintes para investigar se o seu projeto está a exceder as quotas da API ou se o volume de registos elevado está a sobrecarregar os agentes em nós específicos.

Investigue a utilização da quota da Cloud Logging API

Para proteger o serviço, o Cloud Logging aplica uma quota de gravação a todos os projetos, limitando o volume total de registos que o Cloud Logging pode carregar por minuto.

Sintomas:

  • Os registos estão em falta de forma intermitente ou completa.
  • Vê RESOURCE_EXHAUSTED erros relacionados com logging.googleapis.com nos registos do agente de registo ou do nó.

Causa:

O projeto está a exceder a quota de pedidos de gravação da API Cloud Logging. Este problema impede o agente de registo de enviar registos.

Resolução:

Para verificar a utilização da quota e pedir um aumento, faça o seguinte:

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

    Aceder a Quotas

  2. No campo Filtrar, introduza Cloud Logging API e prima Enter.

  3. Na lista filtrada, encontre a quota de bytes de gravação de registos por minuto por região para a região em que o cluster se encontra.

  4. Reveja os valores na coluna Percentagem de utilização atual. Se a utilização estiver no limite ou perto dele, é provável que tenha excedido a quota.

  5. Para pedir um aumento, clique em Editar quota e siga as instruções. Para mais informações, consulte o artigo Veja e faça a gestão das quotas.

Para reduzir a utilização, considere excluir registos ou reduzir a verbosidade dos registos das aplicações. Também pode configurar políticas de alerta para receber uma notificação antes de atingir o limite.

Investigue o débito do nó e a utilização de recursos

O agente de registo do GKE em cada nó tem o seu próprio limite de débito, que pode ser excedido.

Sintomas:

Os registos de nós específicos estão em falta ou atrasados intermitentemente, particularmente durante períodos de elevada atividade do cluster ou utilização intensa de recursos dos nós.

Causa:

O agente de registo do GKE tem um limite de débito predefinido (aproximadamente 100 KBps por nó). Se as aplicações num nó gerarem registos mais rapidamente do que este limite, o agente pode ignorar registos, mesmo que a quota geral da API do projeto não seja excedida. Pode monitorizar o débito do registo de nós através da métrica kubernetes.io/node/logs/input_bytes no Explorador de métricas.

Os registos também podem estar em falta se o nó estiver sob forte pressão da CPU ou da memória, o que deixa recursos insuficientes para o agente processar os registos.

Resolução:

Para reduzir o débito, selecione uma das seguintes opções:

Clusters padrão

Experimente as seguintes soluções:

  • Ativar o registo de débito elevado: esta funcionalidade aumenta a capacidade por nó. Para mais informações, consulte o artigo Ajuste o débito do agente do Cloud Logging.

  • Reduza o volume de registos: analise os padrões de registo de aplicações. Reduza o registo desnecessário ou excessivamente detalhado.

  • Implemente um agente de registo personalizado: pode implementar e gerir o seu próprio Fluent Bit DaemonSet personalizado, mas é responsável pela respetiva configuração e manutenção.

  • Verifique a utilização de recursos dos nós: mesmo que o volume de registos esteja dentro dos limites, certifique-se de que os nós não estão sob forte pressão da CPU ou da memória. Os recursos de nós insuficientes podem dificultar a capacidade do agente de registo de processar e enviar registos. Pode verificar métricas como kubernetes.io/node/cpu/core_usage_time e kubernetes.io/node/memory/used_bytes no explorador de métricas.

Clusters do Autopilot

Experimente as seguintes soluções:

  • Reduza o volume de registos: analise os padrões de registo da sua aplicação. Reduza o registo desnecessário ou excessivamente detalhado. Sempre que possível, certifique-se de que os registos estão estruturados, porque estes tipos de registos podem ajudar no processamento eficiente. Exclua registos não essenciais.

  • Otimize o desempenho das aplicações: uma vez que os recursos dos nós são geridos em clusters do Autopilot, certifique-se de que as suas aplicações não estão a consumir excessivamente a CPU ou a memória, o que pode afetar indiretamente o desempenho dos componentes dos nós, como o agente de registo. Embora não faça a gestão dos nós diretamente, a eficiência da aplicação afeta o estado geral dos nós.

Resolva problemas de filtragem e aplicação

Quando a sua aplicação gera registos com êxito, mas estes continuam a não aparecer no Cloud Logging, o problema é frequentemente causado pela filtragem ou pelo comportamento de registo da aplicação. As secções seguintes exploram problemas como filtros de exclusão de registos, armazenamento em buffer ao nível do contentor, consultas de pesquisa restritivas e aplicações que não escrevem em stdout ou stderr.

Investigue os filtros de exclusão de registos

O Explorador de registos mostra apenas os registos que correspondem a todos os filtros na sua consulta e ao intervalo de tempo selecionado.

Sintomas:

Faltam registos específicos que correspondem a determinados critérios no Cloud Logging, mas estão presentes outros registos das mesmas origens.

Causa:

Os filtros de exclusão de registos são definidos nos destinos do Cloud Logging (frequentemente, o destino _Default). Estas regras ignoram silenciosamente os registos que correspondem a critérios específicos, mesmo que tenham sido enviados com êxito pelo nó.

Resolução:

Para rever e modificar filtros de exclusão, selecione uma das seguintes opções:

Consola

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

    Aceda ao Logs Router

  2. Identifique o filtro problemático:

    1. Para cada destino (exceto o destino _Required, que não pode ter filtros de exclusão), clique em Mais ações e selecione Ver detalhes do destino.
    2. Reveja as consultas na secção Filtros de exclusão. Compare a lógica do filtro com os atributos dos registos em falta (por exemplo, tipo de recurso, etiquetas ou palavras-chave).
    3. Copie a consulta do filtro de exclusão.

    4. Aceda à página Explorador de registos.

      Aceda ao Explorador de registos

    5. Cole a consulta do filtro de exclusão no painel de consultas e clique em Executar consulta.

    6. Reveja os resultados. Os registos apresentados são o que o filtro excluiria. Se os registos em falta aparecerem nestes resultados, é provável que este filtro seja a causa.

  3. Desative ou edite o filtro:

    1. Regresse à página Logs Router.
    2. Clique em Mais ações para o destino com o filtro suspeito e selecione Editar destino.
    3. Localize a secção Escolha os registos a filtrar do sink e encontre o filtro de exclusão.
    4. Pode clicar em Desativar para desativar o filtro ou modificar a respetiva consulta para ser mais específica.
    5. Clique em Atualizar destino. As alterações aplicam-se a novos registos.

gcloud

  1. Apresenta todos os sinks no projeto:

    gcloud logging sinks list --project=PROJECT_ID

  2. Veja os filtros de exclusão de cada destino:

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    Na saída, reveja a secção exclusions. Compare a lógica do filtro com os atributos dos registos em falta (por exemplo, tipo de recurso, etiquetas ou palavras-chave).

  3. Para modificar exclusões, atualize a configuração do destino:

    1. Exporte a configuração do destino para um ficheiro local (por exemplo, sink-config.yaml):

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Abra o ficheiro sink-config.yaml num editor de texto.

    3. Encontre a secção exclusions: e remova ou modifique o filtro problemático.

    4. Atualize o lavatório modificado:

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Para mais informações sobre este comando, consulte a gcloud logging sinks update documentação.

Investigue o armazenamento em buffer e os atrasos dos registos do contentor

As aplicações e os sistemas operativos usam frequentemente o armazenamento em buffer para escrever dados em blocos, em vez de linha a linha, o que pode melhorar o desempenho.

Sintomas:

  • Os registos de contentores específicos aparecem no Cloud Logging apenas depois de o contentor sair ou quando existe um atraso significativo na apresentação dos registos.
  • Por vezes, os registos estão incompletos.

Causa:

Este problema é frequentemente causado pelo armazenamento em buffer de registos. Embora a saída padrão (stdout) seja normalmente armazenada em buffer de linhas quando ligada a um terminal, este comportamento muda quando a saída é encaminhada. Se os registos ou os scripts de arranque de uma aplicação num contentor forem transferidos stdout para outros comandos (por exemplo, my-app | grep ...), a saída pode ficar totalmente em buffer. Como resultado, os registos são retidos até que o buffer esteja cheio ou o canal seja fechado. Este comportamento pode causar atrasos ou perda de dados se o contentor terminar inesperadamente. O armazenamento em buffer interno da aplicação também pode causar atrasos.

Resolução:

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

  • Evite o encaminhamento stdout: se possível, modifique os pontos de entrada do contentor ou os comandos da aplicação para escrever registos diretamente em stdout ou stderr sem encaminhamento através de outros comandos, como grep ou sed, no contentor.
  • Garanta o armazenamento em buffer de linhas:
    • Se o encaminhamento for inevitável, use ferramentas que suportem o armazenamento em buffer de linhas. Por exemplo, use grep --line-buffered.
    • Para aplicações personalizadas, certifique-se de que limpam os registos com frequência, idealmente após cada linha, quando escrevem em stdout. Muitas bibliotecas de registo têm definições para controlar o armazenamento em buffer.

  • Testar o comportamento de colocação em buffer: implemente o seguinte manifesto de pod e observe os efeitos nos registos através do comando kubectl logs -f buffered-pod. Faça experiências comentando e removendo os comentários das diferentes matrizes no manifesto buffered-container:command

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Investigue consultas do Explorador de registos

Se tiver a certeza de que os registos estão a ser recolhidos, mas não os consegue encontrar, o problema pode estar na consulta de pesquisa ou no intervalo de tempo.

Sintomas:

Os registos esperados não aparecem nos resultados da pesquisa, apesar de saber que a aplicação os está a gerar.

Causa:

A sua consulta no Explorador de registos pode ter filtros (por exemplo, em namespaces, etiquetas, tipos de recursos ou texto) que excluem inadvertidamente os registos que procura.

Resolução:

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

    Aceda ao Explorador de registos

  2. Clique em Escolher intervalo de tempo. Mesmo que pense que sabe quando os registos ocorreram, experimente um intervalo significativamente mais amplo para excluir problemas de sincronização.

  3. Simplifique a consulta:

    1. Limpar todos os filtros.

    2. Experimente filtrar apenas pelo seu cluster:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Substitua o seguinte:

      • CLUSTER_NAME: o nome do seu cluster.
      • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.

    3. Clique em Executar consulta.

  4. Se a consulta ampla funcionar, reintroduza os filtros originais um a um:

    • Tipo de recurso: certifique-se de que usa o tipo de recurso correto. Por exemplo, está a filtrar por k8s_container quando devia filtrar por k8s_node?
    • Etiquetas: verifique a ortografia de resource.labels, como namespace_name, container_name ou etiquetas personalizadas.
    • Gravidade: certifique-se de que o nível de gravidade (por exemplo, severity=ERROR) não é demasiado restritivo.
    • Payload de texto: verifique se existem erros ortográficos e strings excessivamente restritivas nos termos de pesquisa. Por exemplo, use : para "contém" em vez de = para uma correspondência exata (jsonPayload.message:"error" em vez de jsonPayload.message="error").

  5. Verifique se os seus filtros têm em conta a sensibilidade a maiúsculas e minúsculas (normalmente, o texto não é sensível a maiúsculas e minúsculas, mas as etiquetas podem ser), certifique-se de que os valores não têm carateres ocultos nem espaços adicionais e verifique se os termos com carateres especiais têm de ser colocados entre aspas.

  6. Reveja a Linha cronológica. As diminuições súbitas quando adiciona um filtro podem ajudar a identificar a parte problemática da consulta.

Para mais sugestões sobre consultas de registo eficazes, consulte o artigo Encontrar entradas de registo rapidamente na documentação do Cloud Logging.

Se ainda não conseguir encontrar os registos depois de refinar a consulta, o problema pode não estar na consulta, mas sim num problema descrito noutras secções deste documento.

Investigue o comportamento de registo específico da aplicação

O agente de registo do GKE apenas recolhe registos escritos nos streams stdout e stderr.

Sintomas:

Não são visíveis registos de um pod ou um contentor específico no Cloud Logging, embora existam outros registos do cluster.

Causa:

A aplicação não está a escrever em stdout nem em stderr. Pode estar configurado incorretamente para escrever registos num ficheiro dentro do contentor, onde o agente de registo não os pode recolher.

A aplicação também pode estar a misturar texto JSON e não JSON na respetiva saída. O analisador do agente de registo espera um formato consistente (JSON ou texto) de um único fluxo. Se uma aplicação configurada para o registo JSON gerar uma linha de texto simples, pode danificar o analisador, o que faz com que os registos sejam ignorados ou carregados incorretamente.

Resolução:

  1. Determine o nome do pod e o espaço de nomes da aplicação cujos registos estão em falta:

    kubectl get pods -n NAMESPACE_NAME

  2. Verifique os registos do contentor:

    • Se o Pod tiver um único contentor, execute o seguinte comando:

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Substitua o seguinte:

      • POD_NAME: o nome do seu Pod.
      • NAMESPACE_NAME: o espaço de nomes do seu Pod.

    • Se o pod tiver vários contentores, especifique o nome do contentor:

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Substitua CONTAINER_NAME pelo nome do contentor no pod.

    • Para seguir os registos em tempo real, execute o seguinte comando:

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Substitua o seguinte:

      • POD_NAME: o nome do seu Pod.
      • CONTAINER_NAME: o nome do contentor no agrupamento.
      • NAMESPACE_NAME: o espaço de nomes do seu Pod.

  3. Analise o resultado:

    • Se o comando kubectl logs não tiver saída ou se a saída do comando não contiver os registos esperados, o problema está na própria aplicação. O comando kubectl logs lê diretamente a partir dos streams stdout e stderr capturados pelo tempo de execução do contentor. Se os registos não estiverem aqui, significa que o agente de registo do GKE não os consegue ver.

      Altere o código ou a configuração da sua aplicação para parar de escrever num ficheiro e, em alternativa, registe todas as mensagens diretamente em stdout (para registos normais) e stderr (para registos de erros).

    • Se vir uma combinação de strings JSON e linhas de texto simples, esta saída indica um problema de formato misto. Configure a sua aplicação para escrever apenas objetos JSON de linha única válidos em stdout e stderr.

    • Se o comando kubectl logs mostrar os registos esperados, o problema está provavelmente mais abaixo na pipeline de registo (por exemplo, agente, autorizações ou serviço Cloud Logging).

Resolva problemas de plataformas e serviços

As secções seguintes ajudam a investigar problemas externos à sua configuração imediata, como políticas de retenção de registos, estado do Cloud Logging ou versões do GKE não suportadas.

Investigue os períodos de retenção de registos

Os registos são armazenados em contentores e cada contentor tem um período de retenção que define durante quanto tempo os respetivos registos são mantidos antes de serem eliminados automaticamente.

Sintomas:

Faltam registos anteriores a uma determinada data.

Causa:

Os registos que está a pesquisar são mais antigos do que o período de retenção do contentor de registos para o qual foram encaminhados.

Resolução:

Para identificar e atualizar o período de retenção, selecione uma das seguintes opções:

Consola

  1. Identifique o contentor para o qual os seus registos do GKE são encaminhados:

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

      Aceda ao Logs Router

    2. Reveja a coluna Destino, que mostra para onde os registos estão a ser encaminhados.

      O destino tem um aspeto semelhante ao seguinte:

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Tenha em atenção o PROJECT_ID, LOCATION e BUCKET_ID.

      Geralmente, os registos são encaminhados para o contentor _Default, mas também podem ser encaminhados para outros contentores se tiver sinks personalizados configurados.

  2. Verifique o período de retenção do contentor de registos:

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

      Aceda ao armazenamento de registos

    2. Encontre os contentores correspondentes a BUCKET_ID, LOCATION e PROJECT_ID no destino do ponto de recolha.

    3. Para cada segmento relevante, veja a coluna Período de retenção.

    4. Se os registos que quer ver forem mais antigos do que o período de retenção, o Cloud Logging eliminou-os. Se precisar de um período de retenção mais longo, faça o seguinte:

      1. Para o contentor cujo período de retenção quer prolongar, clique em Mais ações.
      2. Selecione Editar contentor e atualize o período de retenção. Tenha em atenção as potenciais implicações nos custos.

gcloud

  1. Identifique o contentor para o qual os seus registos do GKE são encaminhados:

    gcloud logging sinks list --project=PROJECT_ID

    Reveja o resultado. O campo destination de cada destino mostra para onde os registos estão a ser encaminhados. O formato de destino de um contentor de registos é:

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Tenha em atenção o PROJECT_ID, LOCATION e BUCKET_ID.

    Os registos são frequentemente encaminhados para o contentor _Default.

  2. Verifique o período de retenção do contentor de registos:

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    Na saída, procure o campo retentionDays. Se os registos de que precisa forem mais antigos do que o valor indicado para retentionDays, o Cloud Logging eliminou-os.

  3. Se precisar de um período de retenção mais longo, atualize-o:

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Substitua o seguinte:

    • BUCKET_ID: o ID do contentor de registos.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o contentor.
    • RETENTION_DAYS: o número de dias para reter registos. Tenha em atenção as potenciais implicações de custos para aumentar o período de retenção.
    • PROJECT_ID: o ID do seu Google Cloud projeto.

Investigue problemas do serviço Cloud Logging e atrasos na carregamento

Por vezes, o próprio pipeline de registo pode ter problemas, quer devido a uma interrupção ao nível do serviço ou a um atraso de carregamento temporário em grande escala.

Sintomas:

  • Perda de registos generalizada ou intermitente em vários projetos ou clusters.
  • Os registos estão significativamente atrasados na apresentação no Explorador de registos.

Causa:

  • Interrupção do serviço Cloud Logging: uma interrupção rara ao nível do serviço pode impedir a ingestão de registos, o que leva a atrasos generalizados ou à perda total de registos.
  • Volume elevado de registos: mesmo sem uma interrupção oficial, um volume elevado de registos do seu projeto ou região pode sobrecarregar temporariamente o serviço de carregamento, o que faz com que os registos demorem a aparecer.

Resolução:

  • Verifique o estado dos Google Cloud serviços visitando o Google Cloud painel de controlo de estado do serviço. Procure incidentes abertos relacionados com o Cloud Logging ou o GKE.

  • Tenha em conta potenciais atrasos na carregamento. Se os registos não estiverem imediatamente visíveis e não existirem incidentes ativos, aguarde algum tempo para a ingestão, especialmente se o volume de registos for elevado. Verifique novamente dentro de alguns minutos.

Investigue a versão do cluster

O GKE lança regularmente novas versões que incluem correções de erros e melhorias de desempenho para componentes, incluindo o agente de registo.

Sintomas:

Os problemas de registo coincidem com as limitações da versão do cluster.

Causa:

O cluster pode estar a executar uma versão mais antiga ou não suportada do GKE que tenha problemas conhecidos do agente de registo ou não tenha determinadas funcionalidades de registo.

Resolução:

Para resolver este problema, faça o seguinte:

  1. Verifique a versão do cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do seu cluster.
    • LOCATION: a região ou a zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) para o cluster.

  2. Para garantir que é uma versão suportada, compare esta versão com o cronograma de lançamentos do GKE.

  3. Se o cluster estiver a usar uma versão não suportada, atualize o cluster.

O que se segue?