Nesta página, descrevemos como o Google Kubernetes Engine (GKE) publica notificações de cluster no Cloud Logging por padrão e, opcionalmente, no Pub/Sub. Essas notificações têm informações sobre eventos relevantes para a configuração do cluster, como upgrades disponíveis ou em andamento, boletins de segurança e datas de fim do suporte.
Visão geral
Quando ocorrem determinados eventos relevantes para os clusters do GKE, como upgrades importantes disponíveis ou boletins de segurança, o GKE envia essas notificações para o Cloud Logging. Para encontrar esses registros no Cloud Logging, consulte Como visualizar notificações de cluster no Cloud Logging.
O GKE também publica notificações sobre esses eventos como mensagens para tópicos do Pub/Sub que você configura. Você pode receber essas notificações em uma assinatura do Pub/Sub, fazer a integração com 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.
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 ajudar 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, o que proporciona mais visibilidade sobre as 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 para o Cloud Logging por padrão. Você pode usar todos os recursos do Cloud Logging, incluindo consultar e visualizar registros e configurar políticas de alertas 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.
Tipos de notificação de upgrade
O GKE envia os seguintes tipos de notificação de cluster:
SecurityBulletinEvent
UpgradeAvailableEvent
UpgradeEvent
UpgradeInfoEvent
, que inclui os seguintes tipos de eventos:
Se você visualizar as notificações de 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 que você receba notificações apenas de eventos relevantes.
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.
UpgradeInfoEvent
O GKE envia uma
notificação 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 de UpgradeInfoEvent
.
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.
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. Executar 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 estiver executando 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 pode 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 após o 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 disso.
- 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 do cluster. O GKE envia essa notificação quando a primeira versão de patch a usar 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.
- As metas atuais e novas.
- Como o GKE pausa os upgrades automáticos de patch para os nós.
A versão do patch que usa o novo marco se torna o destino do upgrade automático do patch para o cluster, e os upgrades automáticos de nós são pausados. Os administradores do cluster precisam decidir qual das seguintes próximas etapas será realizada:
- 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.
- Não faça upgrades de patch até que o GKE faça upgrade do cluster para a próxima versão secundária perto do 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.
Como visualizar notificações de cluster no Cloud Logging
Para acessar os registros dos 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 filtro a seguir 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 .
Veja os registros com o filtro a seguir para conferir um tipo específico de notificação de cluster, como UpgradeEvent
:
jsonPayload.@type=type.googleapis.com/google.container.v1beta1.NOTIFICATION_TYPE
Substitua NOTIFICATION_TYPE
pelo tipo de notificação
do cluster dos registros que você quer ver.
Filtrar notificações de cluster 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:
- A operação de upgrade foi
concluída:
UPGRADE_LIFECYCLE
- Versão secundária no fim ou perto do fim do
suporte:
END_OF_SUPPORT
- Novas versões de patch mudam para um novo marco do Container-Optimized OS
durante o suporte estendido:
COS_MILESTONE_VERSION_UPDATE
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 em um ou mais tipos de notificação disponíveis ao ativar as notificações de cluster especificando valores para filter
na flag --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.
Filtrar notificações no GKE não afeta quais registros 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.
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. 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 será semelhante a esta 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 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 será semelhante a esta 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
UpgradeInfoEvent
quando uma operação de upgrade
é concluída, como este exemplo para um
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/ |
Essa saída é diferente de quando as mensagens são para uma versão secundária no fim do suporte ou perto dele ou quando novas versões de patch mudam para um novo marco do Container-Optimized OS durante o suporte estendido.
A seguir
- Saiba como receber notificações de cluster pelo Pub/Sub.
- Saiba como configurar notificações de cluster para serviços de terceiros.