Bank 4 – Mise en ordre (Partie 1 : Fondations)¶

Instructions

Remettez les étapes dans le bon ordre chronologique ou logique.
Cliquez sur « Correction » pour vérifier.

Total : 10 exercices (2 faciles · 4 moyens · 4 difficiles)

Niveau Facile¶

Exercice 1 : Le cycle de vie d'un déploiement applicatif simple¶

Consigne : Remettez les étapes suivantes dans l'ordre logique pour déployer et exposer une application simple.

[A] Créer un fichier manifeste YAML décrivant l'objet Deployment de l'application.
[B] Exécuter la commande kubectl apply -f service.yaml pour rendre l'application accessible via un Service.
[C] Installer ou initialiser le cluster k3s et s'assurer que le fichier de configuration ~/.kube/config est actif.
[D] Appliquer le déploiement sur le cluster à l'aide de la commande kubectl apply -f deployment.yaml.

Correction

C → A → D → B
On prépare d'abord le cluster, puis on rédige le manifeste de déploiement, on l'applique, et enfin on crée et applique le service réseau pour l'exposer.

Exercice 2 : Consultation de l'état d'un pod en erreur¶

Consigne : Ordonnisez les étapes qu'un administrateur doit suivre pour diagnostiquer un pod qui ne parvient pas à démarrer.

[A] Consulter les journaux applicatifs du conteneur défaillant avec kubectl logs <nom-pod>.
[B] Lister les pods du namespace courant avec kubectl get pods pour identifier celui en état d'échec (CrashLoopBackOff ou autre).
[C] Analyser les événements système et la configuration détaillée du pod à l'aide de la commande kubectl describe pod <nom-pod>.
[D] Corriger le manifeste YAML source et réappliquer la ressource corrigée.

Correction

B → C → A → D
On commence par lister les pods pour repérer l'anomalie, puis on utilise describe pour voir les événements récents, on lit les logs du conteneur pour identifier l'erreur exacte, et enfin on corrige le code.

Niveau Moyen¶

Exercice 3 : Le déroulement d'une mise à jour progressive (Rolling Update)¶

Consigne : Remettez dans l'ordre chronologique les étapes internes exécutées par Kubernetes lors d'un RollingUpdate d'un Deployment.

[A] Le contrôleur crée de nouveaux pods basés sur la nouvelle version du modèle (spec.template).
[B] Les anciens pods sont progressivement supprimés au fur et à mesure que les nouveaux pods deviennent sains, en respectant les paramètres maxSurge et maxUnavailable.
[C] L'utilisateur modifie la version de l'image conteneur dans le manifeste YAML du Deployment et applique la modification.
[D] Les nouveaux pods passent leurs sondes de préparation (readinessProbe) avec succès et sont ajoutés aux endpoints du Service.

Correction

C → A → D → B
La modification initie le processus, le contrôleur génère les nouveaux pods, ceux-ci deviennent prêts via leurs sondes, et les anciens pods sont éliminés de manière fluide.

Exercice 4 : Le flux de résolution de nom DNS d'un Service interne¶

Consigne : Ordonnez les étapes de la résolution d'une requête réseau interne par un pod cherchant à joindre un service.

[A] Le serveur CoreDNS intercepte la requête DNS et cherche l'enregistrement correspondant au nom canonique du service.
[B] L'application du pod émet une requête de résolution de nom vers le serveur DNS du cluster (ex: mon-service.mon-namespace.svc.cluster.local).
[C] CoreDNS renvoie l'adresse IP virtuelle (ClusterIP) du service (ou les adresses IP directes s'il s'agit d'un service Headless).
[D] Le trafic réseau de la requête est acheminé vers le pod cible via l'interception du kube-proxy.

Correction

B → A → C → D
Le pod initie la requête textuelle, CoreDNS la traduit en IP de cluster, puis le réseau s'occupe de relayer le paquet vers l'application ciblée.

Exercice 5 : Le processus de planification (Scheduling) d'un nouveau Pod¶

Consigne : Remettez dans l'ordre les étapes de placement d'un pod nouvellement créé sur un nœud du cluster.

[A] L'API Server enregistre le nouveau Pod dans la base de données de stockage avec l'état non planifié (nodeName: "").
[B] Le planificateur (kube-scheduler) sélectionne le nœud optimal en fonction des contraintes, affinités et ressources disponibles.
[C] L'agent kubelet du nœud choisi détecte l'affectation, récupère les instructions et lance la création des conteneurs via le runtime.
[D] Le planificateur écrit le nom du nœud choisi dans l'objet Pod via l'API Server (opération de binding).

Correction

A → B → D → C
Le pod est créé sans nœud, le scheduler l'évalue et choisit la meilleure machine, inscrit son choix dans l'API, et le kubelet du nœud destinataire exécute l'ordre.

Exercice 6 : Le cycle de vie d'un Job Kubernetes¶

Consigne : Ordonnez les étapes d'exécution d'un objet Job destiné à effectuer une tâche de calcul ponctuelle.

[A] Le pod associé au job démarre et exécute le script ou le binaire applicatif prévu.
[B] L'utilisateur soumet le manifeste YAML définissant un objet de type Job.
[C] Le pod s'arrête avec un code de sortie valant zéro (Exit 0), indiquant le succès de la tâche.
[D] Le job passe à l'état complété (Completed) et conserve le pod terminé dans l'historique selon la politique de rétention.

Correction

B → A → C → D
Le job est créé, le conteneur exécute son travail, s'arrête proprement une fois terminé, et le contrôleur enregistre le succès de l'exécution.

Niveau Difficile¶

Exercice 7 : Le pipeline interne de traitement d'une requête par l'API Server¶

Consigne : Remettez dans l'ordre les couches traversées par une requête kubectl entrante au sein de l'API Server.

[A] Validation et mutation des données via les contrôleurs d'admission (Admission Controllers).
[B] Authentification de l'utilisateur ou du compte de service émetteur de la requête.
[C] Évaluation des autorisations via le système RBAC pour vérifier si l'entité a le droit d'effectuer l'action.
[D] Enregistrement et persistance définitive de la ressource modifiée dans la base de données backend (etcd ou SQLite/kine).

Correction

B → C → A → D
L'API Server commence par identifier qui agit (Authentification), vérifie ce qu'il a le droit de faire (Autorisation RBAC), ajuste ou valide le manifeste via les plugins d'admission, et enfin stocke l'objet.

Exercice 8 : La séquence d'initialisation et de démarrage d'un nœud k3s¶

Consigne : Ordonnez les étapes chronologiques du lancement d'un nœud maître k3s.

[A] Le binaire unique k3s démarre et initialise ses sous-composants intégrés (API server, controller manager, scheduler, kine/SQLite).
[B] L'agent interne s'initialise et lance le démon kubelet ainsi que le proxy réseau.
[C] Le système de fichiers et les interfaces réseau de base (bridge/CNI Flannel) sont configurés sur le système d'exploitation hôte.
[D] Le cluster est prêt à recevoir des requêtes et les conteneurs système (CoreDNS, Traefik) se déploient.

Correction

C → A → B → D
Le système hôte prépare le terrain, k3s lance son control-plane monobloc, puis l'agent s'active avec le CNI, permettant le déploiement des composants additionnels.

Exercice 9 : La configuration et l'application d'une règle CNI réseau pour un nouveau Pod¶

Consigne : Remettez dans l'ordre les actions réalisées par le système réseau lors de la création d'un pod.

[A] Le kubelet invoque le plugin CNI configuré (ex. Flannel) lors de la création du sandbox réseau du pod.
[B] Le plugin CNI alloue une adresse IP unique au pod depuis le sous-réseau du nœud.
[C] Le plugin configure les interfaces virtuelles (veth pair) et les règles de routage/tables du noyau pour permettre la communication.
[D] Le conteneur de l'application démarre et peut communiquer à travers l'interface réseau ainsi établie.

Correction

A → B → C → D
Le kubelet appelle le CNI, qui attribue l'IP, configure les interfaces de pont et les règles de routage, avant que le conteneur ne démarre avec son réseau opérationnel.

Exercice 10 : Le processus de restauration (Rollback) d'un déploiement défectueux¶

Consigne : Ordonnez les étapes d'exécution d'un retour en arrière (rollout undo) suite à une erreur applicative.

[A] L'utilisateur exécute la commande kubectl rollout undo deployment <nom>.
[B] L'API Server met à jour le Deployment en restaurant le modèle de pod (spec.template) issu de la révision précédente stockée dans le ReplicaSet historique.
[C] Le contrôleur de déploiement exécute une mise à jour progressive (rolling update) en basculant le trafic vers l'ancienne version stable.
[D] L'historique des révisions est mis à jour pour refléter l'annulation de la modification.

Correction

A → B → D → C
L'utilisateur déclenche l'ordre, l'API applique le template de la révision antérieure, l'historique s'actualise, et le contrôleur effectue le remplacement progressif des pods.