Notifiche del cluster

Questa pagina descrive in che modo Google Kubernetes Engine (GKE) pubblica le notifiche dei cluster in Cloud Logging per impostazione predefinita e, facoltativamente, in Pub/Sub. Queste notifiche contengono informazioni sugli eventi pertinenti alla configurazione del cluster, come upgrade disponibili o in corso, bollettini sulla sicurezza e date di fine del supporto.

Panoramica

Quando si verificano determinati eventi pertinenti per i tuoi cluster GKE, come importanti upgrade o bollettini sulla sicurezza disponibili, GKE invia queste notifiche a Cloud Logging. Per trovare questi log in Cloud Logging, consulta Visualizzazione delle notifiche del cluster in Cloud Logging.

GKE pubblica anche notifiche relative a questi eventi come messaggi negli argomenti Pub/Sub che configuri. Puoi ricevere queste notifiche in una sottoscrizione Pub/Sub, integrarle con servizi di terze parti e filtrare in base ai tipi di notifiche che vuoi ricevere. Per saperne di più su come configurare le notifiche del cluster con Pub/Sub, consulta Ricevere le notifiche del cluster tramite Pub/Sub.

Vantaggi

Le notifiche dei cluster offrono i seguenti vantaggi:

  • Ricevi una notifica quando vengono pubblicati bollettini sulla sicurezza specifici per i tuoi cluster, che ti forniscono informazioni accurate su rischi e impatto.
  • Ricevi una notifica quando è disponibile una nuova versione di GKE per il tuo cluster, in modo da pianificare meglio i test e le qualifiche e garantire un processo di upgrade fluido e prevedibile. In precedenza, dovevi controllare le note di rilascio di GKE o l'API GKE per scoprire quando è stata rilasciata una nuova versione di GKE.
  • Ricevi una notifica quando GKE o un utente avvia gli upgrade del cluster e quando l'operazione di upgrade termina, in modo da avere maggiore visibilità sulle operazioni in background del cluster.
  • Ricevi una notifica quando il tuo cluster esegue una versione secondaria di GKE che si trova alla fine del periodo di supporto o in prossimità.

  • Puoi scegliere se utilizzare Cloud Logging o Pub/Sub:

    • Le notifiche del cluster vengono inviate a Cloud Logging per impostazione predefinita. Puoi utilizzare tutte le funzionalità di Cloud Logging, tra cui l'esecuzione di query e la visualizzazione dei log e la configurazione di criteri di avviso basati sui log.
    • Pub/Sub è altamente estensibile e ti offre flessibilità nel modo in cui elabori le notifiche in entrata. Ad esempio, puoi eseguire l'integrazione con Slack per inoltrare le notifiche a un canale Slack o avviare funzioni Cloud Run per eseguire processi personalizzati. Quando sono necessari processi personalizzati (ad esempio, l'orchestrazione di un flusso di lavoro di staging in produzione per testare e certificare un upgrade), puoi utilizzare la notifica per attivare automaticamente questi flussi di lavoro.

Tipi di notifiche di upgrade

GKE invia i seguenti tipi di notifiche del cluster:

Se visualizzi le notifiche del cluster in Cloud Logging, puoi utilizzare le funzionalità di Cloud Logging per filtrare i log. Se utilizzi Pub/Sub, puoi filtrare le notifiche che ricevi in modo da ricevere notifiche solo per gli eventi pertinenti.

SecurityBulletinEvent

Quando GKE pubblica un bollettino sulla sicurezza direttamente correlato alla configurazione o alla versione del tuo cluster, GKE invia una notifica SecurityBulletinEvent, fornendoti informazioni sulla vulnerabilità, sull'impatto e, se applicabile, sulle azioni che puoi intraprendere.

UpgradeAvailableEvent

Quando una nuova versione diventa disponibile su un canale di rilascio, GKE invia una notifica UpgradeAvailableEvent ai cluster su quel canale di rilascio per informarli che una nuova versione è ora disponibile. Questa notifica fornisce un preavviso di una settimana per le versioni patch e di almeno 2-4 settimane per le versioni secondarie (a seconda del canale). Per saperne di più, consulta Quali versioni sono disponibili in un canale.

Per i cluster non presenti in un canale di rilascio, GKE invia notifiche UpgradeAvailableEvent per tutte le nuove versioni a cui è possibile eseguire l'upgrade dei cluster, incluse le patch sulla versione secondaria corrente e sulla versione secondaria successiva.

Se utilizzi i pool di nodi Windows Server, le informazioni sulla versione di Windows vengono inviate come parte della notifica UpgradeAvailableEvent.

UpgradeEvent

Quando tu o GKE avviate un upgrade, GKE invia una notifica UpgradeEvent che ti informa dell'inizio di un upgrade. Idealmente, dovresti utilizzare il tipo di notifica UpgradeAvailableEvent per essere a conoscenza dell'upgrade imminente in modo da eseguirlo in anticipo o prendere le misure necessarie per prepararti, come la configurazione di periodi di manutenzione.

La notifica UpgradeEvent viene inviata all'inizio dell'operazione di upgrade. L'ID operazione viene passato nel messaggio.

UpgradeInfoEvent

GKE invia una notifica UpgradeInfoEvent per diversi tipi di eventi, descritti nelle sezioni successive.

Per saperne di più sul filtraggio per un tipo specifico di UpgradeInfoEvent, vedi Filtrare le notifiche dei cluster UpgradeInfoEvent.

L'operazione di upgrade è stata completata

Quando GKE termina l'operazione per eseguire l'upgrade automatico o manuale del control plane o dei nodi di un cluster, invia una notifica per informarti che l'operazione è completata. L'operazione viene completata con uno dei seguenti stati:

  • SUCCEEDED: GKE ha eseguito l'upgrade del control plane o dei nodi.
  • FAILED: GKE non è riuscito a eseguire l'upgrade del control plane o dei nodi.
  • CANCELED: GKE ha annullato l'operazione di upgrade per motivi tecnici o commerciali oppure hai annullato l'operazione di upgrade.

Utilizza la notifica per confermare la riuscita di un'operazione di upgrade.

Versione secondaria alla fine o quasi alla fine del supporto

Quando il cluster esegue una versione secondaria di GKE che si avvicina alla fine dell'assistenza standard o alla fine dell'assistenza estesa oppure ha raggiunto uno di questi traguardi, GKE invia notifiche che ti informano che devi eseguire l'upgrade del control plane o dei nodi del cluster alla successiva versione secondaria supportata. L'esecuzione di una versione secondaria supportata garantisce la ricezione continua di patch di sicurezza, correzioni di bug e assistenza. GKE invia una notifica 30 giorni prima della fine del supporto e una notifica al termine del supporto, se il cluster esegue ancora la versione secondaria.

GKE invia notifiche a livello di cluster, anche se potrebbero essere interessati più componenti del cluster e il cluster può eseguire contemporaneamente versioni secondarie diverse. Se la versione secondaria sta per raggiungere la fine del supporto standard e hai bisogno di tempo per prepararti a eseguire l'upgrade a una versione supportata, puoi passare al canale di rilascio esteso per ricevere assistenza a lungo termine. In caso contrario, GKE pianifica gli upgrade automatici al termine dell'assistenza. Queste notifiche ti aiutano a prepararti all'applicazione di queste norme di fine del supporto.

Una notifica include i seguenti dettagli:

  • Il cluster interessato.
  • La versione attuale che è alla fine del supporto o quasi.
  • La data di fine del supporto.

Per maggiori dettagli sulla cronologia dell'assistenza per le versioni secondarie di GKE, consulta il ciclo di vita delle versioni secondarie di GKE.

Passaggio alle nuove versioni delle patch alla nuova pietra miliare di Container-Optimized OS durante il supporto esteso

Quando il cluster è registrato nel canale esteso durante il periodo di supporto esteso e la milestone di Container-Optimized OS utilizzata dalla versione secondaria di GKE raggiunge la fine del supporto prima della versione secondaria, GKE invia una notifica al cluster. GKE invia questa notifica quando la prima versione patch che utilizza il nuovo traguardo diventa disponibile nel canale Extended.

Questa notifica include i seguenti dettagli:

  • Il cluster interessato.
  • La versione della patch che utilizza il nuovo traguardo.
  • Le tappe fondamentali esistenti e nuove.
  • In che modo GKE mette in pausa gli upgrade automatici delle patch per i nodi.

La versione patch che utilizza il nuovo traguardo alla fine diventa la destinazione dell'upgrade automatico della patch per il cluster e gli upgrade automatici dei nodi vengono sospesi. Gli amministratori del cluster devono decidere quali dei seguenti passaggi successivi intraprendere:

  • Esegui manualmente l'upgrade dei nodi del cluster alla patch successiva che utilizza la successiva milestone di Container-Optimized OS.
  • Esegui manualmente l'upgrade del cluster alla versione secondaria successiva.
  • Rinuncia agli upgrade delle patch finché GKE non esegue l'upgrade del cluster alla versione secondaria successiva verso la fine del supporto esteso.

Per saperne di più, vedi La milestone di Container-Optimized OS raggiunge la fine del supporto prima della fine del supporto esteso della versione secondaria.

Visualizzazione delle notifiche del cluster in Cloud Logging

Per visualizzare i log dei cluster GKE, consulta la sezione Accesso ai log.

Per disattivare l'archiviazione di questi log, puoi configurare un filtro di esclusione.

Visualizza i log in Cloud Logging con il seguente filtro per visualizzare tutti i tipi di notifiche del cluster:

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

Sostituisci PROJECT_ID con l'ID del tuo progetto Trusted Cloud by S3NS .

Visualizza i log con il seguente filtro per visualizzare un tipo specifico di notifica del cluster, ad esempio UpgradeEvent:

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

Sostituisci NOTIFICATION_TYPE con il tipo di notifica del cluster per i log che vuoi visualizzare.

Filtrare le notifiche dei cluster UpgradeInfoEvent

Visualizza i log con il seguente filtro per vedere un UpgradeInfoEvent specifico, ad esempio la notifica che indica il completamento di un'operazione di upgrade:

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

Sostituisci EVENT_TYPE con una delle seguenti opzioni:

Filtrare le notifiche in Pub/Sub

Puoi filtrare le notifiche del cluster per assicurarti di ricevere solo le notifiche che ti interessano in Pub/Sub. Puoi applicare il filtro per le notifiche a Pub/Sub in uno dei seguenti modi:

Per visualizzare e filtrare le notifiche in Cloud Logging, consulta Visualizzazione delle notifiche del cluster in Cloud Logging.

Filtrare le notifiche in Pub/Sub in GKE

Quando attivi le notifiche del cluster, puoi configurare il filtro per Pub/Sub per uno o più tipi di notifiche disponibili specificando i valori per filter nel flag --notification-config. filter accetta un elenco delimitato da barre verticali ( | ) dei tipi di notifica che vuoi ricevere.

Ad esempio, se specifichi filter="UpgradeEvent|SecurityBulletinEvent", GKE invierà notifiche solo per i tipi di notifiche UpgradeEvent e SecurityBulletinEvent.

Il filtraggio delle notifiche tramite filter offre vantaggi come i seguenti:

  • Più facile da usare, perché filtri in base al tipo di notifica senza utilizzare una sintassi specifica.
  • Le notifiche che filtri non vengono mai inviate a Pub/Sub, quindi non ti vengono addebitati costi per i messaggi non consegnati.
  • Puoi modificare la configurazione del filtro in qualsiasi momento.

Per istruzioni sul filtraggio delle notifiche in GKE, vedi Ricevere notifiche del cluster tramite Pub/Sub.

Il filtraggio delle notifiche in GKE non influisce sui log visualizzati in Cloud Logging.

Filtrare le notifiche in Pub/Sub

Pub/Sub supporta il filtraggio dei messaggi nella sottoscrizione utilizzando una sintassi di filtraggio. Quando utilizzi questo metodo, GKE invia tutti i tipi di notifiche all'argomento Pub/Sub. Pub/Sub filtra i messaggi in base alla configurazione della sottoscrizione e consegna i messaggi che vuoi ricevere.

Ad esempio, puoi filtrare le notifiche UpgradeEvent e UpgradeAvailableEvent utilizzando la seguente sintassi nell'abbonamento:

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

Ti vengono comunque addebitati i messaggi non consegnati filtrati dal tuo abbonamento. Inoltre, non puoi modificare i filtri dopo aver configurato l'abbonamento. Tuttavia, la sintassi di filtraggio è più estensibile rispetto al filtraggio in GKE.

Per scoprire di più sul filtraggio della sottoscrizione Pub/Sub, consulta Filtrare i messaggi.

Utilizzo dei messaggi Pub/Sub

I messaggi Pub/Sub contengono due campi: data (stringa) e attributes (mappa da stringa a stringa).

Per le notifiche GKE, il campo data contiene informazioni leggibili. Il campo attributes contiene informazioni generiche sulle notifiche, ad esempio il tipo di notifica, l'ID progetto, il nome del cluster e la posizione del cluster. Il campo attributes.payload è una stringa analizzabile in formato JSON che contiene informazioni specifiche sulle notifiche, ad esempio i dettagli di unbollettino sulla sicurezzaa.

Le notifiche contengono sempre i seguenti attributi:

Attributo Descrizione Esempio
project_id Il numero del progetto proprietario del cluster. 123456789
cluster_location La posizione del cluster. us-central1-c
cluster_name Il nome del cluster. example-cluster
type_url Il tipo di notifica. type.googleapis.com/google.container.v1beta1.UpgradeEvent
payload Una stringa analizzabile in formato JSON contenente informazioni specifiche per la notifica. 
{ "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"}

GKE invierà sempre i tipi di notifica beta. Tuttavia, puoi analizzare il payload per visualizzare il tipo di notifica GA corrispondente, se disponibile.

Messaggi di notifica del cluster di esempio

Oltre al testo nel campo data, ogni messaggio che GKE invia a Cloud Logging o Pub/Sub ha valori specifici nei campi attributes.type_url e attributes.payload. Le tabelle seguenti mostrano esempi delle informazioni che potresti ricevere per ogni tipo di notifica:

SecurityBulletinEvent

L'output è simile al seguente per un messaggio SecurityBulletinEvent:

Attributi
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

L'output è simile al seguente per un messaggio UpgradeAvailableEvent:

Attributi
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

L'output è simile al seguente per un messaggio UpgradeEvent:

Attributi
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

L'output è simile al seguente per un messaggio UpgradeInfoEvent per il completamento di un'operazione di upgrade, come questo esempio per un upgrade del pool di nodi:

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

Questo output è diverso da quello che si verifica quando i messaggi riguardano una versione secondaria alla fine del supporto o in prossimità di questa data oppure quando le nuove versioni delle patch passano a una nuova milestone di Container-Optimized OS durante il supporto esteso.

Passaggi successivi