Intervalles de maintenance et exclusions

Cette page décrit les intervalles de maintenance et les exclusions de maintenance, qui sont des règles permettant de contrôler à quel moment certaines opérations de maintenance des clusters, telles que les mises à niveau automatiques, peuvent être effectuées sur vos clusters Google Kubernetes Engine (GKE). Par exemple, une entreprise de vente au détail peut limiter les tâches de maintenance aux soirs de semaine et empêcher la maintenance automatique lors d'un événement commercial majeur.

À propos des règles de maintenance GKE

Les règles de maintenance GKE, qui incluent des intervalles et des exclusions de maintenance, vous permettent de contrôler à quel moment certaines opérations de maintenance automatique peuvent être effectuées sur vos clusters, y compris les mises à niveau et d'autres modifications apportées à la configuration des nœuds ou à la topologie réseau du cluster.

Un intervalle de maintenance est une période récurrente pendant laquelle la maintenance automatique GKE est autorisée.

Une exclusion de maintenance est une période non récurrente pendant laquelle la maintenance automatique GKE est interdite.

GKE effectue des modifications automatiques qui respectent les règles de maintenance de votre cluster lorsqu'il existe un intervalle de maintenance ouvert et qu'aucune exclusion de maintenance active n'est présente. Pour chaque cluster, vous pouvez configurer un intervalle de maintenance récurrent et plusieurs exclusions de maintenance.

Les autres types de maintenance ne dépendent pas des règles de maintenance de GKE, y compris les opérations de réparation du plan de contrôle et la maintenance des services dont dépend GKE, tels que Compute Engine. Pour en savoir plus, consultez la section Maintenance automatique qui ne respecte pas les règles de maintenance.

Quelles modifications respectent ou non les règles de maintenance GKE ?

Avant de configurer des règles de maintenance GKE (intervalles et exclusions de maintenance), consultez les sections suivantes pour comprendre comment GKE et les services associés appliquent ou non ces règles.

Maintenance automatique qui respecte les règles de maintenance GKE

Avec les règles de maintenance GKE, vous pouvez contrôler la chronologie des types d'événements suivants, qui entraînent une perturbation temporaire de votre cluster :

Les autres types de maintenance automatique ne dépendent pas des règles de maintenance. Pour en savoir plus, consultez la section Maintenance automatique qui ne respecte pas les règles de maintenance.

Maintenance automatique qui ne respecte pas les règles de maintenance GKE

Les intervalles et les exclusions de maintenance GKE ne bloquent pas tous les types de maintenance automatique. Avant de configurer les règles de maintenance de votre cluster GKE, assurez-vous de bien comprendre les types de modifications qui ne respectent pas les intervalles et exclusions de maintenance.

Autres opérations de maintenance de Google Cloud

Les intervalles et exclusions de maintenance GKE n'empêchent pas la maintenance automatique des services Google Cloud sous-jacents, principalement Compute Engine, ni des services qui installent des applications sur le cluster, tels que Cloud Deploy.

Par exemple, les nœuds GKE sont des VM Compute Engine gérées par GKE pour votre cluster. Les VM Compute Engine sont parfois confrontées à des événements hôtes, qui peuvent inclure des événements de maintenance ou des erreurs d'hôte. Le comportement des VM lors de ces événements est déterminé par la règle de maintenance d'hôte de la VM qui, par défaut pour la plupart des VM, implique une migration à chaud. Cela se traduit généralement par un temps d'arrêt faible ou nul pour les nœuds. Pour la plupart des charges de travail, les règles par défaut sont suffisantes. Pour certaines familles de machines de VM, vous pouvez : Surveiller et planifier un événement de maintenance d'hôte et Déclencher un événement de maintenance d'hôte pour le synchroniser avec vos règles de maintenance GKE.

Certaines VM, y compris celles dotées de GPU et de TPU, ne peuvent pas effectuer la migration à chaud. Si vous utilisez ces accélérateurs, découvrez comment gérer les perturbations dues à la maintenance des nœuds pour les GPU ou les TPU.

Nous vous recommandons de consulter les informations sur les Événements d'hôte et les Règles de maintenance d'hôte, puis de vérifier que vos charges de travail sont préparées pour les interruptions, en particulier si elles s'exécutent sur des nœuds qui ne peuvent pas effectuer de migration à chaud.

Réparations automatiques et redimensionnement

GKE effectue des réparations automatiques sur les plans de contrôle. Cela inclut des processus tels que le redimensionnement de la VM du plan de contrôle à une taille adaptée ou le redémarrage du plan de contrôle pour résoudre des problèmes. La plupart des réparations ignorent les intervalles et les exclusions de maintenance, car l'échec des réparations peut entraîner un dysfonctionnement des clusters.

Vous ne pouvez pas désactiver les réparations du plan de contrôle. Cependant, la plupart des types de clusters, y compris les clusters Autopilot et les clusters régionaux standards, disposent de plusieurs instances dupliquées des plans de contrôle, ce qui permet d'assurer une haute disponibilité du serveur d'API Kubernetes, même pendant des événements de maintenance. Les clusters zonaux standards, qui ne possèdent qu'un seul plan de contrôle, ne peuvent pas être modifiés lors des modifications de la configuration du plan de contrôle et de la maintenance du cluster. Cela inclut le déploiement de charges de travail.

Les nœuds disposent également d'une fonctionnalité de réparation automatique, que vous pouvez désactiver pour les clusters standards.

Correction de failles de sécurité critiques

Les intervalles et les exclusions de maintenance peuvent entraîner un retard dans l'application des correctifs de sécurité. Cependant, GKE se réserve le droit de remplacer les règles de maintenance en cas de failles de sécurité critiques.

Modifications manuelles qui respectent les règles de maintenance GKE

Certaines modifications apportées aux nœuds ou à la configuration réseau nécessitent la recréation des nœuds pour appliquer la nouvelle configuration. Celles-ci incluent notamment certaines des modifications suivantes :

Ces modifications respectent les règles de maintenance GKE, ce qui signifie que GKE attend un intervalle de maintenance ouvert et attend qu'aucune exclusion de maintenance active n'empêche la maintenance des nœuds. Pour appliquer manuellement les modifications aux nœuds, utilisez Google Cloud CLI pour appeler la commande gcloud container clusters upgrade et transmettez l'option --cluster-version avec la même version de GKE que celle déjà exécutée par le pool de nœuds.

Intervalles de maintenance

Les intervalles de maintenance permettent de contrôler les mises à jour automatiques des plans de contrôle et des nœuds afin de limiter les interruptions transitoires potentielles de vos charges de travail. Les intervalles de maintenance s'avèrent utiles dans certains types de scénarios, parmi lesquels :

  • Heures creuses : vous souhaitez réduire les risques de temps d'arrêt en planifiant des mises à jour automatiques pendant les heures creuses, lorsque le trafic est réduit.
  • Heures de travail : vous tenez à ce que les mises à niveau aient lieu pendant les heures de travail, afin que quelqu'un puisse les surveiller et gérer tout problème imprévu.
  • Mises à niveau multicluster : vous souhaitez déployer les mises à niveau sur plusieurs clusters situés dans différentes régions, à raison d'une à la fois et durant des intervalles spécifiés.

En plus des mises à jour automatiques, Google peut parfois avoir besoin d'effectuer d'autres tâches de maintenance. Il est alors tenu compte, dans la mesure du possible, des intervalles de maintenance des clusters.

Si l'exécution des tâches dépasse l'intervalle de maintenance, GKE tente de les mettre en pause et de les reprendre lors de l'intervalle de maintenance suivant.

GKE se réserve le droit de déployer des mises à niveau d'urgence non planifiées en dehors des intervalles de maintenance. En outre, les mises à niveau obligatoires des logiciels obsolètes peuvent se produire automatiquement en dehors des intervalles de maintenance.

Pour savoir comment configurer un intervalle de maintenance pour un cluster nouveau ou existant, consultez la page Configurer un intervalle de maintenance.

Fuseaux horaires des intervalles de maintenance

Lorsque vous configurez et affichez des intervalles de maintenance, les heures s'affichent différemment selon l'outil employé pour les consulter :

Lors de la configuration des intervalles de maintenance

Les heures sont toujours stockées en temps UTC. Toutefois, lors de la configuration de l'intervalle de maintenance, vous utilisez soit le fuseau horaire UTC, soit votre fuseau horaire local.

Si vous configurez des intervalles de maintenance à l'aide de l'option plus générique --maintenance-window, vous ne pouvez pas spécifier de fuseau horaire. Si vous utilisez gCloud CLI ou l'API, le fuseau horaire UTC s'applique. La console Google Cloud affiche les horaires dans le fuseau horaire local.

Si vous utilisez des options plus précises, telles que --maintenance-window-start, vous pouvez spécifier le fuseau horaire dans la valeur. Si vous omettez le fuseau horaire, votre fuseau horaire local est utilisé.

Lors de l'affichage des intervalles de maintenance

Lorsque vous affichez les informations sur votre cluster, les horodatages des intervalles de maintenance peuvent s'afficher en temps UTC ou dans votre fuseau horaire local, selon l'outil utilisé pour les consulter :

  • Si vous consultez les informations du cluster dans la console Google Cloud, les heures sont toujours affichées dans votre fuseau horaire local.
  • Lorsque vous utilisez gCloud CLI pour afficher les informations de votre cluster, les heures sont toujours affichées en temps UTC.

Dans les deux cas, RRULE est toujours au format UTC. Cela signifie que si vous spécifiez, par exemple, les jours de la semaine, ces jours sont affichés au format UTC.

Exclusions de maintenance

Les exclusions de maintenance vous permettent d'empêcher la maintenance automatique pendant une période spécifique. Par exemple, de nombreuses entreprises de vente au détail interdisent les modifications d'infrastructure pendant les fêtes de fin d'année dans leurs consignes commerciales. Autre exemple, si une entreprise utilise une API dont l'abandon est planifié, elle peut utiliser des exclusions de maintenance pour suspendre les mises à niveau mineures afin de leur laisser le temps de migrer des applications.

Pour les événements connus à fort impact, il est recommandé de faire correspondre toutes les restrictions de modification internes avec une exclusion de maintenance qui commence une semaine avant l'événement et qui s'étale sur toute la durée de l'événement.

Les exclusions ne sont pas récurrentes. Vous devez donc créer chaque instance d'exclusion périodique séparément.

Lorsque les exclusions et les intervalles de maintenance se chevauchent, les exclusions sont prioritaires.

Pour apprendre à configurer des exclusions de maintenance pour un cluster nouveau ou existant, consultez la page Configurer une exclusion de maintenance.

Champ d'application d'exclusion de maintenance

Vous pouvez non seulement spécifier quand empêcher la maintenance automatique sur votre cluster, mais également limiter le champ d'application des mises à jour automatiques susceptibles de se produire. Les champs d'application d'exclusion de maintenance sont utiles dans les types de scénarios suivants, entre autres :

  • Aucune mise à jour – Empêcher toute opération de maintenance : vous souhaitez éviter temporairement toute modification de votre cluster pendant une période spécifique. Il s'agit du champ d'application par défaut.
  • Aucune mise à jour mineure – Conserver la version mineure Kubernetes actuelle : vous souhaitez conserver temporairement la version mineure d'un cluster pour éviter des modifications de l'API ou valider la version mineure suivante.
  • Aucune mise à jour mineure ou mise à jour de nœud – Empêcher la perturbation du pool de nœuds : vous souhaitez éviter temporairement l'éviction et la replanification de vos charges de travail en raison de mises à jour de nœuds.

Le tableau suivant répertorie le champ d'application des mises à jour automatiques que vous pouvez limiter dans le cadre d'une exclusion de maintenance. Le tableau indique également le type de mise à niveau (mineure ou correctif) effectué. Lorsque des mises à niveau se produisent, les VM du plan de contrôle et des pools de nœuds redémarrent. Pour les plans de contrôle, les redémarrages de VM peuvent réduire temporairement la disponibilité du serveur d'API Kubernetes, en particulier dans la topologie de cluster zonal avec un seul plan de contrôle. Pour les nœuds, les redémarrages de VM déclenchent la replanification des pods, ce qui peut perturber temporairement les charges de travail existantes. Vous pouvez définir la tolérance d'interruption de la charge de travail à l'aide d'un budget d'interruption de pod (PDB).

Champ d'application Plan de contrôle Pools de nœuds
Mise à niveau mineure Mise à niveau de type correctif Perturbation des VM
en raison de la
maintenance de GKE		 Mise à niveau mineure Mise à niveau de type correctif Perturbation des VM
en raison de la
maintenance de GKE
Aucune mise à niveau (par défaut) Non Non Non Non Non Non
Aucune mise à niveau mineure Non Oui Oui Non Oui Oui
Aucune mise à niveau mineure ni de mise à niveau des nœuds Non Oui Oui Non Non Non

Pour obtenir la définition des mises à niveau mineures et de type correctif, consultez la page Schéma de gestion des versions.

Exclusions multiples

Vous pouvez définir plusieurs exclusions sur un cluster. Ces exclusions peuvent avoir des champs d'application différents et des périodes se chevauchant. Le cas d'utilisation des fêtes de fin d'année est un exemple d'exclusions qui se chevauchent, dans lequel les champs d'application "Aucune mise à niveau" et "Aucune mise à niveau mineure" sont utilisés.

Lorsque des exclusions se chevauchent, si une exclusion active (c'est-à-dire, lorsque l'heure actuelle correspond à la période d'exclusion) bloque une mise à niveau, cette mise à niveau sera reportée.

En utilisant le cas d'utilisation des fêtes de fin d'année, un cluster comporte les exclusions suivantes :

  • Aucune mise à jour mineure : du 30 septembre au 15 janvier
  • Aucune mise à jour : du 19 novembre au 4 décembre
  • Aucune mise à jour : du 15 décembre au 5 janvier

En raison de ces exclusions qui se chevauchent, les mises à niveau suivantes seront bloquées sur le cluster :

  • Mise à jour du correctif sur le pool de nœuds le 25 novembre (refusée par l'exclusion "Aucune mise à jour")
  • Mise à jour mineure sur le plan de contrôle le 20 décembre (rejetée par les exclusions "Aucune mise à jour mineure" et "Aucune mise à jour")
  • Mise à jour du correctif sur le plan de contrôle le 25 décembre (refusée par l'exclusion "Aucune mise à jour")
  • Mise à jour mineure sur le pool de nœuds le 1er janvier (rejetée par les exclusions "Aucune mise à jour mineure" et "Aucune mise à jour")

L'événement de maintenance suivant serait autorisé sur le cluster :

  • Mise à jour du correctif sur le plan de contrôle le 10 novembre (autorisée par l'exclusion "Aucune mise à jour mineure")
  • Perturbation des VM en raison de la maintenance de GKE le 10 décembre (autorisée par l'exclusion "Aucune mise à jour mineure")

Expiration des exclusions

Lorsqu'une exclusion expire (c'est-à-dire, que l'heure actuelle est passée au-delà de l'heure de fin spécifiée pour l'exclusion), cette exclusion n'empêche plus les mises à jour de GKE. Les autres exclusions valides (non expirées) continueront à empêcher les mises à jour de GKE.

Si aucune exclusion n'empêche les mises à niveau du cluster, votre cluster sera progressivement mis à niveau vers la version par défaut actuelle figurant dans son canal de publication (ou la version statique par défaut, pour les clusters sans canal de publication).

Si votre cluster a plusieurs versions mineures de retard par rapport à la version par défaut actuelle après expiration de l'exclusion, GKE planifie une mise à niveau mineure par mois (mise à niveau du plan de contrôle et des nœuds du cluster) jusqu'à ce que votre cluster atteigne la version par défaut correspondant au canal de publication. Si vous souhaitez ramener plus rapidement votre cluster à la version par défaut, vous pouvez exécuter des mises à niveau manuelles.

Limites de configuration des exclusions de maintenance

Les exclusions de maintenance sont soumises aux limites suivantes :

  • La limitation du champ d'application des mises à niveau automatiques dans une exclusion de maintenance ne s'applique qu'aux clusters enregistrés dans un canal de publication. Pour les clusters non enregistrés dans un canal de publication, vous ne pouvez créer une exclusion de maintenance qu'avec le champ d'application "Aucune mise à niveau" par défaut.
  • Vous pouvez ajouter jusqu'à trois exclusions de maintenance qui excluent toutes les mises à jour (c'est-à-dire définies avec le champ d'application "aucune mise à jour"). Ces exclusions doivent être configurées pour prévoir une disponibilité de maintenance d'au moins 48 heures sur une période glissante de 32 jours.
  • Vous pouvez définir au maximum 20 exclusions de maintenance pour chaque cluster.
  • Si vous ne spécifiez pas de champ d'application dans votre exclusion, celui-ci est défini par défaut sur "aucune mise à niveau".
  • Vous pouvez définir des exclusions de maintenance pour différentes durées en fonction du champ d'application. Pour en savoir plus, consultez la ligne Durée de l'exclusion de maintenance dans la section Configurer une exclusion de maintenance.
  • Vous ne pouvez pas configurer d'exclusion de maintenance pour inclure ou dépasser la date de fin de vie de la version mineure. Par exemple, dans le cas d'un cluster exécutant une version mineure dans laquelle le calendrier des versions de GKE indique que sa date de fin de vie est le 5 juin 2023, vous devez définir l'heure de fin de vie de l'exclusion de maintenance sur 2023-06-05T00:00:00Z ou une heure antérieure.

Exemples d'utilisation

Voici quelques exemples d'utilisation permettant de limiter le champ d'application des mises à jour susceptibles de se produire.

Exemple : marchand préparant la période des fêtes de fin d'année

Dans cet exemple, la boutique souhaite éviter les perturbations lors de la période critique pour les ventes, à savoir les quatre jours entre le Black Friday et le Cyber Monday, et la période couvrant le mois de décembre jusqu'au début de la nouvelle année. Pour préparer cette période, l'administrateur du cluster configure les exclusions suivantes :

  • Aucune mise à niveau mineure : seules les mises à jour de type correctif sont autorisées sur le plan de contrôle et les nœuds entre le 30 septembre et le 15 janvier.
  • Aucune mise à niveau : toutes les mises à niveau sont gelées entre le 19 novembre et le 4 décembre.
  • Aucune mise à niveau : toutes les mises à niveau sont gelées entre le 15 décembre et le 5 janvier.

Si aucune autre fenêtre d'exclusion ne s'applique lorsque l'exclusion de maintenance arrive à expiration, le cluster est mis à jour vers une nouvelle version mineure de GKE si celle-ci est disponible entre le 30 septembre et le 6 janvier.

Exemple : entreprise utilisant une API bêta en cours de suppression dans Kubernetes

Dans cet exemple, une entreprise utilise l'API CustomResourceDefinition apiextensions.k8s.io/v1beta1, qui sera supprimée dans la version 1.22. Tant que l'entreprise exécute une version antérieure à la version 1.22, l'administrateur du cluster configure l'exclusion suivante :

  • Aucune mise à niveau mineure : les mises à niveau mineures sont gelées pendant trois mois, correspondant à la migration des applications clientes de apiextensions.k8s.io/v1beta1 vers apiextensions.k8s.io/v1.

Exemple : entreprise dont l'ancienne base de données n'est pas résiliente aux mises à niveau du pool de nœuds

Dans cet exemple, une entreprise exécute une base de données qui ne répond pas correctement aux évictions et aux replanifications de pods qui se produisent lors d'une mise à niveau du pool de nœuds. L'administrateur du cluster configure l'exclusion suivante :

  • Aucune mise à niveau mineure ni de mise à niveau des nœuds : les mises à niveau de nœuds sont gelées pendant trois mois. Lorsque l'entreprise sera prête à accepter des temps d'arrêt pour la base de données, elle déclenchera une mise à niveau manuelle des nœuds.

Étape suivante