Opérer Kubernetes, ce n’est pas seulement déployer des manifests. C’est savoir observer un cluster, qualifier un incident, intervenir sans casser la production, puis améliorer progressivement la fiabilité. Ce parcours regroupe 23 guides organisés en 6 blocs : observation, diagnostic, maintenance, stabilité, exploitation et décisions d’architecture.
Chaque guide suit la même logique : comprendre le problème, appliquer une méthode, vérifier le résultat.
Ce que ce parcours couvre
Section intitulée « Ce que ce parcours couvre »- Observer : vérifier l’état du cluster, lire les métriques, centraliser les logs, analyser les événements, détecter les problèmes nœud
- Diagnostiquer : méthode reproductible, résolution des erreurs courantes (CrashLoopBackOff, Pending, ImagePullBackOff, réseau)
- Maintenir : cordon/drain, gestion des nœuds, mises à jour, sauvegardes
- Stabiliser : requests/limits en production, pression des nœuds, PDB, autoscaling
- Industrialiser : runbooks, SLO/SLI, tâches quotidiennes
- Décider : quand un cluster devient complexe, mono vs multi-cluster
Prérequis
Section intitulée « Prérequis »- Un cluster Kubernetes fonctionnel (v1.28+)
kubectlconfiguré et connecté- Connaissances de base sur les Pods, les Deployments et les Services
- Avoir suivi le parcours Kubernetes fondamentaux ou équivalent
Bloc 1 — Observer et superviser
Section intitulée « Bloc 1 — Observer et superviser »Objectif : rendre l’état du cluster visible et interprétable, avant l’incident.
Mettre en place les métriques Kubernetes
Configurer metrics-server, Prometheus et Grafana pour le monitoring du cluster.
Centraliser les logs Kubernetes
Collecter et exploiter les logs des pods, nœuds et composants du plan de contrôle.
Surveiller la santé des nœuds avec Node Problem Detector
Remonter les problèmes matériels et système des nœuds sous forme de Conditions et Events.
Bloc 2 — Diagnostiquer les incidents
Section intitulée « Bloc 2 — Diagnostiquer les incidents »Objectif : une méthode claire pour chaque type d’incident — qualifier, isoler, confirmer, corriger.
En exploitation, on commence toujours par qualifier le symptôme au niveau cluster, puis nœud, puis pod, puis réseau. Cette approche du plus global au plus local évite de perdre du temps sur un faux diagnostic.
Résoudre un Pod Pending
Scheduling, resources insuffisantes, affinité, taints — trouver pourquoi un pod ne démarre pas.
Résoudre un ImagePullBackOff
Registre inaccessible, tag introuvable, credentials manquants — diagnostiquer les erreurs de pull.
Diagnostiquer un problème réseau applicatif
Bloc 3 — Maintenir le cluster
Section intitulée « Bloc 3 — Maintenir le cluster »Objectif : intervenir sur un cluster sans casser la disponibilité. Chaque opération de maintenance est une disruption volontaire — cordon, drain, upgrade, remplacement de nœud. Les PodDisruptionBudgets garantissent que ces interventions respectent les contraintes de disponibilité de vos applications.
Gérer les nœuds au quotidien
Ajouter, retirer, labéliser et surveiller les nœuds d’un cluster en production.
Mettre à jour un cluster Kubernetes
Stratégie d’upgrade, ordre des composants, rollback — mise à jour sans interruption.
Sauvegarder un cluster Kubernetes
Backup etcd, ressources critiques, Velero — protéger le cluster contre la perte de données.
Bloc 4 — Stabilité et capacité
Section intitulée « Bloc 4 — Stabilité et capacité »Objectif : passer du dépannage à la prévention — stabiliser la plateforme et anticiper les dégradations de service.
Requests et Limits en production
Impact concret des requests/limits sur le scheduling, la stabilité et les coûts.
Pression des nœuds et éviction
Comprendre les seuils d’éviction du kubelet et anticiper la saturation.
Disponibilité applicative
PodDisruptionBudget, anti-affinité, probes — garantir la continuité de service.
Autoscaling en production
Bloc 5 — Industrialiser l’exploitation
Section intitulée « Bloc 5 — Industrialiser l’exploitation »Objectif : passer de l’administration ponctuelle à l’exploitation structurée — avec des rituels, des indicateurs et des procédures documentées.
Runbooks Kubernetes
Procédures opérationnelles documentées pour les incidents récurrents.
SLO et SLI pour Kubernetes
Définir et mesurer des indicateurs de fiabilité pour vos services.
Tâches quotidiennes de l'admin Kubernetes
Routine d’exploitation : vérifications, nettoyage, revue des alertes.
Bloc 6 — Décisions d’architecture
Section intitulée « Bloc 6 — Décisions d’architecture »Objectif : aider à prendre les bonnes décisions d’architecture et d’exploitation.
Quand un cluster Kubernetes devient complexe
Les signaux qui indiquent qu’il est temps de repenser l’architecture.
Un ou plusieurs clusters Kubernetes ?
Critères de décision : isolation, coût, complexité, conformité.
Parcours recommandé
Section intitulée « Parcours recommandé »-
Commencez par observer : le guide Observer la santé du cluster vous donne les 5 commandes essentielles pour vérifier l’état de votre cluster. C’est le point de départ de toute exploitation.
-
Apprenez à diagnostiquer : la méthode de diagnostic vous donne une approche systématique. Appliquez-la ensuite sur les cas concrets (CrashLoopBackOff, Pending, réseau).
-
Préparez vos interventions : avant toute maintenance, suivez le guide Préparer une maintenance pour éviter les interruptions de service.
-
Stabilisez la plateforme : requests/limits, PDB, autoscaling — les guides du bloc Stabilité vous aident à prévenir les incidents plutôt qu’à les subir.
-
Structurez l’exploitation : runbooks, SLO/SLI et routine quotidienne transforment l’administration ponctuelle en exploitation professionnelle.
Maillage avec les autres parcours
Section intitulée « Maillage avec les autres parcours »Les guides « Opérer » complètent les parcours existants :
| Guide Opérer | Parcours lié | Type de lien |
|---|---|---|
| Observer la santé | Troubleshooting CKA | Complémentaire |
| CrashLoopBackOff | Troubleshooting CKA | Approfondissement |
| Préparer maintenance | kubeadm, Worker Nodes | Complémentaire |
| Requests/Limits prod | Requests et Limits | Angle production |
| Réseau applicatif | Network Policies, CoreDNS | Complémentaire |
À retenir
Section intitulée « À retenir »- Observer avant d’agir : la majorité des incidents sont détectables avec 5 commandes kubectl avant qu’ils ne deviennent critiques
- Une méthode reproductible vaut mieux que 10 astuces isolées — qualifier, isoler, confirmer, corriger
- Chaque maintenance doit être préparée : cordon, drain, vérification des PDB, puis uncordon
- La fiabilité se construit : requests/limits correctes, PDB en place, autoscaling configuré
- L’exploitation structurée (runbooks, SLO/SLI, routine) réduit le stress et le temps de résolution