Utiliser la maintenance planifiée pour planifier et contrôler les mises à niveau de votre cluster Azure Kubernetes Service
Cet article explique comment utiliser la maintenance planifiée pour planifier et contrôler les mises à niveau d’images de cluster et de nœud dans Azure Kubernetes Service (AKS).
Une maintenance régulière est effectuée automatiquement sur votre cluster AKS. Il existe deux types d’opérations de maintenance :
- La maintenance lancée par AKS implique les versions hebdomadaires publiées par AKS pour tenir votre cluster à jour avec les dernières fonctionnalités et correctifs.
- La maintenance lancée par l’utilisateur inclut les mises à niveau automatiques de cluster et les mises à jour de sécurité automatiques du système d’exploitation de nœud.
Lorsque vous utilisez la fonctionnalité de maintenance planifiée dans AKS, vous pouvez exécuter les deux types de maintenance à la cadence de votre choix pour réduire l’impact de la charge de travail. Vous pouvez utiliser la maintenance planifiée pour planifier le minutage des mises à niveau automatiques, mais l’activation ou la désactivation de la maintenance planifiée n’active pas ou ne désactive pas les mises à niveau automatiques.
Avant de commencer
- Cet article suppose que vous avez un cluster AKS existant. Si vous ne disposez pas de cluster AKS, consultez Créer un cluster AKS.
- Si vous utilisez Azure CLI, effectuez une mise à niveau vers la dernière version à l’aide de la commande
az upgrade
.
À propos de l’installation
Lorsque vous utilisez la maintenance planifiée, les considérations suivantes s’appliquent :
- AKS se réserve le droit d’arrêter ces fenêtres d’opérations de maintenance planifiées pour les opérations non planifiées ou réactives qui sont urgentes ou critiques. Ces opérations de maintenance peuvent même s’exécuter pendant les périodes
notAllowedTime
ounotAllowedDates
définies dans votre configuration. - Les opérations de maintenance obéissent au principe faire pour le mieux uniquement et il n’est pas garanti qu’elles se produisent dans une période spécifiée.
Planifier des types de configuration pour la maintenance planifiée
Trois types de configuration de planification sont disponibles pour la maintenance planifiée :
default
est une configuration de base pour contrôler les versions AKS. Ces versions peuvent prendre jusqu’à deux semaines pour être déployées dans toutes les régions à partir du moment initial de l’expédition, en raison des pratiques de déploiement sécurisées Azure (SDP).Choisissez
default
pour planifier ces mises à jour de manière à vous perturber le moins possible. Vous pouvez surveiller l’état d’une version AKS en cours par région avec l’outil de suivi des versions hebdomadaires.aksManagedAutoUpgradeSchedule
contrôle quand effectuer des mises à niveau de cluster planifiées par votre canal de mise à niveau automatique désigné. Cette configuration vous permet de configurer des paramètres de fréquence et de périodicité avec plus de précision par rapport à la configurationdefault
. Pour plus d’informations sur la mise à niveau automatique de clusters, consultez Mettre à niveau automatiquement un cluster Azure Kubernetes Service.aksManagedNodeOSUpgradeSchedule
contrôle quand effectuer le correctif de sécurité de système d’exploitation planifié par votre canal de mise à niveau automatique du système d’exploitation de nœud. Cette configuration vous permet de configurer des paramètres de fréquence et de périodicité avec plus de précision par rapport à la configurationdefault
. Pour plus d’informations sur le canal de mise à niveau automatique du système d’exploitation de nœud, consultez Corriger et mettre à jour automatiquement des images de nœud de cluster AKS
Nous vous recommandons d’utiliser aksManagedAutoUpgradeSchedule
pour tous les scénarios de mise à niveau de clusters et aksManagedNodeOSUpgradeSchedule
pour tous les scénarios de correctifs de sécurité du système d’exploitation du nœud.
L’option default
est destinée exclusivement aux versions hebdomadaires d’AKS. Vous pouvez basculer la configuration default
vers la configuration aksManagedAutoUpgradeSchedule
ou aksManagedNodeOSUpgradeSchedule
à l’aide de la commande az aks maintenanceconfiguration update
.
Créer une fenêtre de maintenance
Remarque
Quand vous utilisez la mise à niveau automatique, utilisez une fenêtre de maintenance d’une durée de quatre heures minimum afin de garantir un fonctionnement correct.
Les fenêtres de maintenance planifiée sont spécifiées en temps universel coordonné (UTC).
Une fenêtre de maintenance default
possède les propriétés héritées suivantes (n’étant plus recommandées) :
Nom | Description | Valeur par défaut |
---|---|---|
timeInWeek |
Dans une configuration default , cette propriété contient les valeurs day et hourSlots qui définissent une fenêtre de maintenance |
Non applicable |
timeInWeek.day |
Jour de la semaine de la maintenance dans une configuration default . |
Non applicable |
timeInWeek.hourSlots |
Liste des créneaux d’une heure pour effectuer la maintenance un jour particulier dans une configuration default . |
Non applicable |
notAllowedTime |
Plage de dates pendant laquelle la maintenance ne peut pas s’exécuter, déterminée par les propriétés enfants start et end . Cette propriété s’applique uniquement lorsque vous créez la fenêtre de maintenance à l’aide d’un fichier de configuration. |
Non applicable |
Remarque
À partir de la version 2023-05-01 de l’API, utilisez les propriétés ci-dessous pour la configuration de default
.
À partir de la version 2023-05-01 de l’API, une fenêtre de maintenance aksManagedAutoUpgradeSchedule
ou aksManagedNodeOSUpgradeSchedule
, ainsi qu’une configuration default
ont les propriétés suivantes :
Nom | Description | Valeur par défaut |
---|---|---|
utcOffset |
Fuseau horaire pour la maintenance du cluster. | +00:00 |
startDate |
Date à laquelle la fenêtre de maintenance commence à prendre effet. | Date actuelle au moment de la création |
startTime |
Heure du début de la maintenance, selon le fuseau horaire déterminé par utcOffset . |
Non applicable |
schedule |
Fréquence de mise à niveau. Trois types sont disponibles : Weekly , AbsoluteMonthly et RelativeMonthly . |
Non applicable |
intervalDays |
Intervalle en jours des exécutions de maintenance. Applicable uniquement à aksManagedNodeOSUpgradeSchedule . |
Non applicable |
intervalWeeks |
Intervalle en semaines des exécutions de maintenance. | Non applicable |
intervalMonths |
Intervalle en mois des exécutions de maintenance. | Non applicable |
dayOfWeek |
Jour de la semaine spécifié pour le début de la maintenance. | Non applicable |
durationHours |
Durée de la fenêtre pour l’exécution de la maintenance. | Non applicable |
notAllowedDates |
Plage de dates pendant laquelle la maintenance ne peut pas s’exécuter, déterminée par les propriétés enfants start et end . Applicable uniquement lorsque vous créez la fenêtre de maintenance à l’aide d’un fichier de configuration. |
Non applicable |
Types de planification
Quatre types de planification sont disponibles : Daily
, Weekly
, AbsoluteMonthly
et RelativeMonthly
.
Les types de planification Weekly
, AbsoluteMonthly
et RelativeMonthly
s’appliquent uniquement aux configurations aksManagedClusterAutoUpgradeSchedule
et aksManagedNodeOSUpgradeSchedule
. Les planifications Daily
s’appliquent uniquement aux configurations aksManagedNodeOSUpgradeSchedule
.
Tous les champs affichés pour chaque type de planification sont obligatoires.
Une planification Daily
peut ressembler à « tous les trois jours » :
"schedule": {
"daily": {
"intervalDays": 3
}
}
Une planification Weekly
peut ressembler à « toutes les deux semaines, le vendredi » :
"schedule": {
"weekly": {
"intervalWeeks": 2,
"dayOfWeek": "Friday"
}
}
Une planification AbsoluteMonthly
peut ressembler à « tous les trois mois, le premier jour du mois » :
"schedule": {
"absoluteMonthly": {
"intervalMonths": 3,
"dayOfMonth": 1
}
}
Une planification RelativeMonthly
peut ressembler à « tous les deux mois, le dernier lundi » :
"schedule": {
"relativeMonthly": {
"intervalMonths": 2,
"dayOfWeek": "Monday",
"weekIndex": "Last"
}
}
Les valeurs valides pour weekIndex
sont First
, Second
, Third
, Fourth
et Last
.
Ajouter une configuration de fenêtre de maintenance
Ajoutez une configuration de fenêtre de maintenance à un cluster AKS à l’aide de la commande az aks maintenanceconfiguration add
.
Le premier exemple ajoute une nouvelle configuration default
qui planifie l’exécution de la maintenance de 01:00 à 02:00 tous les lundis. Le deuxième exemple ajoute une nouvelle configuration aksManagedAutoUpgradeSchedule
qui planifie l’exécution de la maintenance tous les troisièmes vendredis du mois, entre 00:00 et 08:00 dans le fuseau horaire UTC+5:30
.
# Add a new default configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 1
# Add a new aksManagedAutoUpgradeSchedule configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule --schedule-type Weekly --day-of-week Friday --interval-weeks 3 --duration 8 --utc-offset +05:30 --start-time 00:00
Remarque
Quand vous utilisez un type de configuration default
, vous pouvez omettre le paramètre --start-time
pour autoriser la maintenance à tout moment au cours d’une journée.
Mettre à jour une fenêtre de maintenance existante
Mettez à jour une configuration de maintenance existante à l’aide de la commande az aks maintenanceconfiguration update
.
L’exemple suivant met à jour la configuration default
pour planifier l’exécution de la maintenance de 02:00 à 03:00 tous les lundis :
az aks maintenanceconfiguration update --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 2
Répertorier toutes les fenêtres de maintenance dans un cluster existant
Répertoriez toutes les fenêtres de configuration de maintenance actuelles dans votre cluster AKS à l’aide de la commande az aks maintenanceconfiguration list
:
az aks maintenanceconfiguration list --resource-group myResourceGroup --cluster-name myAKSCluster
Afficher une fenêtre spécifique de configuration de la maintenance dans un cluster existant
Affichez une fenêtre spécifique de configuration de maintenance dans votre cluster AKS à l’aide de la commande az aks maintenanceconfiguration show
avec le paramètre --name
:
az aks maintenanceconfiguration show --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule
L’exemple de sortie suivant affiche la fenêtre de maintenance pour aksManagedAutoUpgradeSchedule
:
{
"id": "/subscriptions/<subscription>/resourceGroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster/maintenanceConfigurations/aksManagedAutoUpgradeSchedule",
"maintenanceWindow": {
"durationHours": 4,
"notAllowedDates": [
{
"end": "2024-01-05",
"start": "2023-12-23"
}
],
"schedule": {
"absoluteMonthly": {
"dayOfMonth": 1,
"intervalMonths": 3
},
"daily": null,
"relativeMonthly": null,
"weekly": null
},
"startDate": "2023-01-20",
"startTime": "09:00",
"utcOffset": "-08:00"
},
"name": "aksManagedAutoUpgradeSchedule",
"notAllowedTime": null,
"resourceGroup": "myResourceGroup",
"systemData": null,
"timeInWeek": null,
"type": null
}
Supprimez une fenêtre de configuration de la maintenance dans un cluster existant
Supprimez une fenêtre de configuration de maintenance dans votre cluster AKS à l’aide de la commande az aks maintenanceconfiguration delete
.
L’exemple suivant supprime la configuration de maintenance autoUpgradeSchedule
:
az aks maintenanceconfiguration delete --resource-group myResourceGroup --cluster-name myAKSCluster --name autoUpgradeSchedule
FAQ
Comment puis-je consulter les configurations de maintenance existantes dans mon cluster ?
Utilisez la commande
az aks maintenanceconfiguration show
.La maintenance réactive non planifiée peut-elle également se produire pendant les périodes
notAllowedTime
ounotAllowedDates
?Oui. AKS se réserve le droit d’arrêter ces fenêtres pour des opérations de maintenance non planifiées réactives qui sont urgentes ou critiques.
Comment faire pour savoir si un événement de maintenance s’est produit ?
Pour les versions, consultez la région de votre cluster et recherchez les informations dans les versions hebdomadaires afin de vérifier si elles correspondent à votre planification de maintenance. Pour afficher l’état de vos mises à niveau automatiques, recherchez les journaux d’activité sur votre cluster. Vous pouvez également rechercher des événements liés à une mise à niveau spécifique, comme indiqué dans Mettre à niveau un cluster AKS.
AKS émet également des événements Azure Event Grid liés à la mise à niveau. Pour plus d’informations, consultez AKS en tant que source Event Grid.
Puis-je utiliser plusieurs configurations de maintenance en même temps ?
Oui, vous pouvez exécuter les trois configurations simultanément :
default
,aksManagedAutoUpgradeSchedule
etaksManagedNodeOSUpgradeSchedule
. Si les fenêtres se chevauchent, AKS décide de l’ordre d’exécution.J’ai configuré une fenêtre de maintenance, mais la mise à niveau n’a pas eu lieu. Pourquoi ?
La mise à niveau automatique d’AKS nécessite un certain temps (généralement pas plus de 15 minutes) pour prendre en compte la fenêtre de maintenance. Nous vous recommandons de laisser s’écouler au moins 15 minutes entre la création ou la mise à jour d’une configuration de maintenance et l’heure de début planifiée.
Vérifiez également que votre cluster est démarré lorsque la fenêtre de maintenance planifiée débute. Si le cluster est arrêté, son plan de contrôle est libéré et aucune opération ne peut être effectuée.
Pourquoi l’un de mes pools d’agents a-t-il été mis à niveau en dehors de la fenêtre de maintenance ?
Si un pool d’agents n’est pas mis à niveau (par exemple, car les budgets d’interruption des pods l’ont empêché), il peut être mis à niveau ultérieurement, en dehors de la fenêtre de maintenance. Ce scénario est appelé « mise à niveau de rattrapage ». Il évite de faire en sorte que les pools d’agents soit mis à niveau avec une version différente du plan de contrôle AKS.
Une autre raison pour laquelle un pool d’agents peut être mis à niveau de manière inattendue est qu’il n’existe pas de configuration de maintenance définie ou qu’il a été supprimé. Dans ce cas, un cluster avec mise à niveau automatique mais sans configuration de maintenance sera mis à niveau à des moments aléatoires (planification de secours), ce qui signifie que cela peut se produire à un moment non souhaité.
Existe-t-il de meilleures pratiques pour les configurations de maintenance ?
Nous vous recommandons de définir la planification des mises à jour de sécurité du système d’exploitation de nœud sur une cadence hebdomadaire si vous utilisez le canal
NodeImage
, car une nouvelle image de nœud est livrée chaque semaine. Vous pouvez également choisir le canalSecurityPatch
afin de recevoir des mises à jour de sécurité quotidiennes.Définissez la planification de mise à niveau automatique sur une cadence mensuelle pour rester au fait de la stratégie de prise en charge Kubernetes N-2.
Pour obtenir une discussion détaillée sur les bonnes pratiques de mise à niveau et d’autres considérations, consultez l’article Correctif et conseils de mise à niveau d’Azure Kubernetes Service.
Puis-je configurer tous mes clusters dans un abonnement unique pour utiliser la même configuration de maintenance ?
Nous vous déconseillons d’utiliser la même configuration de maintenance pour plusieurs clusters dans un abonnement unique, car cela peut entraîner des erreurs de limitation ARM entraînant l’échec des mises à niveau de cluster. Au lieu de cela, nous vous recommandons de mettre en place des fenêtres de maintenance pour chaque cluster afin d’éviter ces erreurs.
Étapes suivantes
- Pour bien démarrer avec la mise à niveau de votre cluster AKS, consultez Options de mise à niveau des clusters AKS.
Azure Kubernetes Service