Intervalles de maintenance et exclusions

Cette page décrit les intervalles de maintenance et les exclusions de maintenance qui permettent de contrôler à quel moment les tâches de maintenance, telle que les mises à jour 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.

Présentation

Les intervalles et les exclusions de maintenance permettent de contrôler avec précision les tâches de maintenance automatique sur vos clusters.

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

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

Les intervalles et les exclusions de maintenance peuvent être configurés de manière distincte et indépendante. Vous pouvez configurer plusieurs exclusions de maintenance.

Exemples de maintenance automatique

Google effectue des tâches de maintenance sur vos clusters en fonction des besoins, ou lorsque vous effectuez une modification de configuration qui recrée des nœuds ou des réseaux dans le cluster, par exemple :

Les clusters zonaux ne peuvent pas être modifiés lors des modifications de la configuration du plan de contrôle et en cas de maintenance du cluster. Cela inclut le déploiement de charges de travail.

Chacun des autres types de modifications présentés ci-dessus peut entraîner des interruptions temporaires lors de la migration des charges de travail vers des nœuds mis à niveau.

Mises en garde

Les intervalles et les exclusions de maintenance peuvent entraîner un retard dans l'application des correctifs de sécurité. GKE se réserve le droit de remplacer les règles de maintenance en cas de failles de sécurité critiques. Avant d'activer des intervalles et des exclusions de maintenance, assurez-vous de bien comprendre les mises en garde suivantes.

Autres opérations de maintenance de Google Cloud

Les clusters et les charges de travail GKE peuvent également être affectés par la maintenance automatique sur d'autres services dépendants, tels que Compute Engine. Les intervalles et les exclusions de maintenance GKE n'empêchent pas la maintenance automatique à partir d'autres services Google, ni les services qui installent des applications sur le cluster, tels que Cloud Deploy.

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. La réparation automatique des plans de contrôle ne peut pas être désactivée.

Les nœuds offrent également une fonctionnalité de réparation automatique, mais celle-ci peut être désactivée.

Recréation des nœuds et intervalles de maintenance

Lorsque vous activez ou modifiez des fonctionnalités ou des options, comme celles qui ont une incidence sur la mise en réseau entre les plans de contrôle et les nœuds, ces nœuds sont recréés afin d'appliquer la nouvelle configuration. Voici quelques exemples de fonctionnalités qui entraînent la recréation des nœuds :

Si vous utilisez des intervalles ou des exclusions de maintenance, et que vous activez ou modifiez une fonctionnalité ou une option nécessitant la recréation de nœuds, telle que la rotation des identifiants sur le cluster, la nouvelle configuration n'est appliquée aux nœuds que si la maintenance des nœuds est autorisée. Pour éviter d'attendre, vous pouvez appliquer manuellement les modifications aux nœuds en appelant la commande gcloud container clusters upgrade et en transmettant l'option --cluster-version avec la même version de GKE que celle exécutée par le pool de nœuds. Vous devez utiliser la Google Cloud CLI pour mettre en œuvre cette solution.

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.

Restrictions

Les intervalles de maintenance sont soumis aux restrictions suivantes :

Un seul intervalle de maintenance par cluster

Vous ne pouvez configurer qu'un seul intervalle de maintenance par cluster. La configuration d'un nouvel intervalle de maintenance remplace la configuration précédente.

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

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 temps UTC s'applique. Si vous utilisez la console Google Cloud, les heures sont affichées 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é. Les heures sont toujours stockées en temps UTC.

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 et/ou correctif) effectué. Lorsque des mises à niveau se produisent, la ou les VM du plan de contrôle et/ou du pool 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

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 standards non enregistrés dans une version disponible, 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".
  • La durée d'une exclusion de maintenance est soumise à des restrictions basées sur le champ d'application des exclusions spécifiées :
    • Aucune mise à niveau : ne peut pas dépasser 30 jours.
    • Aucune mise à niveau mineure : ne peut pas se terminer plus de 180 jours après la date de création de l'exclusion.
    • Aucune mise à niveau mineure ni mise à niveau des nœuds : ne peut pas se terminer plus de 180 jours après la date de création de l'exclusion.
  • 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