Framework de planification Kubernetes : liste de vérification des opérations de production avec exemples pratiques

Introduction

L'exploitation en production du framework de planification Kubernetes exige une approche systématique : observer l'état actuel, comprendre le pipeline de planification, apporter des modifications ciblées et vérifier les résultats. Cet article fournit une liste de vérification pratique avec des commandes, les sorties attendues, les signaux de défaillance et les étapes de reprise pour les ingénieurs qui exploitent le framework de planification en production.

Le framework de planification Kubernetes est une architecture modulaire intégrée au kube-scheduler qui permet d'étendre le comportement de planification avec des plugins personnalisés. En production, une mauvaise configuration ou un manque d'observabilité peut entraîner des pods bloqués en état Pending, un gaspillage de ressources ou des SLO non respectés. Cette liste de vérification s'adresse aux ingénieurs DevOps, aux équipes plateforme et aux SRE qui gèrent des clusters Kubernetes et doivent garantir que la couche de planification est saine, correctement configurée et récupérable.

Nous aborderons l'inventaire des versions et de l'environnement, les chemins de configuration sûrs, la vérification et les diagnostics, les modes de défaillance et la reprise, ainsi qu'une liste de vérification consolidée des opérations. Chaque section fournit des commandes concrètes et des exemples. En suivant ce guide, vous pourrez détecter les problèmes tôt, modifier la configuration en toute sécurité et récupérer après incident avec confiance.

Inventaire des versions et de l'environnement

Comprendre votre framework de planification commence par un inventaire précis. Cela inclut la version du cluster, la configuration du scheduler, les versions des plugins et les ressources dépendantes. Une incompatibilité de version ou une configuration obsolète peut modifier silencieusement le comportement de planification, alors commencez par collecter des informations en lecture seule avant toute modification.

Vérifier la version du cluster et du scheduler

Exécutez la commande suivante pour voir la version du kube-scheduler :

kubectl version --short
kubectl get pods -n kube-system -l component=kube-scheduler -o wide

La sortie attendue inclut le nom du pod du scheduler, le nœud et le statut. Par exemple :

NAME                 READY   STATUS    RESTARTS   AGE   IP           NODE
kube-scheduler-minikube   1/1     Running   0          10d   10.0.0.1     control-plane

Si le pod du scheduler ne tourne pas ou plante, consultez les journaux avec :

kubectl logs -n kube-system kube-scheduler-minikube --previous

Cela affiche les détails de la boucle de crash. Pour un cluster managé (EKS, GKE, AKS), le plan de contrôle n'est pas directement accessible ; fiez-vous alors à kubectl version et à la documentation du fournisseur cloud pour l'alignement des versions du scheduler.

Inspecter la configuration du scheduler

La configuration du kube-scheduler est souvent définie dans un fichier KubeSchedulerConfiguration monté en tant que ConfigMap ou fichier. Pour voir la configuration actuelle, utilisez :

kubectl get configmap -n kube-system kube-scheduler-config -o yaml

Si le scheduler tourne comme un pod statique, inspectez son manifeste :

kubectl get pod -n kube-system kube-scheduler-minikube -o yaml | grep -A 20 command

Recherchez des options comme --config=/etc/kubernetes/scheduler-config.yaml. Ensuite, ``kubectl exec`` dans le pod du scheduler (si autorisé) ou accédez au nœud pour lire le fichier. Exemple d'extrait de configuration :

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        enabled:
          - name: NodeResourcesFit
            weight: 1

Notez la liste des plugins et leurs poids. C'est essentiel pour le dépannage des problèmes de scoring.

Vérifier les prérequis et dépendances

Listez tous les CRD liés aux extensions de planification, comme PriorityClass, RuntimeClass ou les plugins de planification personnalisés :

kubectl get crd | grep -E 'scheduling|priority|runtime'

Vérifiez la disponibilité des nœuds et les taints, car ils affectent directement la planification :

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

Exemple de sortie :

NAME                 TAINTS
node1               <none>
node2               [key=value:NoSchedule]

Si une taint existe sans tolérance correspondante, les pods ne pourront pas être planifiés sur ce nœud. Ce type d'inventaire doit être réalisé avant tout changement.

Rayon d'impact et chemin de reprise

Pour tout changement potentiel, identifiez les ressources affectées. Par exemple, modifier la politique du scheduler peut affecter tous les pods qui utilisent le scheduler par défaut. Si vous ajoutez un plugin, assurez-vous que le pod du scheduler redémarre correctement et qu'aucun pod ne reste non planifié. Ayez toujours un plan de retour en arrière, comme restaurer la ConfigMap précédente et redémarrer le scheduler.

Chemin de configuration sûr

Modifier la configuration du scheduler en production doit suivre un processus contrôlé : tester dans un cluster de staging, revoir le schéma de configuration, appliquer avec un minimum de perturbations et vérifier les résultats de la planification. Cette section fournit un chemin sûr étape par étape.

Étape 1 : Comprendre le changement souhaité

Exemple : vous voulez ajouter un plugin de scoring personnalisé qui préfère les nœuds avec SSD pour certaines charges de travail. Définissez la configuration souhaitée du plugin. Dans KubeSchedulerConfiguration, ajoutez le plugin sous score et assurez-vous que le binaire du plugin est disponible dans l'image du scheduler ou via un volume monté.

Pour Kubernetes managé, il se peut que vous ne puissiez pas modifier directement le scheduler ; vous devrez plutôt déployer un second scheduler. Dans ce cas, créez un nouveau Deployment avec un nom de scheduler personnalisé et une configuration, puis mettez à jour les charges de travail pour utiliser ce scheduler.

Étape 2 : Valider le schéma de configuration

Avant d'appliquer, validez la syntaxe YAML et le schéma. Utilisez un outil local comme kube-scheduler --config=config.yaml --validate si disponible, ou lancez un dry-run avec l'API server :

kubectl apply --dry-run=client -f scheduler-config.yaml

Remarque : cela valide uniquement le schéma général des ressources Kubernetes, pas la configuration spécifique au scheduler. Pour cela, fiez-vous à la documentation et à la validation spécifique à la version. Vérifiez la version de Kubernetes pour vous assurer que la version de l'API de configuration (kubescheduler.config.k8s.io/v1 vs v1beta1) correspond. Exemple pour Kubernetes 1.26+ : utilisez v1.

Étape 3 : Appliquer le changement avec un rayon d'impact minimal

Si vous modifiez le scheduler par défaut, mettez à jour la ConfigMap ou le fichier, puis redémarrez le pod du scheduler. Pour un pod statique, le kubelet le redémarrera automatiquement lors du changement de fichier. Pour un scheduler basé sur un Deployment, déclenchez un redémarrage progressif :

kubectl rollout restart deployment custom-scheduler -n kube-system

Surveillez le déploiement :

kubectl rollout status deployment/custom-scheduler -n kube-system

Sortie attendue : deployment "custom-scheduler" successfully rolled out.

Si vous utilisez un second scheduler pour des charges de travail spécifiques, mettez à jour le Deployment de ce scheduler uniquement. Les pods existants ne sont pas affectés, mais les nouveaux pods utilisant ce scheduler le seront.

Étape 4 : Tester la planification avec un pod d'exemple

Créez un pod de test qui utilise le nouveau scheduler ou la configuration modifiée. Par exemple, pour tester le scheduler par défaut avec un nouveau plugin de scoring, déployez un pod avec le nom de scheduler approprié :

apiVersion: v1
kind: Pod
metadata:
  name: test-scheduling
spec:
  schedulerName: default-scheduler
  containers:
  - name: test
    image: busybox
    command: ["sleep", "3600"]
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

Appliquez et vérifiez le statut :

kubectl apply -f test-pod.yaml
kubectl get pod test-scheduling -o wide

Le pod doit être en état Running, et la colonne NODE doit indiquer un nœud approprié. S'il reste Pending, utilisez kubectl describe pod pour voir les événements du scheduler.

Étape 5 : Vérifier la décision de planification

Inspectez les journaux du scheduler pour confirmer que le plugin a été utilisé. Si la verbosité du scheduler est définie, vous pouvez voir les détails du scoring. Pour augmenter temporairement la journalisation, définissez --v=4 dans la commande du scheduler, mais évitez une verbosité élevée en production en raison de l'impact sur les performances. Pour le débogage, vous pouvez exécuter une instance séparée du scheduler avec une verbosité plus élevée pointée vers le même cluster pendant une courte période, mais n'y planifiez pas de pods de production à moins de les isoler soigneusement avec schedulerName.

Documentez toujours le changement et le plan de retour en arrière. Par exemple :

• Changement : ajout du plugin de scoring NodeResourcesFit avec un poids de 2 pour le scheduler default-scheduler.
• Retour en arrière : restaurer la ConfigMap précédente kube-scheduler-config depuis la sauvegarde, supprimer le pod du scheduler pour redémarrer.

Vérification et diagnostics

Après tout changement, ou lors d'une opération de routine, vérifiez la santé du scheduler et diagnostiquez les problèmes courants. Cette section couvre les commandes et les signaux pour la vérification.

Commandes de vérification de la santé

Vérifiez le statut du pod du scheduler et les journaux :

kubectl get pods -n kube-system -l component=kube-scheduler
kubectl logs -n kube-system kube-scheduler-minikube --tail=100

Recherchez des erreurs comme failed to load config, plugin not found, ou des messages répétés d'élection de leader (normaux dans les configurations HA).

Vérifiez l'élection de leader du scheduler (si plusieurs réplicas) :

kubectl get endpoints -n kube-system kube-scheduler -o yaml

L'annotation control-plane.alpha.kubernetes.io/leader indique le leader actuel. Exemple :

annotations:
  control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"kube-scheduler-minikube", ...}'

Diagnostic des pods en attente

Lorsqu'un pod est bloqué en Pending, décrivez-le pour voir les événements :

kubectl describe pod <pod-name>

Messages courants d'échec de planification :

• 0/3 nodes are available: 3 Insufficient cpu. → les demandes de ressources sont trop élevées.
• 0/3 nodes are available: 1 node(s) had taint {key: value}, that the pod didn't tolerate. → ajoutez une tolérance ou supprimez la taint.
• 0/3 nodes are available: 3 node(s) didn't match node selector. → ajustez le nodeSelector ou étiquetez les nœuds.

Utilisez kubectl get events --sort-by=.lastTimestamp pour voir les événements récents de planification.

Vérifier les plugins du framework de planification

Pour confirmer quels plugins sont actifs, interrogez la configuration du scheduler. Si vous avez accès au fichier de configuration du pod du scheduler, consultez-le. Pour une configuration basée sur ConfigMap :

kubectl get configmap kube-scheduler-config -n kube-system -o jsonpath='{.data}' | jq .

Alternativement, utilisez kubectl describe sur le pod du scheduler pour voir les arguments de commande qui référencent le fichier de configuration, puis exécutez un exec dans le pod (si possible) pour afficher le fichier.

Métriques et observabilité

Si Prometheus est configuré, interrogez les métriques du scheduler :

scheduler_pending_pods
scheduler_schedule_attempts_total
scheduler_scheduling_duration_seconds

Exemple d'alerte : si scheduler_pending_pods reste élevé pendant plus de 5 minutes, enquêtez sur les pods non planifiables.

Modes de défaillance et reprise

Les défaillances du scheduler peuvent se manifester par des pods non planifiés, un placement incorrect ou des boucles de crash du scheduler. Cette section décrit les modes de défaillance courants et les étapes de reprise.

Mode de défaillance 1 : boucle de crash du pod du scheduler

Symptôme : kubectl get pods -n kube-system -l component=kube-scheduler affiche CrashLoopBackOff.

Diagnostic :

kubectl logs -n kube-system kube-scheduler-minikube --previous

Causes courantes :

• Fichier de configuration avec syntaxe invalide.
• Binaire du plugin introuvable ou incompatibilité de version.
• Permissions RBAC manquantes.

Reprise :

• Restaurez la dernière configuration connue comme bonne depuis la sauvegarde.
• Si un plugin personnalisé cause le crash, retirez-le de la configuration ou corrigez le binaire du plugin.
• Redémarrez le pod du scheduler : kubectl delete pod -n kube-system kube-scheduler-minikube (si pod statique, il sera recréé).

Mode de défaillance 2 : pods bloqués en Pending

Symptôme : un pod reste Pending sans nœud assigné.

Diagnostic :

kubectl describe pod <pod-name> | grep -A 10 Events

Recherchez des raisons comme FailedScheduling. Remèdes courants :

• Augmentez la capacité du cluster ou réduisez les demandes de ressources du pod.
• Ajoutez des étiquettes de nœuds ou ajustez le nodeSelector.
• Ajoutez des tolérances pour les taints.
• Vérifiez si le pod utilise un nom de scheduler inexistant : spec.schedulerName doit correspondre à un scheduler disponible.

Mode de défaillance 3 : décisions de planification incorrectes

Symptôme : les pods sont planifiés sur des nœuds mais le placement ne correspond pas aux attentes (par exemple, charge de travail sur des nœuds non SSD malgré le plugin).

Diagnostic :

• Vérifiez que le plugin est activé dans la configuration du scheduler.
• Consultez les journaux du scheduler pour les détails de scoring (avec verbosité).
• Confirmez que les étiquettes des nœuds sont correctes : kubectl get nodes --show-labels.
• Assurez-vous que les demandes de ressources du pod sont dans les limites de capacité du nœud.

Reprise :

• Ajustez les poids ou la configuration du plugin.
• Si nécessaire, évacuez le pod (kubectl delete pod) et laissez-le se replanifier avec la configuration corrigée.

Mode de défaillance 4 : scheduler indisponible (perte d'élection de leader)

Symptôme : aucun leader de scheduler ou plusieurs leaders causant une planification incohérente.

Diagnostic :

• Vérifiez les endpoints comme mentionné précédemment.
• Vérifiez une partition réseau ou une charge élevée sur le plan de contrôle.

Reprise :

• Assurez-vous que tous les réplicas du scheduler ont une configuration cohérente et peuvent communiquer avec l'API server.
• Si un split-brain est suspecté, redémarrez les pods du scheduler un par un.

Étapes générales de reprise

1. Identifiez la défaillance : utilisez kubectl get pods, describe, logs.
2. Isolez le rayon d'impact : arrêtez la nouvelle planification en définissant pause: true dans la configuration du scheduler (si supporté) ou en cordonnant les nœuds.
3. Retour en arrière de la configuration : restaurez la ConfigMap ou le fichier précédent, redémarrez le scheduler.
4. Vérifiez la reprise : observez les journaux du scheduler et la planification des pods.
5. Documentez l'incident et mettez à jour le runbook.

Liste de vérification des opérations

Cette liste de vérification consolide les contrôles et actions de routine pour l'exploitation du framework de planification Kubernetes en production. Utilisez-la comme référence pour les revues quotidiennes, hebdomadaires et mensuelles.

Contrôles quotidiens

• [ ] Vérifier que les pods du scheduler tournent : kubectl get pods -n kube-system -l component=kube-scheduler
• [ ] Vérifier les pods en état Pending : kubectl get pods --all-namespaces --field-selector=status.phase=Pending
• [ ] Examiner les journaux du scheduler pour les erreurs (dernières lignes)
• [ ] Surveiller les métriques du scheduler pour les anomalies (si Prometheus est utilisé)

Contrôles hebdomadaires

• [ ] Valider la configuration du scheduler par rapport à la documentation de version (s'assurer qu'aucune version d'API obsolète n'est utilisée)
• [ ] Examiner la capacité des nœuds et les demandes de ressources par rapport aux ressources allouables pour anticiper la pression de planification
• [ ] Vérifier les mises à jour ou les correctifs nécessaires pour les plugins de planification personnalisés
• [ ] S'assurer qu'une sauvegarde de la configuration du scheduler existe et est à jour

Contrôles mensuels

• [ ] Effectuer un test de bascule : tuer le pod du scheduler et vérifier qu'un nouveau leader est élu (si HA) et que la planification continue
• [ ] Revoir et mettre à jour la liste des plugins du scheduler en fonction des changements de charge de travail
• [ ] Auditer les permissions RBAC liées au scheduler pour le principe du moindre privilège
• [ ] Exécuter une planification de capacité : simuler une charge accrue et vérifier si le scheduler peut suivre (considérer les limites de débit du scheduler)

Liste de vérification pour la gestion des changements

Avant tout changement du scheduler :

• [ ] Comprendre l'objectif et l'impact : quelles charges de travail, nœuds, plugins sont affectés ?
• [ ] Examiner le schéma de configuration et la version d'API supportée pour votre version de Kubernetes
• [ ] Tester le changement dans un cluster non productif avec des plugins de scheduler identiques
• [ ] Préparer le plan de retour en arrière : prendre un instantané de la configuration actuelle, savoir comment restaurer
• [ ] Annoncer la fenêtre de changement et le comportement attendu
• [ ] Appliquer le changement progressivement (si plusieurs schedulers sont utilisés, migrer les charges de travail graduellement)
• [ ] Surveiller la santé du scheduler et la planification des pods pendant et après le changement
• [ ] Documenter le changement et tout effet secondaire observé

Référence de runbook d'urgence

Conclusion

Exploiter le framework de planification Kubernetes en production exige une approche disciplinée : inventorier votre environnement, modifier la configuration par des chemins sûrs, vérifier avec des diagnostics et récupérer après défaillance à l'aide de runbooks prédéfinis. Cette liste de vérification fournit une base, mais vous devez l'adapter aux spécificités de votre cluster, y compris les plugins personnalisés et les politiques organisationnelles.

N'oubliez pas que la planification est une fonction critique du plan de contrôle ; les erreurs peuvent perturber toutes les charges de travail. Par conséquent, observez toujours avant de changer, gardez les modifications limitées et réversibles, et maintenez l'observabilité via les journaux et les métriques. Au fur et à mesure que vous gagnez de l'expérience, étendez cette liste de vérification avec vos propres apprentissages et intégrez-la dans vos runbooks opérationnels.

Pour approfondir, consultez la documentation officielle de Kubernetes sur le framework de planification, la configuration du kube-scheduler et le développement de plugins. Révisez continuellement les notes de version pour les changements du scheduler lors des mises à niveau de cluster.