Notificações de clusters

Esta página descreve como o Google Kubernetes Engine (GKE) publica as notificações de cluster no Cloud Logging por predefinição e, opcionalmente, no Pub/Sub. Estas notificações contêm informações sobre eventos relevantes para a configuração do cluster, como atualizações disponíveis ou em curso, boletins de segurança e datas de fim do apoio técnico.

Vista geral

Quando ocorrem determinados eventos relevantes para os seus clusters do GKE, como atualizações importantes disponíveis ou boletins de segurança, o GKE envia estas notificações para o Cloud Logging. Para encontrar estes registos no Cloud Logging, consulte o artigo Ver notificações de clusters no Cloud Logging.

O GKE também publica notificações sobre esses eventos como mensagens em tópicos do Pub/Sub que configurar. Pode receber estas notificações numa subscrição do Pub/Sub, integrá-las com serviços de terceiros e filtrá-las pelos tipos de notificações que quer receber. Para mais informações sobre como configurar notificações de clusters com o Pub/Sub, consulte o artigo Receba notificações de clusters através do Pub/Sub.

Vantagens

As notificações de clusters oferecem as seguintes vantagens:

  • Recebe uma notificação quando são emitidos boletins de segurança específicos para os seus clusters, o que lhe fornece informações precisas sobre o risco e o impacto.
  • Recebe uma notificação quando estiver disponível uma nova versão do GKE para o seu cluster, o que lhe permite planear melhor os testes e as qualificações, e ajuda a garantir um processo de atualização simples e previsível. Anteriormente, tinha de consultar as notas de lançamento do GKE ou a API GKE para saber quando era lançada uma nova versão do GKE.
  • Recebe uma notificação quando o GKE ou um utilizador inicia atualizações do cluster e quando a operação de atualização termina, o que lhe dá mais visibilidade das operações em segundo plano do seu cluster.
  • Recebe uma notificação quando o seu cluster está a executar uma versão secundária do GKE que está no fim do suporte técnico ou perto do mesmo.

  • Pode optar por usar o Cloud Logging ou o Pub/Sub:

    • Por predefinição, as notificações de clusters são enviadas para o Cloud Logging. Pode usar todas as capacidades do Cloud Logging, incluindo consultar e ver registos, e configurar políticas de alerta baseadas em registos.
    • O Pub/Sub é altamente extensível, o que lhe dá flexibilidade na forma como processa as notificações recebidas. Por exemplo, pode fazer a integração com o Slack para encaminhar notificações para um canal do Slack ou iniciar funções do Cloud Run para executar processos personalizados. Quando são necessários processos personalizados (por exemplo, orquestrar um fluxo de trabalho de preparação para produção para testar e certificar uma atualização), pode usar a notificação para acionar automaticamente estes fluxos de trabalho.

Tipos de notificações de atualização

O GKE envia os seguintes tipos de notificações de clusters:

Se vir as notificações de clusters no Cloud Logging, pode usar as capacidades do Cloud Logging para filtrar os registos. Se usar o Pub/Sub, pode filtrar as notificações que recebe para que seja notificado apenas de eventos relevantes.

SecurityBulletinEvent

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

UpgradeAvailableEvent

Quando uma nova versão fica disponível num canal de lançamento, o GKE envia uma notificação UpgradeAvailableEvent aos clusters nesse canal de lançamento para informar os clusters de que uma nova versão está agora disponível. Esta notificação fornece um aviso prévio de uma semana para versões de patch e, pelo menos, 2 a 4 semanas para versões secundárias (consoante o canal). Para mais informações, consulte o artigo Que versões estão disponíveis num canal.

Para clusters que não estejam num canal de lançamento, o GKE envia UpgradeAvailableEvent notificações para todas as novas versões para as quais os clusters podem ser atualizados, incluindo patches na versão secundária atual e na versão secundária seguinte.

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

UpgradeEvent

Quando o GKE inicia uma atualização, envia uma notificação UpgradeEvent a indicar que uma atualização foi iniciada. Idealmente, deve usar o tipo de notificação UpgradeAvailableEvent para estar a par da atualização futura, de modo a poder atualizar antecipadamente ou tomar as medidas necessárias para se preparar, como configurar períodos de manutenção.

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

UpgradeInfoEvent

O GKE envia uma notificação para diferentes tipos de eventos, que são descritos nas secções seguintes.UpgradeInfoEvent

Para mais informações sobre a filtragem de um tipo específico de UpgradeInfoEvent, consulte o artigo Filtre as notificações de clusters UpgradeInfoEvent.

A operação de atualização está concluída

Quando o GKE conclui a operação para atualizar automaticamente ou manualmente o plano de controlo ou os nós de um cluster, o GKE envia uma notificação para informar que a operação está concluída. A operação é concluída com um dos seguintes estados:

  • SUCCEEDED: o GKE atualizou com êxito o plano de controlo ou os nós.
  • FAILED: o GKE não conseguiu atualizar o plano de controlo nem os nós.
  • CANCELED: o GKE cancelou a operação de atualização por motivos técnicos ou empresariais, ou cancelou a operação de atualização.

Use a notificação para confirmar o êxito de uma operação de atualização.

Versão secundária no fim do apoio técnico ou perto do fim do apoio técnico

Quando o cluster executa uma versão secundária do GKE que está perto do fim do apoio técnico padrão ou do fim do apoio técnico alargado, ou atingiu qualquer um desses marcos, o GKE envia notificações de que tem de atualizar o plano de controlo ou os nós do cluster para a próxima versão secundária suportada. A execução de uma versão secundária suportada garante que continua a receber patches de segurança, correções de erros e apoio técnico. O GKE envia uma notificação 30 dias antes do fim do apoio técnico e uma notificação no fim do apoio técnico, se o cluster continuar a executar a versão secundária.

O GKE envia notificações ao nível do cluster, embora vários componentes do seu cluster possam ser afetados e o cluster possa executar diferentes versões secundárias em simultâneo. Se a versão secundária estiver a atingir o fim do apoio técnico padrão e precisar de tempo para se preparar para uma atualização para uma versão suportada, pode mudar para o canal de lançamento alargado para receber apoio técnico a longo prazo. Caso contrário, o GKE agenda atualizações automáticas no final do apoio técnico. Estas notificações ajudam a garantir que está preparado para a aplicação destas políticas de fim de apoio técnico.

Uma notificação inclui os seguintes detalhes:

  • O cluster afetado.
  • A versão atual que atingiu ou está perto de atingir o fim do suporte.
  • A data de fim do apoio técnico.

Para mais detalhes sobre a linha cronológica do apoio técnico para versões secundárias do GKE, consulte o ciclo de vida das versões secundárias do GKE.

As novas versões de patches mudam para um novo marco do SO otimizado para contentores durante o apoio técnico alargado

Quando o cluster está inscrito no canal alargado durante o período de apoio técnico alargado e a etapa importante do SO otimizado para contentores usada pela versão secundária do GKE atinge o fim do apoio técnico antes da versão secundária, o GKE envia uma notificação do cluster. O GKE envia esta notificação quando a primeira versão de patch a usar o novo marco fica disponível no canal Extended.

Esta notificação inclui os seguintes detalhes:

  • O cluster afetado.
  • A versão do patch que usa o novo marco.
  • As conquistas existentes e novas.
  • Como o GKE pausa as atualizações automáticas de patches para os nós.

A versão de patch que usa o novo marco torna-se, eventualmente, o destino de atualização automática do patch para o cluster, e as atualizações automáticas de nós são pausadas. Os administradores do cluster têm de decidir qual dos seguintes passos seguintes dar:

  • Atualize manualmente os nós do cluster para a versão de patch seguinte, que usa a próxima etapa do SO otimizado para contentores.
  • Atualize manualmente o cluster para a versão secundária seguinte.
  • Renuncie às atualizações de patches até o GKE atualizar o cluster para a versão secundária seguinte no final do apoio técnico alargado.

Para saber mais, consulte o artigo A etapa do SO otimizado para contentores atinge o fim da compatibilidade antes do fim da compatibilidade alargada da versão secundária.

Ver notificações de clusters nos Registos na nuvem

Para ver os registos dos clusters do GKE, consulte o artigo Aceder aos seus registos.

Para desativar o armazenamento destes registos, pode configurar um filtro de exclusão.

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

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

Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

Veja os registos com o seguinte filtro para ver um tipo de notificação de cluster específico, como UpgradeEvent:

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

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

Filtre notificações de clusters UpgradeInfoEvent

Veja os registos com o seguinte filtro para ver um UpgradeInfoEvent específico, como a notificação de conclusão de uma operação de atualização:

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

Substitua EVENT_TYPE por uma das seguintes opções:

Filtrar notificações para o Pub/Sub

Pode filtrar as notificações de clusters para garantir que recebe apenas as notificações que quer no Pub/Sub. Pode aplicar a filtragem para notificações no Pub/Sub de uma das seguintes formas:

Para ver e filtrar notificações nos Registos na nuvem, consulte o artigo Ver notificações de clusters nos Registos na nuvem.

Filtrar notificações para o Pub/Sub no GKE

Pode configurar a filtragem para o Pub/Sub para um ou mais tipos de notificações disponíveis quando ativa as notificações de clusters especificando valores para filter na flag --notification-config. filter recebe uma lista delimitada por barras ( | ) dos tipos de notificações que quer receber.

Por exemplo, especificar filter="UpgradeEvent|SecurityBulletinEvent" indica ao GKE que só deve enviar notificações para os tipos de notificações UpgradeEvent e SecurityBulletinEvent.

Filtrar notificações através de filter tem vantagens como as seguintes:

  • Mais fácil de usar, porque filtra pelo tipo de notificação sem usar uma sintaxe específica.
  • As notificações que filtra nunca são enviadas para o Pub/Sub, pelo que não lhe são cobradas taxas por mensagens não entregues.
  • Pode editar a configuração do filtro em qualquer altura.

Para ver instruções sobre como filtrar notificações no GKE, consulte o artigo Receba notificações de clusters através do Pub/Sub.

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

Filtrar notificações no Pub/Sub

O Pub/Sub suporta a filtragem de mensagens na sua subscrição através de uma sintaxe de filtragem. Quando usa este método, o GKE envia todos os tipos de notificações para o seu tópico do Pub/Sub. O Pub/Sub filtra as mensagens com base na configuração da sua subscrição e envia as mensagens que quer receber.

Por exemplo, pode filtrar as notificações UpgradeEvent e UpgradeAvailableEvent usando a seguinte sintaxe na sua subscrição:

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

Continua a pagar as mensagens não entregues filtradas pela sua subscrição. Também não pode modificar os filtros depois de configurar a subscrição. No entanto, a sintaxe de filtragem é mais extensível do que a filtragem no GKE.

Para saber como filtrar a sua subscrição do Pub/Sub, consulte o artigo Filtrar mensagens.

Consumir mensagens do Pub/Sub

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

Para as 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 de notificação, o ID do projeto, o nome do cluster e a localização do cluster. O campo attributes.payload é uma string analisável por JSON que contém informações de notificação específicas, como os detalhes de um boletim de segurança.

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

Atributo Descrição Exemplo
project_id O número do projeto proprietário do cluster. 123456789
cluster_location A localização 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 analisável em JSON que contém informações específicas da 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 envia sempre tipos de notificações beta. No entanto, pode analisar o conteúdo útil para apresentar o tipo de notificação do GA correspondente, se estiver disponível.

Exemplos de mensagens de notificação de clusters

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 seguintes mostram exemplos das informações que pode receber para cada tipo de notificação:

SecurityBulletinEvent

O resultado é semelhante ao seguinte para uma mensagem de 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://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2021-001"
      }

UpgradeAvailableEvent

A saída é semelhante à seguinte 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 de 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"}

UpgradeInfoEvent

A saída é semelhante à seguinte para uma mensagem de quando uma operação de atualização é concluída, como neste exemplo para uma atualização do conjunto de nós:UpgradeInfoEvent

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"}

Este resultado é diferente do que acontece quando as mensagens se destinam a uma versão secundária no final ou perto do final do apoio técnico, ou quando as novas versões de patches mudam para um novo marco do SO otimizado para contentores durante o apoio técnico alargado.

O que se segue?