Ce document présente le concept de budgets de perturbations de cluster et explique comment vous pouvez éventuellement les personnaliser pour les adapter aux besoins de votre environnement. Les budgets de perturbation de cluster font partie d'une suite de fonctionnalités qui permettent à un administrateur de plate-forme de minimiser les perturbations des charges de travail tout en améliorant leurs performances, leur fiabilité et leur sécurité.
Les mises à niveau de cluster (lorsque GKE met à jour la version utilisée par le plan de contrôle et les nœuds de votre cluster) peuvent être une source majeure de perturbation pour un cluster GKE. Pour en savoir plus sur les mises à niveau, consultez À propos des mises à niveau des clusters GKE. Pour en savoir plus sur toutes les autres fonctionnalités permettant de minimiser les perturbations lors des mises à niveau de cluster, consultez la section Contrôler les mises à niveau de cluster de ce document. Pour obtenir des informations plus générales sur les modifications du cycle de vie des clusters au-delà des mises à niveau, consultez Gérer les modifications du cycle de vie des clusters pour minimiser les perturbations.
Qu'est-ce qu'un budget d'interruptions de clusters ?
Pour éviter que votre cluster ne soit trop souvent perturbé par les mises à niveau automatiques, GKE applique par défaut un budget de perturbation du cluster afin de définir un intervalle minimal entre les mises à niveau automatiques du plan de contrôle du cluster. GKE applique également ce budget entre la création du cluster et la première mise à niveau automatique du plan de contrôle. De plus, si vous mettez à niveau manuellement le plan de contrôle du cluster, GKE respecte le budget d'indisponibilité du cluster lors de la prochaine mise à niveau automatique. Vous pouvez toujours mettre à niveau manuellement le cluster, même si cette mise à niveau ne respecte pas le budget de perturbation du cluster.
Dans un cluster, GKE met automatiquement à niveau le plan de contrôle avant les nœuds. Ce budget définit également la cadence minimale des mises à niveau automatiques des nœuds de cluster.
GKE dispose de budgets d'indisponibilité par défaut pour les différents types de mises à niveau de version :
- Mises à niveau de versions de correctif : 24 heures
- Mises à niveau de versions mineures : 30 jours
GKE applique le budget entre les mêmes types de mises à niveau. Par exemple, GKE attend 24 heures entre la mise à niveau d'un cluster entre les versions correctives 1.35.0-gke.1403000 et 1.35.0-gke.1624000, et 30 jours entre les versions 1.34 et 1.35. Toutefois, GKE attend 24 heures après une mise à niveau mineure avant d'effectuer une mise à niveau corrective.
GKE n'utilise un budget de perturbation du cluster que pour les mises à niveau du cluster, et non pour les autres types de modifications apportées à un cluster GKE.
Le budget d'interruptions du cluster est distinct des intervalles et des exclusions de maintenance, mais peut être utilisé en complément. Les règles de maintenance contrôlent à quel moment la maintenance des clusters GKE peut avoir lieu, tandis que le budget de perturbation des clusters définit un intervalle de temps spécifique entre les mises à niveau des clusters.
Quand personnaliser le budget d'interruption de votre cluster
Les budgets d'interruption de cluster par défaut de GKE reflètent un équilibre entre la rapidité des mises à niveau, tout en évitant les mises à niveau consécutives et en optimisant la stabilité. Toutefois, ces valeurs générales ne sont peut-être pas idéales pour votre environnement de cluster.
Si vous souhaitez contrôler cette durée minimale entre les mises à niveau automatiques du cluster, vous pouvez configurer le budget d'indisponibilité du cluster. Prenons les exemples suivants :
- Vous disposez d'un processus personnalisé pour évaluer une version corrective du plan de contrôle GKE avant de la déployer en production. Ce processus prend un certain temps, supérieur au budget de cluster par défaut.
- Vous disposez de grands clusters qui mettent plus de temps à mettre à niveau tous les pools de nœuds. Vous souhaitez maintenir une cohérence relative des versions dans ces pools de nœuds. Vous réduisez donc la fréquence des mises à niveau des correctifs, en les effectuant tous les mois, tout en autorisant des intervalles de maintenance fréquents pour vous assurer que les mises à niveau du pool de nœuds sont effectuées en temps voulu.
Définir le budget d'interruption de cluster pour les mises à niveau automatiques
Si vous avez besoin de contrôler l'intervalle entre deux mises à niveau mineures ou deux mises à niveau correctives, vous pouvez définir vos propres budgets de perturbation de cluster. Toutefois, nous vous recommandons de commencer par configurer un intervalle de maintenance pour définir une heure récurrente pour la maintenance des clusters GKE. Vous pouvez ensuite personnaliser l'intervalle entre les mises à niveau à l'aide du budget de perturbation du cluster.
Nous vous recommandons d'utiliser le budget de perturbation du cluster avec les autres outils disponibles dans GKE pour contrôler les mises à niveau du cluster. Ces paramètres, qui fonctionnent avec tous les autres outils de mise à niveau, n'affectent que le moment où GKE met automatiquement à niveau un cluster vers une nouvelle version. GKE respecte toujours les intervalles et les exclusions de maintenance, suit l'ordre d'une séquence de déploiement et applique toutes les autres pratiques standards généralement utilisées pour les mises à niveau automatiques.
Le budget d'interruption de cluster par défaut est de 24 heures pour les mises à niveau de correctifs et de 30 jours pour les mises à niveau mineures. Vous pouvez configurer les intervalles sur une durée comprise entre 0 et 90 jours. Toutefois, vous devez tenir compte des points suivants lorsque vous mettez à jour ces valeurs :
- Nous vous recommandons de ne pas définir l'intervalle de mise à niveau des correctifs sur une durée supérieure à 30 jours, sauf si vous disposez d'un processus de qualification de version spécifique qui prend plus de temps. Vous risquez de manquer des correctifs critiques si vous effectuez des mises à niveau moins souvent que tous les 30 jours.
- Nous vous recommandons d'autoriser les mises à niveau mineures aussi souvent que possible pour l'environnement de votre cluster. Si vous définissez l'intervalle de mise à niveau mineure sur le maximum de 90 jours, vous augmentez le risque que GKE doive mettre à niveau votre cluster à partir de la version mineure lorsqu'elle atteindra la fin de la période d'assistance. GKE respecte un budget de perturbation de cluster distinct de sept jours pour les mises à niveau mineures lorsqu'une version mineure arrive en fin de compatibilité. Il ne respecte aucun budget de perturbation de cluster que vous avez configuré. Pour en savoir plus, consultez Mises à niveau automatiques à la fin de la période d'assistance.
- Nous vous recommandons de définir l'intervalle des mises à niveau correctives sur une période plus courte que celui des mises à niveau mineures.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande
gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Configurer le budget d'interruption du cluster
Tout d'abord, si vous ne l'avez pas déjà fait, nous vous recommandons de configurer une période de maintenance.
Ensuite, pour définir un budget d'indisponibilité de cluster personnalisé, utilisez les options suivantes lorsque vous créez ou mettez à jour un cluster à l'aide de la gcloud CLI :
- Mises à niveau mineures :
--maintenance-minor-version-disruption-interval=MINOR_INTERVAL - Mises à niveau des correctifs :
--maintenance-patch-version-disruption-interval=PATCH_INTERVAL
Pour ces indicateurs, remplacez MINOR_INTERVAL ou PATCH_INTERVAL, respectivement, par une durée exprimée en secondes, comprise entre 0 jour (0s) et 90 jours (7776000s).
Vous pouvez utiliser ces options dans les cas suivants :
- Créer un cluster :
- Autopilot :
gcloud container clusters create-auto - Standard :
gcloud container cluster create
- Autopilot :
- Mettre à jour un cluster :
gcloud container cluster update
Vous pouvez utiliser les indicateurs en même temps ou indépendamment.
Rétablir le budget de perturbation du cluster sur les valeurs par défaut
Pour rétablir les valeurs par défaut du budget d'indisponibilité du cluster (24 heures pour les mises à niveau correctives et 30 jours pour les mises à niveau mineures), vous pouvez utiliser les indicateurs suivants :
- Mises à niveau mineures :
--clear-maintenance-minor-version-disruption-interval - Mises à niveau correctives :
--clear-maintenance-patch-version-disruption-interval
Utilisez ces indicateurs lorsque vous mettez à jour un cluster avec la commande gcloud container cluster
update.
Vous pouvez utiliser les indicateurs en même temps ou indépendamment.