Ce document explique comment Google Kubernetes Engine (GKE) publie par défaut des notifications de cluster dans Cloud Logging (et éventuellement dans Pub/Sub) lorsque des événements spécifiques se produisent dans vos clusters GKE. Ces notifications contiennent des informations sur les événements liés à la configuration de votre cluster, tels que les mises à niveau planifiées, disponibles ou en cours, les bulletins de sécurité et les dates de fin de prise en charge. Pour trouver ces journaux dans Cloud Logging, consultez Afficher les notifications de cluster dans Cloud Logging.
GKE publie également des notifications sur ces événements sous forme de messages dans les sujets Pub/Sub que vous configurez. Vous pouvez recevoir ces notifications sur un abonnement Pub/Sub, les intégrer à des services tiers et filtrer les types de notifications que vous souhaitez recevoir. Pour savoir comment configurer les notifications de cluster avec Pub/Sub, consultez Recevoir des notifications de cluster via Pub/Sub.
En plus des notifications de cluster, GKE fournit également des notifications pour le séquençage du déploiement avec des étapes personnalisées exclusivement à Cloud Logging.
Avantages
Les notifications de cluster offrent les avantages suivants :
- Vous êtes averti lorsque des bulletins de sécurité spécifiques à vos clusters sont émis, ce qui vous fournit des informations précises sur les risques et l'impact.
- Vous êtes averti lorsqu'une nouvelle version de GKE est disponible pour votre cluster, ce qui vous permet de mieux planifier les tests et les qualifications et de garantir la fluidité d'un processus de mise à niveau prévisible. Auparavant, vous deviez consulter les notes de version de GKE ou l'API GKE pour savoir si une nouvelle version de GKE a été publiée.
- Vous êtes averti lorsque GKE ou un utilisateur lance des mises à niveau du cluster et lorsque l'opération de mise à niveau se termine, ce qui vous offre une meilleure visibilité sur les opérations en arrière-plan de votre cluster.
- Vous êtes averti lorsque votre cluster exécute une version mineure de GKE qui est arrivée ou arrive bientôt en fin de compatibilité.
Vous pouvez choisir d'utiliser Cloud Logging ou Pub/Sub :
- Les notifications de cluster sont envoyées à Cloud Logging par défaut. Vous pouvez utiliser toutes les fonctionnalités de Cloud Logging, y compris interroger et afficher les journaux, et configurer des règles d'alerte basées sur les journaux.
- Pub/Sub est une solution hautement extensible, qui vous offre toute flexibilité pour le traitement des notifications entrantes. Par exemple, vous pouvez l'intégrer avec Slack pour transférer les notifications vers une chaîne Slack, ou faire appel aux fonctions Cloud Run pour exécuter des processus personnalisés. Lorsque des processus personnalisés sont requis (par exemple, orchestrer un workflow englobant préproduction et production pour tester et certifier une mise à niveau), vous pouvez utiliser la notification pour déclencher automatiquement ces workflows.
Les notifications de séquençage du déploiement vous informent des éléments suivants :
- Progression d'un déploiement dans une séquence de déploiement avec des étapes personnalisées. Les notifications vous tiennent informé de l'état d'un déploiement. Vous pouvez ainsi surveiller les performances de vos clusters et charges de travail, et prendre des mesures si nécessaire.
- Si une séquence de déploiement avec des étapes personnalisées est mal configurée, vous devez la corriger.
Types de notifications de mise à niveau
GKE envoie les types de notifications de cluster suivants :
SecurityBulletinEventUpgradeAvailableEventUpgradeEventUpgradeInfoEvent, qui inclut les types d'événements suivants :- Mises à niveau de cluster planifiées (preview)
- L'opération de mise à niveau est terminée
- Version mineure en fin de compatibilité ou proche
- Les nouvelles versions de correctifs passent à un nouveau jalon Container-Optimized OS pendant l'assistance étendue
- Événements perturbateurs lors d'une mise à niveau du pool de nœuds
Si vous affichez les notifications de cluster dans Cloud Logging, vous pouvez utiliser les fonctionnalités de Cloud Logging pour filtrer les journaux. Si vous utilisez Pub/Sub, vous pouvez filtrer les notifications que vous recevez afin de n'être averti que des événements pertinents.
GKE envoie les types de notifications de séquence de déploiement suivants pour le séquençage du déploiement avec des étapes personnalisées :
SecurityBulletinEvent
Lorsque GKE émet un bulletin de sécurité directement lié à la configuration ou à la version de votre cluster, il envoie une notification SecurityBulletinEvent qui vous fournit des informations sur la faille, et, le cas échéant, les mesures que vous pouvez prendre.
UpgradeAvailableEvent
À l'arrivée d'une nouvelle version sur un canal de publication, GKE envoie une notification UpgradeAvailableEvent aux clusters de ce canal de publication afin de les informer qu'une nouvelle version est désormais disponible. Cette notification est émise une semaine à l'avance pour les versions de correctif et au moins deux à quatre semaines à l'avance pour les versions mineures (selon le canal). Pour plus d'informations, consultez la section Versions disponibles sur un canal.
Pour les clusters qui ne figurent pas dans un version disponible, GKE envoie des notifications UpgradeAvailableEvent concernant toutes les nouvelles versions auxquelles les clusters peuvent passer, y compris les correctifs de la version mineure en cours et la version mineure suivante.
Si vous utilisez des pools de nœuds Windows Server, les informations de version de Windows sont envoyées dans le cadre de la notification UpgradeAvailableEvent.
UpgradeEvent
Lorsque vous-même ou GKE déclenchez une mise à niveau, GKE envoie une notification UpgradeEvent vous informant qu'une mise à niveau a commencé. Dans l'idéal, vous devez utiliser le type de notification UpgradeAvailableEvent pour être informé de la mise à niveau à venir afin de pouvoir effectuer la mise à niveau à l'avance ou prendre les mesures nécessaires pour la préparer, telle que la configuration de intervalles de maintenance.
La notification UpgradeEvent est envoyée au début de l'opération de mise à niveau.
L'ID d'opération associé est transmis dans le message.
Pour les mises à niveau mineures du plan de contrôle en deux étapes avec sécurité de rollback, GKE envoie cette notification lorsque la mise à niveau binaire commence et lorsque la mise à niveau de la version émulée commence. Pour en savoir plus sur les détails clés fournis par GKE, consultez Éléments inclus dans la notification pour les mises à niveau en deux étapes.
UpgradeInfoEvent
GKE envoie une notification UpgradeInfoEvent pour différents types d'événements, qui sont décrits dans les sections suivantes.
Pour en savoir plus sur le filtrage d'un type spécifique de UpgradeInfoEvent, consultez Filtrer les notifications de cluster UpgradeInfoEvent.
Mises à niveau planifiées des clusters
Lorsque GKE planifie une mise à niveau de cluster, GKE vous envoie une notification entre 72 et 96 heures à l'avance. Pour en savoir plus sur l'activation des mises à niveau planifiées des clusters, consultez Recevoir des notifications sur les mises à niveau planifiées des clusters.
L'opération de mise à niveau est terminée
Lorsque GKE termine l'opération de mise à niveau automatique ou manuelle du plan de contrôle ou des nœuds d'un cluster, il envoie une notification pour vous en informer. L'opération se termine avec l'un des états suivants :
SUCCEEDED: GKE a mis à niveau le plan de contrôle ou les nœuds.FAILED: GKE n'a pas réussi à mettre à niveau le plan de contrôle ou les nœuds.CANCELED: GKE a annulé l'opération de mise à niveau pour des raisons techniques ou commerciales, ou vous avez annulé l'opération de mise à niveau.
Utilisez la notification pour confirmer la réussite d'une opération de mise à niveau.
Contenu de la notification pour les mises à niveau en deux étapes
Pour les mises à niveau mineures du plan de contrôle en deux étapes avec sécurité de restauration, GKE envoie cette notification une fois la mise à niveau binaire terminée (c'est-à-dire au début de la période de stabilisation) et une autre fois la mise à niveau de la version émulée terminée. Ces notifications incluent des informations telles que les suivantes, le cas échéant en fonction de l'état de la mise à niveau en deux étapes :
- La version initiale
- La version cible
- Version émulée initiale
- Version émulée cible
Version mineure en fin de prise en charge ou proche
Lorsque votre cluster exécute une version mineure de GKE qui approche de la fin de l'assistance standard ou de la fin de l'assistance étendue, ou qui a atteint l'une de ces étapes, GKE vous envoie des notifications vous informant que vous devez mettre à niveau le plan de contrôle ou les nœuds de votre cluster vers la prochaine version mineure compatible. L'exécution d'une version mineure compatible vous permet de continuer à recevoir des correctifs de sécurité, des corrections de bugs et de l'assistance. GKE envoie une notification 30 jours avant la fin de la période de compatibilité et une autre à la fin de cette période, si votre cluster exécute toujours la version mineure.
GKE envoie des notifications au niveau du cluster, même si plusieurs composants de votre cluster peuvent être affectés et que votre cluster peut exécuter différentes versions mineures en même temps. Si la version mineure arrive à la fin de la période d'assistance standard et que vous avez besoin de temps pour préparer la mise à niveau vers une version compatible, vous pouvez basculer sur le version disponible étendu pour bénéficier d'une assistance à long terme. Sinon, GKE planifie des mises à niveau automatiques à la fin de la période de compatibilité. Ces notifications vous aident à vous préparer à l'application de ces règles de fin de compatibilité.
Une notification inclut les informations suivantes :
- Cluster concerné.
- Version actuelle qui est en fin de prise en charge ou proche.
- Date de fin de la prise en charge.
Pour en savoir plus sur le calendrier d'assistance des versions mineures de GKE, consultez Cycle de vie d'une version mineure de GKE.
Les nouvelles versions de correctif passent à un nouveau jalon Container-Optimized OS pendant l'assistance étendue
Lorsque votre cluster est inscrit au canal Extended pendant la période d'assistance étendue et que l'étape Container-Optimized OS utilisée par la version mineure de GKE arrive en fin de compatibilité avant la version mineure, GKE envoie une notification de cluster. GKE envoie cette notification lorsque la première version du correctif utilisant la nouvelle étape est disponible dans le canal étendu.
Cette notification inclut les informations suivantes :
- Cluster concerné.
- Version corrective qui utilise la nouvelle étape.
- Les jalons existants et nouveaux.
- Comment GKE met en veille les mises à niveau automatiques des correctifs pour les nœuds.
La version de correctif qui utilise la nouvelle étape devient finalement la cible de mise à niveau automatique des correctifs pour le cluster, et les mises à niveau automatiques des nœuds sont suspendues. Les administrateurs de cluster doivent décider de la prochaine étape à suivre parmi les suivantes :
- Mettez à niveau manuellement les nœuds du cluster vers la prochaine version de correctif qui utilise la prochaine étape de Container-Optimized OS.
- Mettez à niveau manuellement le cluster vers la version mineure suivante.
- Renoncez aux mises à niveau de correctifs jusqu'à ce que GKE mette à niveau le cluster vers la version mineure suivante vers la fin de la période de compatibilité étendue.
Pour en savoir plus, consultez La version de Container-Optimized OS arrive en fin de compatibilité avant la fin de l'assistance étendue de la version mineure.
Événements perturbateurs lors d'une mise à niveau de pool de nœuds
Lorsqu'un pool de nœuds subit certains types d'événements perturbateurs lors d'une mise à niveau, GKE envoie une notification pour vous en informer.
GKE envoie une notification de cluster pour les types d'événements perturbateurs suivants :
- Le drainage du nœud est bloqué par le budget d'interruption de pod (PDB).
- Le délai avant expiration du PDB est atteint et les pods seront supprimés de force malgré la violation du PDB.
Cette notification inclut les informations suivantes :
- Nœud concerné par cet événement de perturbation.
- Pods concernés par cet événement d'interruption.
- Opération qui a déclenché le drainage du nœud.
- Délai avant expiration du PDB avant la suppression forcée des pods.
RolloutEvent
GKE envoie des notifications lorsque les événements suivants se produisent pour le déploiement d'une version GKE dans une séquence de déploiement avec des étapes personnalisées :
ROLLOUT_CREATED: un déploiement a été créé.ROLLOUT_STAGE_TRANSITION: une étape du déploiement est passée à un nouvel état.ROLLOUT_BLOCKED: le déploiement est bloqué, car un plan de contrôle ou un pool de nœuds n'est pas éligible à la mise à niveau.ROLLOUT_AUTO_PAUSED: le déploiement a été automatiquement suspendu par GKE.ROLLOUT_AUTO_RESUMED: le déploiement a été automatiquement repris après avoir été mis en pause.ROLLOUT_CANCELLATION_WARNING: le déploiement a été suspendu pendant trop longtemps et sera automatiquement annulé dans sept jours s'il n'est pas repris.ROLLOUT_AUTO_CANCELLED: le déploiement a été automatiquement annulé par GKE.ROLLOUT_COMPLETED: le déploiement s'est terminé avec succès.
RolloutSequenceEvent
GKE envoie des notifications dans les situations suivantes pour une séquence de déploiement avec des étapes personnalisées :
SEQUENCE_MISCONFIGURED: la séquence de déploiement est mal configurée, ce qui signifie que GKE ne peut pas effectuer de mises à niveau dans la séquence avec sa configuration actuelle.SEQUENCE_DEACTIVATION_WARNING: avertissement indiquant que GKE désactivera la séquence de déploiement si la configuration incorrecte n'est pas corrigée.
Afficher les notifications de cluster dans Cloud Logging
Les instructions suivantes s'appliquent à la fois aux notifications de cluster et aux notifications de séquencement de déploiement.
Pour afficher les journaux des clusters GKE, consultez Accéder à vos journaux.
Pour désactiver le stockage de ces journaux, vous pouvez configurer un filtre d'exclusion.
Affichez les journaux dans Cloud Logging avec le filtre suivant pour voir tous les types de notifications de cluster :
logName=projects/PROJECT_ID/logs/container.googleapis.com%2Fnotifications
Remplacez PROJECT_ID par l'ID du projet Google Cloud .
Affichez les journaux avec le filtre suivant pour voir un type de notification de cluster spécifique, tel que UpgradeEvent :
jsonPayload.@type=type.googleapis.com/google.container.v1beta1.NOTIFICATION_TYPE
Remplacez NOTIFICATION_TYPE par le type de notification de cluster pour les journaux que vous souhaitez afficher.
Filtrer les notifications de cluster UpgradeInfoEvent
Affichez les journaux avec le filtre suivant pour voir un UpgradeInfoEvent spécifique, tel que la notification indiquant qu'une opération de mise à niveau est terminée :
jsonPayload.@type=type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent
jsonPayload.eventType=EVENT_TYPE
Remplacez EVENT_TYPE par l'un des éléments suivants :
- L'opération de mise à niveau est terminée :
UPGRADE_LIFECYCLE - Version mineure en fin de compatibilité ou proche de la fin de compatibilité :
END_OF_SUPPORT - Les nouvelles versions de correctifs passent à un nouveau jalon Container-Optimized OS pendant l'assistance étendue :
COS_MILESTONE_VERSION_UPDATE - Événements perturbateurs lors d'une mise à niveau de pool de nœuds :
DISRUPTION_EVENT - Mises à niveau planifiées des clusters :
UPGRADE_LIFECYCLE
Filtrer les notifications vers Pub/Sub
Vous pouvez filtrer les notifications de cluster pour vous assurer de ne recevoir que celles que vous souhaitez dans Pub/Sub. Vous pouvez appliquer le filtrage des notifications à Pub/Sub de l'une des manières suivantes :
Pour afficher et filtrer les notifications dans Cloud Logging, consultez Afficher les notifications de cluster dans Cloud Logging.
Filtrer les notifications Pub/Sub dans GKE
Vous pouvez configurer le filtrage vers Pub/Sub pour un ou plusieurs types de notifications disponibles lors de l'activation des notifications de cluster en spécifiant des valeurs pour filter dans l'option --notification-config. filter utilise une liste délimitée par des barres verticales ( | ) des types de notifications que vous souhaitez recevoir.
Par exemple, si vous spécifiez filter="UpgradeEvent|SecurityBulletinEvent", vous indiquez à GKE de n'envoyer que des notifications pour les types de notifications UpgradeEvent et SecurityBulletinEvent.
Le filtrage des notifications à l'aide de filter présente les avantages suivants :
- Utilisation facilitée, car ils permettent de filtrer le type de notification sans utiliser de syntaxe spécifique ;
- Les notifications que vous filtrez ne sont jamais envoyées à Pub/Sub. Par conséquent, les messages non distribués ne vous sont pas facturés.
- Vous pouvez modifier la configuration du filtre à tout moment.
Pour obtenir des instructions sur le filtrage des notifications dans GKE, consultez Recevoir des notifications de cluster via Pub/Sub.
Le filtrage des notifications dans GKE n'a aucune incidence sur les journaux qui s'affichent dans Cloud Logging.
Filtrer les notifications dans Pub/Sub.
Pub/Sub permet de filtrer les messages de votre abonnement à l'aide d'une syntaxe de filtrage. Lorsque vous utilisez cette méthode, GKE transmet tous les types de notifications à votre sujet Pub/Sub. Pub/Sub filtre les messages en fonction de la configuration de votre abonnement et envoie les messages que vous souhaitez recevoir.
Par exemple, vous pouvez filtrer les notifications UpgradeEvent et UpgradeAvailableEvent à l'aide de la syntaxe suivante dans votre abonnement :
attributes.type_url = "type.googleapis.com/google.container.v1beta1.UpgradeEvent" OR "type.googleapis.com/google.container.v1beta1.UpgradeAvailableEvent"
Vous êtes toujours facturé pour les messages non distribués filtrés par votre abonnement. Vous ne pouvez pas non plus modifier les filtres après avoir configuré l'abonnement. Cependant, la syntaxe de filtrage est plus extensible que le filtrage dans GKE.
Pour en savoir plus sur le filtrage de votre abonnement Pub/Sub, consultez la section Filtrer des messages.
Alertes sur les notifications de cluster dans Cloud Logging
Vous pouvez configurer des alertes basées sur les journaux pour recevoir des notifications lorsque des événements de cluster spécifiques se produisent. La section suivante fournit un exemple de base de configuration d'une alerte basée sur les journaux, mais vous trouverez d'autres exemples dans le dépôt d'exemples de tableaux de bord de surveillance.
Créer une alerte basée sur les journaux
Pour créer une alerte pour un type d'avis spécifique, procédez comme suit.
Les étapes suivantes utilisent UpgradeEvent comme exemple.
Dans la console Google Cloud , accédez à l'explorateur de journaux.
Dans le champ Requête, saisissez la requête suivante pour filtrer le type d'avis de votre choix :
resource.type="RESOURCE_TYPE" log_id("container.googleapis.com/notifications") jsonPayload.@type="type.googleapis.com/google.container.v1beta1.NOTIFICATION_TYPE"Remplacez les éléments suivants :
RESOURCE_TYPE: type de ressource sur lequel vous souhaitez filtrer, par exemplegke_clusterOUgke_nodepool, ou une combinaison.NOTIFICATION_TYPE: type de notification de cluster pour lequel vous souhaitez recevoir une alerte, par exempleUpgradeEvent.
Certains types de notifications nécessitent un filtrage supplémentaire. Par exemple, si vous souhaitez filtrer un type spécifique de
UpgradeInfoEvent, ajoutez le filtrejsonPayload.eventTypeà votre requête. L'exemple de requête suivant filtre les événementsUpgradeInfoEventdont le type estUPGRADE_LIFECYCLE:resource.type="RESOURCE_TYPE" log_id("container.googleapis.com/notifications") jsonPayload.@type="type.googleapis.com/google.container.v1beta1.UpgradeInfoEvent" jsonPayload.eventType="UPGRADE_LIFECYCLE"Pour en savoir plus sur le filtrage de
UpgradeInfoEvent, consultez Filtrer les notifications de clusterUpgradeInfoEvent.Dans le menu Actions, cliquez sur Créer une alerte de journal.
Sur la page Détails de l'alerte, donnez un nom à votre règle d'alerte, puis cliquez sur Suivant.
Dans la section Définir les entrées de journal pour lesquelles des alertes doivent être générées, votre requête est préremplie.
Dans la section Extraire les étiquettes de journaux, cliquez sur Ajouter une étiquette. L'extraction des étiquettes de journaux permet de rendre vos notifications plus informatives. Par exemple, pour un
UpgradeEvent, vous pouvez inclure les versions actuelle et cible d'une mise à niveau en ajoutant les étiquettes suivantes :- CurrentVersion :
jsonPayload.currentVersion - TargetVersion :
jsonPayload.targetVersion
- CurrentVersion :
Cliquez sur Suivant.
Configurez la fréquence des notifications et le délai pour la fermeture automatique, puis cliquez sur Suivant.
Dans la section Qui doit être informé ?, sélectionnez les canaux de notification sur lesquels vous souhaitez recevoir les alertes, puis cliquez sur Enregistrer.
Une fois l'alerte configurée, les notifications pour un UpgradeEvent incluent les étiquettes CurrentVersion et TargetVersion, ce qui fournit un contexte utile directement dans la notification.
Consommer des messages Pub/Sub
Les messages Pub/Sub contiennent deux champs : data (chaîne) et attributes (mappage chaîne à chaîne).
Pour les notifications GKE, le champ data contient des informations lisibles par l'humain. Le champ attributes contient des informations de notification génériques telles que le type de notification, l'ID de votre projet, le nom du cluster et son emplacement.
Le champ attributes.payload est une chaîne analysable par JSON qui contient des informations de notification spécifiques, telles que les détails d'un bulletin de sécurité.
Les notifications comportent toujours les attributs suivants :
| Attribut | Description | Exemple |
|---|---|---|
project_id |
Numéro du projet propriétaire du cluster. | 123456789 |
cluster_location |
Emplacement du cluster. | us-central1-c |
cluster_name |
Nom du cluster. | example-cluster |
type_url |
Type de notification. | type.googleapis.com/google.container.v1beta1.UpgradeEvent
|
payload |
Chaîne au format JSON, pouvant être analysée et contenant des informations spécifiques aux notifications. | { "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 envoie toujours des types de notifications beta. Cependant, vous pouvez analyser la charge utile pour afficher le type de notification GA correspondant s'il est disponible.
Exemples de messages de notification de cluster
En plus du texte dans le champ data, chaque message envoyé par GKE à Cloud Logging ou Pub/Sub possède des valeurs spécifiques dans les champs attributes.type_url et attributes.payload. Les tableaux suivants présentent des exemples d'informations que vous pouvez recevoir pour chaque type de notification :
SecurityBulletinEvent
Le résultat est semblable à ce qui suit pour un message SecurityBulletinEvent :
| Attributs | |
|---|---|
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
Le résultat est semblable à ce qui suit pour un message UpgradeAvailableEvent :
| Attributs | |
|---|---|
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
Le résultat est semblable à celui-ci pour un message UpgradeEvent :
| Attributs | |
|---|---|
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"} |
Ce résultat représente une notification pour une mise à niveau du plan de contrôle en une seule étape. Les informations contenues dans la notification de mise à niveau en deux étapes sont différentes. Pour en savoir plus sur les différents types de mises à niveau du plan de contrôle, consultez Mettre à niveau le plan de contrôle du cluster.
UpgradeInfoEvent
Le résultat est semblable à celui de l'UpgradeInfoEvent
lorsqu'une opération de mise à niveau est terminée, comme dans cet exemple pour la mise à niveau d'un pool de nœuds :
| Attributs | |
|---|---|
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/ |
Ce résultat est différent des notifications de mise à niveau du plan de contrôle, lorsque les messages concernent une version mineure en fin de compatibilité ou proche de la fin de compatibilité, lorsque les nouvelles versions de correctif passent à un nouveau jalon Container-Optimized OS pendant la période de compatibilité étendue, ou pour les événements perturbateurs lors d'une mise à niveau de pool de nœuds.
Notification de mise à niveau programmée du cluster
Lorsqu'une mise à niveau de cluster est planifiée et que les notifications de mise à niveau planifiée sont activées, GKE envoie un message de sortie UpgradeInfoEvent semblable au suivant pour une mise à niveau planifiée du plan de contrôle :
| Attributs | |
|---|---|
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": " |
GKE envoie un message de sortie semblable à celui-ci pour les mises à niveau de nœuds planifiées :
| Attributs | |
|---|---|
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: |
Pour les mises à niveau de nœuds planifiées, qui sont regroupées par cible de mise à niveau automatique, GKE liste par ordre alphabétique jusqu'à 10 pools de nœuds, en ne fournissant des informations détaillées que pour le premier pool de nœuds. Si plus de 10 pools de nœuds sont programmés, GKE affiche le nombre de pools restants non listés (par exemple, 33 mises à niveau au total dans cet exemple).
Étapes suivantes
- Découvrez comment recevoir des notifications de cluster.
- Découvrez comment envoyer des notifications de cluster à Slack.
- En savoir plus sur les mises à niveau de clusters pour les clusters GKE Standard
- Consultez la présentation des intervalles et exclusions de maintenance.