Notificações de cluster

Neste documento, descrevemos como o Google Kubernetes Engine (GKE) publica notificações de cluster no Cloud Logging por padrão (e, opcionalmente, no Pub/Sub) quando eventos específicos ocorrem nos clusters do GKE. Essas notificações têm informações sobre eventos relevantes para a configuração do cluster, como upgrades programados, disponíveis ou em andamento, boletins de segurança e datas de fim do suporte. Para encontrar esses registros no Cloud Logging, consulte Como ver notificações de cluster no Cloud Logging.

O GKE também publica notificações sobre esses eventos como mensagens nos tópicos do Pub/Sub que você configura. Você pode receber essas notificações em uma assinatura do Pub/Sub, integrar a serviços de terceiros e filtrar os tipos de notificação que você quer receber. Para mais informações sobre como configurar notificações de cluster com o Pub/Sub, consulte Receber notificações de cluster pelo Pub/Sub.

Além das notificações de cluster, o GKE também fornece notificações para sequenciamento de lançamento com estágios personalizados exclusivamente para o Cloud Logging.

Vantagens

As notificações de cluster oferecem os seguintes benefícios:

  • Você recebe notificações quando os boletins de segurança específicos dos clusters são emitidos, o que fornece informações precisas de risco e impacto.
  • Você recebe uma notificação quando há uma nova versão do GKE disponível para seu cluster, o que permite planejar melhor os testes e as qualificações e ajuda a garantir um processo de upgrade tranquilo e previsível. Antes, era preciso verificar as notas da versão do GKE ou a API GKE para descobrir quando uma nova versão do GKE foi lançada.
  • Você recebe uma notificação quando o GKE ou um usuário inicia upgrades de cluster e quando a operação de upgrade termina, fornecendo mais visibilidade às operações em segundo plano do cluster.
  • Você recebe uma notificação quando o cluster está executando uma versão secundária do GKE que está no fim do suporte ou perto dele.

  • Você pode escolher se quer usar o Cloud Logging ou o Pub/Sub:

    • As notificações de cluster são enviadas ao Cloud Logging por padrão. Você pode usar todos os recursos do Cloud Logging, incluindo consultar e visualizar registros e configurar políticas de alerta com base em registros.
    • O Pub/Sub é altamente extensível, o que oferece flexibilidade para a forma como você processa as notificações recebidas. Por exemplo, é possível fazer a integração com o Slack para encaminhar as notificações a um canal do Slack, ou iniciar as funções do Cloud Run para executar processos personalizados. Quando processos personalizados forem necessários (por exemplo, orquestrar um fluxo de trabalho de preparo para produção e teste e certificar um upgrade), use a notificação para acionar esses fluxos de trabalho automaticamente.

As notificações de sequenciamento de lançamento informam sobre o seguinte:

  • A progressão de um lançamento em uma sequência de lançamento com etapas personalizadas. As notificações mantêm você informado sobre o status de um lançamento para que seja possível monitorar o desempenho dos clusters e das cargas de trabalho e tomar medidas, se necessário.
  • Se uma sequência de lançamento com estágios personalizados estiver mal configurada, ou seja, você precisa corrigir.

Tipos de notificação de upgrade

O GKE envia os seguintes tipos de notificação de cluster:

Se você visualizar as notificações do cluster no Cloud Logging, poderá usar os recursos do Cloud Logging para filtrar os registros. Se você usa o Pub/Sub, é possível filtrar as notificações recebidas para receber alertas apenas de eventos relevantes.

O GKE envia os seguintes tipos de notificação de sequência de lançamento para sequenciamento de lançamento com estágios personalizados:

SecurityBulletinEvent

Quando o GKE emite um boletim de segurança correlacionado diretamente à configuração ou versão do cluster, o GKE envia uma notificação SecurityBulletinEvent fornecendo informações sobre a vulnerabilidade, impacto e, se aplicável, as ações que você pode realizar.

UpgradeAvailableEvent

Quando uma nova versão é disponibilizada em um canal de lançamento, o GKE envia uma notificação UpgradeAvailableEvent aos clusters nesse canal de lançamento para informar aos clusters que uma nova versão já está disponível. Esta notificação fornece uma semana de aviso com antecedência para versões de patch e pelo menos duas a quatro semanas para versões secundárias (dependendo do canal). Para mais informações, consulte Quais versões estão disponíveis em um canal.

Para clusters que não estão em um canal de lançamento, o GKE envia notificações UpgradeAvailableEvent para todas as novas versões que os clusters possam fazer upgrade para, incluindo patches na versão secundária atual e na próxima versão secundária.

Se você usar os pools de nós do Windows Server, as informações da versão do Windows serão enviadas como parte da notificação UpgradeAvailableEvent.

UpgradeEvent

Quando um upgrade é iniciado por você ou pelo GKE, o GKE envia uma notificação UpgradeEvent informando que um upgrade já foi iniciado. O ideal é usar o tipo de notificação UpgradeAvailableEvent para acompanhar o futuro upgrade e fazer upgrade com antecedência ou tomar as medidas necessárias para se preparar, como a configuração de janelas de manutenção.

A notificação UpgradeEvent é enviada no início da operação de upgrade. O ID da operação é transmitido na mensagem.

Para upgrades secundários do plano de controle em duas etapas com segurança de reversão, o GKE envia essa notificação quando o upgrade binário e o upgrade da versão emulada são iniciados. Para mais informações sobre os detalhes principais fornecidos pelo GKE, consulte O que está incluído na notificação para upgrades em duas etapas.

UpgradeInfoEvent

O GKE envia uma notificação de UpgradeInfoEvent para diferentes tipos de eventos, que são descritos nas próximas seções.

Para mais informações sobre como filtrar um tipo específico de UpgradeInfoEvent, consulte Filtrar notificações de cluster do UpgradeInfoEvent.

Upgrades de cluster programados

Quando o GKE programa um upgrade de cluster, ele envia uma notificação entre 72 e 96 horas antes. Para mais informações sobre como ativar upgrades programados de cluster, consulte Receber notificações sobre upgrades programados de cluster.

A operação de upgrade foi concluída

Quando o GKE conclui a operação para fazer upgrade automático ou manual do plano de controle ou dos nós de um cluster, ele envia uma notificação para informar que a operação foi concluída. A operação é concluída com um dos seguintes estados:

  • SUCCEEDED: o GKE fez upgrade do plano de controle ou dos nós.
  • FAILED: o GKE não conseguiu fazer upgrade do plano de controle ou dos nós.
  • CANCELED: o GKE cancelou a operação de upgrade por motivos técnicos ou comerciais, ou você cancelou a operação de upgrade.

Use a notificação para confirmar o sucesso de uma operação de upgrade.

O que está incluído na notificação de upgrades em duas etapas

Para upgrades secundários do plano de controle em duas etapas com segurança de reversão, o GKE envia essa notificação uma vez após a conclusão do upgrade binário, que é quando o tempo de imersão começa, e novamente após a conclusão do upgrade da versão emulada. Essas notificações incluem informações como as seguintes, quando aplicável, com base no status do upgrade em duas etapas:

  • A versão inicial
  • A versão de destino
  • A versão emulada inicial
  • A versão emulada de destino

Versão secundária no fim do suporte ou perto dele

Quando o cluster executa uma versão secundária do GKE que está perto do fim do suporte padrão ou fim do suporte estendido ou atingiu qualquer um desses marcos, o GKE envia notificações informando que você precisa fazer upgrade do plano de controle ou dos nós do cluster para a próxima versão secundária compatível. A execução de uma versão secundária compatível garante que você continue recebendo patches de segurança, correções de bugs e suporte. O GKE envia uma notificação 30 dias antes do fim do suporte e outra no fim do suporte, se o cluster ainda executar a versão secundária.

O GKE envia notificações no nível do cluster, embora vários componentes do cluster possam ser afetados, e o cluster possa executar diferentes versões secundárias ao mesmo tempo. Se a versão secundária estiver chegando ao fim do suporte padrão e você precisar de tempo para se preparar para um upgrade para uma versão com suporte, mude para o canal de lançamento estendido para receber suporte de longo prazo. Caso contrário, o GKE vai programar upgrades automáticos no fim do suporte. Essas notificações ajudam a garantir que você esteja preparado para a aplicação dessas políticas de fim de suporte.

Uma notificação inclui os seguintes detalhes:

  • O cluster afetado.
  • A versão atual que está no fim do suporte ou perto dele.
  • A data de término do suporte.

Para mais detalhes sobre o cronograma de suporte para versões secundárias do GKE, consulte o ciclo de vida da versão secundária do GKE.

Novas versões de patch mudam para um novo marco do Container-Optimized OS durante o suporte estendido

Quando o cluster está inscrito no canal estendido durante o período de suporte estendido e o marco do Container-Optimized OS usado pela versão secundária do GKE chega ao fim do suporte antes da versão secundária, o GKE envia uma notificação de cluster. O GKE envia essa notificação quando a primeira versão de patch que usa o novo marco fica disponível no canal estendido.

Essa notificação inclui os seguintes detalhes:

  • O cluster afetado.
  • A versão do patch que usa o novo marco.
  • Os marcos atuais e novos.
  • Como o GKE pausa os upgrades automáticos de patch para os nós.

A versão do patch que usa o novo marco acaba se tornando o destino de upgrade automático de patch para o cluster, e os upgrades automáticos de nós são pausados. Os administradores de cluster precisam decidir qual das seguintes etapas seguir:

  • Faça upgrade manual dos nós do cluster para a próxima versão de patch que usa o próximo marco do Container-Optimized OS.
  • Faça upgrade manual do cluster para a próxima versão secundária.
  • Abra mão dos upgrades de patch até que o GKE faça upgrade do cluster para a próxima versão secundária no fim do suporte estendido.

Para saber mais, consulte O marco do Container-Optimized OS chega ao fim do suporte antes do fim do suporte estendido da versão secundária.

Eventos de interrupção durante um upgrade do pool de nós

Quando um pool de nós passa por determinados tipos de eventos disruptivos durante um upgrade, o GKE envia uma notificação para informar sobre o evento.

O GKE envia uma notificação de cluster para os seguintes tipos de eventos de interrupção:

A notificação inclui os seguintes detalhes:

  • O nó afetado por esse evento de interrupção.
  • Os pods afetados por esse evento de interrupção.
  • A operação que acionou a drenagem do nó.
  • O tempo limite do PDB antes da exclusão forçada dos pods.

RolloutEvent

O GKE envia notificações quando os seguintes eventos ocorrem para o lançamento de uma versão do GKE em uma sequência de lançamento com estágios personalizados:

  • ROLLOUT_CREATED: um novo lançamento foi criado.
  • ROLLOUT_STAGE_TRANSITION: um estágio no lançamento passou para um novo estado.
  • ROLLOUT_BLOCKED: o lançamento está bloqueado porque um plano de controle ou pool de nós não está qualificado para upgrade.
  • ROLLOUT_AUTO_PAUSED: o lançamento foi pausado automaticamente pelo GKE.
  • ROLLOUT_AUTO_RESUMED: o lançamento foi retomado automaticamente depois de ser pausado.
  • ROLLOUT_CANCELLATION_WARNING: o lançamento foi pausado por muito tempo e será cancelado automaticamente em sete dias se não for retomado.
  • ROLLOUT_AUTO_CANCELLED: o lançamento foi cancelado automaticamente pelo GKE.
  • ROLLOUT_COMPLETED: o lançamento foi concluído.

RolloutSequenceEvent

O GKE envia notificações nas seguintes situações para uma sequência de lançamento com etapas personalizadas:

  • SEQUENCE_MISCONFIGURED: a sequência de lançamento está configurada incorretamente, o que significa que o GKE não pode realizar upgrades na sequência com a configuração atual.
  • SEQUENCE_DEACTIVATION_WARNING: um aviso de que o GKE vai desativar a sequência de lançamento se a configuração incorreta não for corrigida.

Como visualizar notificações de cluster no Cloud Logging

As instruções a seguir funcionam para notificações de cluster e de sequenciamento de lançamento.

Para ver os registros de clusters do GKE, consulte Como acessar seus registros.

Para desativar o armazenamento desses registros, configure um filtro de exclusão.

Veja os registros no Cloud Logging com o seguinte filtro para conferir todos os tipos de notificações de cluster:

logName=projects/PROJECT_ID/logs/container.googleapis.com%2Fnotifications

Substitua PROJECT_ID pelo ID do projeto Google Cloud .

Para ver um tipo específico de notificação de cluster, como UpgradeEvent, use o seguinte filtro:

jsonPayload.@type=type.googleapis.com/google.container.v1beta1.NOTIFICATION_TYPE

Substitua NOTIFICATION_TYPE pelo tipo de notificação do cluster para os registros que você quer ver.

Filtrar notificações de cluster do UpgradeInfoEvent

Confira os registros com o filtro a seguir para ver um UpgradeInfoEvent específico, como a notificação de conclusão de uma operação de upgrade:

jsonPayload.@type=type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent
jsonPayload.eventType=EVENT_TYPE

Substitua EVENT_TYPE por um dos seguintes:

Como filtrar notificações para o Pub/Sub

É possível filtrar as notificações de cluster para garantir que você receba apenas as notificações que quiser no Pub/Sub. É possível aplicar a filtragem de notificações ao Pub/Sub de uma das seguintes maneiras:

Para ver e filtrar notificações no Cloud Logging, consulte Visualizar notificações de cluster no Cloud Logging.

Como filtrar notificações para o Pub/Sub no GKE

É possível configurar a filtragem para o Pub/Sub para um ou mais tipos de notificação disponíveis ao ativar as notificações de cluster especificando valores para filter na sinalização --notification-config. filter usa uma lista delimitada por barra vertical ( | ) dos tipos de notificação que você quer receber.

Por exemplo, especificar filter="UpgradeEvent|SecurityBulletinEvent" instrui o GKE a enviar notificações somente para os tipos de notificação UpgradeEvent e SecurityBulletinEvent.

A filtragem de notificações usando filter tem os seguintes benefícios:

  • Mais fácil de usar, porque você filtra o tipo de notificação sem usar uma sintaxe específica.
  • As notificações filtradas não são enviadas ao Pub/Sub. Portanto, você não é cobrado por mensagens não entregues.
  • Você pode editar a configuração do filtro a qualquer momento.

Para instruções sobre como filtrar notificações no GKE, consulte Receber notificações de cluster pelo Pub/Sub.

A filtragem de notificações no GKE não afeta os registros que aparecem no Cloud Logging.

Como filtrar notificações no Pub/Sub

O Pub/Sub é compatível com a filtragem de mensagens na sua assinatura usando uma sintaxe de filtragem. Quando você usa esse método, o GKE entrega todos os tipos de notificação ao tópico do Pub/Sub. O Pub/Sub filtra mensagens com base na configuração de assinatura e entrega as mensagens que você quer receber.

Por exemplo, é possível filtrar por notificações UpgradeEvent e UpgradeAvailableEvent usando a seguinte sintaxe na sua assinatura:

attributes.type_url = "type.googleapis.com/google.container.v1beta1.UpgradeEvent" OR "type.googleapis.com/google.container.v1beta1.UpgradeAvailableEvent"

Você ainda será cobrado pelas mensagens não entregues filtradas pela sua assinatura. Também não é possível modificar os filtros depois de configurar a assinatura. No entanto, a sintaxe de filtragem é mais extensível do que a filtragem no GKE.

Para saber mais sobre como filtrar sua assinatura do Pub/Sub, consulte Como filtrar mensagens.

Alertas sobre notificações de cluster no Cloud Logging

É possível configurar alertas baseados em registros para receber notificações quando ocorrerem eventos específicos do cluster. A seção a seguir mostra um exemplo básico de como configurar um alerta com base em registros, mas você pode encontrar outros exemplos no repositório de amostras do painel de monitoramento.

criar um alerta baseado em registros;

Para criar um alerta para um tipo específico de notificação, siga estas etapas. As etapas a seguir usam UpgradeEvent como exemplo.

  1. No console do Google Cloud , acesse a Análise de registros.

  2. No campo Consulta, insira a consulta a seguir para filtrar o tipo do aviso escolhido:

    resource.type="RESOURCE_TYPE"
log_id("container.googleapis.com/notifications")
jsonPayload.@type="type.googleapis.com/google.container.v1beta1.NOTIFICATION_TYPE"

    Substitua:

    • RESOURCE_TYPE: o tipo de recurso que você quer filtrar, por exemplo, gke_cluster OU gke_nodepool ou uma combinação.
    • NOTIFICATION_TYPE: o tipo de notificação do cluster que você quer alertar, como UpgradeEvent.

    Alguns tipos de notificação exigem filtragem adicional. Por exemplo, se você quiser filtrar por um tipo específico de UpgradeInfoEvent, adicione o filtro jsonPayload.eventType à consulta. A consulta de exemplo a seguir filtra UpgradeInfoEvent quando o tipo de evento é UPGRADE_LIFECYCLE:

    resource.type="RESOURCE_TYPE"
log_id("container.googleapis.com/notifications")
jsonPayload.@type="type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent"
jsonPayload.eventType="UPGRADE_LIFECYCLE"

    Para mais informações sobre como filtrar UpgradeInfoEvent, consulte Filtrar notificações de cluster do UpgradeInfoEvent.

  3. No menu Ações, clique em Criar alerta de registro.

  4. Na página Detalhes do alerta, dê um nome à política de alertas e clique em Próxima.

    Na seção Definir entradas de registro para receber alertas, sua consulta é pré-preenchida.

  5. Na seção Extrair rótulos de registros, clique em Adicionar um rótulo. Extrair rótulos de registro ajuda a tornar as notificações mais informativas. Por exemplo, para um UpgradeEvent, é possível incluir as versões atual e de destino de um upgrade adicionando os seguintes rótulos:

    • CurrentVersion: jsonPayload.currentVersion
    • TargetVersion: jsonPayload.targetVersion

  6. Clique em Próxima.

  7. Configure a frequência de notificação e a duração do fechamento automático e clique em Próxima.

  8. Na seção Quem precisa ser notificado?, selecione os canais de notificação em que você quer receber os alertas e clique em Salvar.

Depois de configurar o alerta, as notificações de um UpgradeEvent incluem os rótulos CurrentVersion e TargetVersion, fornecendo um contexto valioso diretamente na notificação.

Como consumir mensagens do Pub/Sub

As mensagens do Pub/Sub contêm dois campos: data (string) e attributes (mapa de string a string).

Para notificações do GKE, o campo data contém informações legíveis por humanos. O campo attributes tem informações genéricas de notificação, como o tipo e o ID do projeto, o nome e o local do cluster. O campo attributes.payload é uma string JSON analisável que contém informações de notificação específicas, como os detalhes de um boletim de segurança.

As notificações sempre contêm os seguintes atributos:

Atributo Descrição Exemplo
project_id O número do projeto que é o proprietário do cluster. 123456789
cluster_location O local do cluster. us-central1-c
cluster_name O nome do cluster. example-cluster
type_url O tipo de notificação. type.googleapis.com/google.container.v1beta1.UpgradeEvent
payload Uma string JSON analisável com informações específicas de notificação. 
{ "resourceType":"MASTER",
  "operation":"operation-1595889094437-87b7254a",
  "operationStartTime":"2020-07-27T22:31:34.437652293Z",
  "currentVersion":"1.15.12-gke.2",
  "targetVersion":"1.15.12-gke.9"}

O GKE sempre enviará tipos de notificação beta. No entanto, é possível analisar o payload para exibir o tipo de notificação do GA correspondente, se ele estiver disponível.

Exemplos de mensagens de notificação de cluster

Além do texto no campo data, cada mensagem que o GKE envia para o Cloud Logging ou o Pub/Sub tem valores específicos nos campos attributes.type_url e attributes.payload. As tabelas a seguir mostram exemplos das informações que você pode receber para cada tipo de notificação:

SecurityBulletinEvent

A saída é semelhante à seguinte para uma mensagem SecurityBulletinEvent:

Atributos
type_url type.googleapis.com/google.container.v1beta1.SecurityBulletinEvent
payload 
{    "resourceTypeAffected":"RESOURCE_TYPE_CONTROLPLANE",
         "bulletinId":"GCP-2021-001",
         "cveIds":[
            "CVE-2021-3156"
         ],
         "severity":"Medium",
         "briefDescription":"A vulnerability was recently discovered in the Linux utility sudo, described in CVE-2021-3156, that may allow an attacker with unprivileged local shell access on a system with sudo installed to escalate their privileges to root on the system.",
         "affectedSupportedMinors":["1.18", "1.19"],
         "patchedVersions":["1.18.9-gke.1900", "1.19.9-gke.1900"],
         "suggestedUpgradeTarget":"1.19.9-gke.1900",
         "bulletinUri":"https://docs.cloud.google.com/kubernetes-engine/security-bulletins#gcp-2021-001"
      }

UpgradeAvailableEvent

A saída será semelhante a esta para uma mensagem de UpgradeAvailableEvent:

Atributos
type_url type.googleapis.com/google.container.v1beta1.UpgradeAvailableEvent
payload 
{ "version":"1.17.15-gke.800",
  "resourceType":"MASTER",
  "releaseChannel":{"channel":"RAPID"},
  "windowsVersions": [
    {
      "imageType": "WINDOWS_SAC",
      "osVersion": "10.0.18363.1198",
      "supportEndDate": {
        "day": 10,
        "month": 5,
        "year": 2022
      }
    },
    {
      "imageType": "WINDOWS_LTSC",
      "osVersion": "10.0.17763.1577",
      "supportEndDate": {
        "day": 9,
        "month": 1,
        "year": 2024
      }
    }
  ]
}

UpgradeEvent

A saída é semelhante à seguinte para uma mensagem UpgradeEvent:

Atributos
type_url type.googleapis.com/google.container.v1beta1.UpgradeEvent
payload 
{ "resourceType":"MASTER",
  "operation":"operation-1595889094437-87b7254a",
  "operationStartTime":"2020-07-27T22:31:34.437652293Z",
  "currentVersion":"1.15.12-gke.2",
  "targetVersion":"1.15.12-gke.9"}

Essa saída representa uma notificação para um upgrade do plano de controle em uma etapa. Os upgrades em duas etapas incluem informações diferentes na notificação. Para mais informações sobre os diferentes tipos de upgrade do plano de controle, consulte Como fazer upgrade do plano de controle do cluster.

UpgradeInfoEvent

A saída é semelhante à seguinte para uma mensagem UpgradeInfoEvent quando uma operação de upgrade é concluída, como este exemplo de upgrade de pool de nós:

Atributos
type_url type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent
payload 
{ "currentVersion":"1.31.1-gke.1846000",
  "endTime":"2024-11-06T17:12:54.111640650Z",
  "operation":"operation-1730912205658-de2f88a8-6290-4718-b2c1-fb19611060b8",
  "resource":"projects/PROJECT_ID/locations/CLUSTER_LOCATION/clusters/CLUSTER_NAME/nodePools/NODE_POOL_NAME",
  "resourceType":"NODE_POOL"
  "startTime":"2024-11-06T16:56:45.658321844Z",
  "state":"SUCCEEDED",
  "targetVersion":"1.31.1-gke.2105000"}

Essa saída é diferente das notificações de upgrades do plano de controle, quando as mensagens são para uma versão secundária no final ou perto do final do suporte, quando novas versões de patch mudam para um novo marco do Container-Optimized OS durante o suporte estendido ou para eventos disruptivos durante um upgrade do pool de nós.

Notificação de upgrade programado do cluster

Quando um upgrade de cluster é programado e as notificações de upgrade programado estão ativadas, o GKE envia uma mensagem de saída UpgradeInfoEvent semelhante à seguinte para um upgrade programado do plano de controle:

Atributos
type_url type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent
payload 
{
  "insertId": "[...]",
  "jsonPayload": {
    "description": "Your cluster control plane will be upgraded to 1.32.9-gke.1239000 after 2025-12-13 12:46 UTC",
    "startTime": "2025-12-13T12:46:37.380970854Z",
    "targetVersion": "1.32.9-gke.1239000",
    "@type": "type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent",
    "currentVersion": "1.31.14-gke.1081000",
    "eventType": "UPGRADE_LIFECYCLE",
    "state": "SCHEDULED",
    "resourceType": "MASTER"
  },
  "resource": {
    "type": "gke_cluster",
    "labels": {
      "cluster_name": "CLUSTER_NAME",
      "location": "LOCATION",
      "project_id": "PROJECT_ID"
    }
  },
  "timestamp": "2025-12-10T12:46:37.989407414Z",
  "severity": "NOTICE",
  "logName": "projects/PROJECT_ID/logs/container.googleapis.com%2Fnotifications",
  "receiveTimestamp": "2025-12-10T12:46:38.007312354Z"
}

O GKE envia uma mensagem de saída semelhante à seguinte para upgrades programados de nós:

Atributos
type_url type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent
payload 
{
  "insertId": "[...]",
  "jsonPayload": {
    "description": "Your cluster node pools will be upgraded to 1.32.9-gke.1239000 (or latest target patch) after 2025-12-13 12:46 UTC: NODE_POOL_1, NODE_POOL_2, [...] and 23 more.",
    "startTime": "2025-12-13T12:46:37.380970854Z",
    "targetVersion": "1.32.9-gke.1239000",
    "@type": "type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent",
    "currentVersion": "1.31.14-gke.1081000",
    "eventType": "UPGRADE_LIFECYCLE",
    "state": "SCHEDULED",
    "resource": "projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/nodePools/NODE_POOL_1",
    "resourceType": "NODE_POOL"
  },
  "resource": {
    "type": "gke_nodepool",
    "labels": {
      "cluster_name": "CLUSTER_NAME",
      "location": "LOCATION",
      "nodepool_name": "NODE_POOL_NAME",
      "project_id": "PROJECT_ID"
    }
  },
  "timestamp": "2025-12-10T12:46:37.989407414Z",
  "severity": "NOTICE",
  "logName": "projects/PROJECT_ID/logs/container.googleapis.com%2Fnotifications",
  "receiveTimestamp": "2025-12-10T12:46:38.007312354Z"
}

Para upgrades de nós programados, que são agrupados por destino de upgrade automático, o GKE lista em ordem alfabética até 10 pools de nós, fornecendo informações detalhadas apenas para o primeiro pool de nós. Se mais de 10 pools de nós forem programados, o GKE vai mostrar uma contagem dos pools restantes não listados (como 33 upgrades no total neste exemplo).

A seguir