Aller au contenu

Bank 8 – Études de cas (Partie 1 : Fondations)

Instructions

Analysez la mise en situation et répondez aux consignes.
Cliquez sur « Corrigé & Barème » pour comparer.

Total : 5 cas (2 intermédiaires · 3 difficiles)

Niveau Intermédiaire

Cas 1.3 : Gestion des pics de charge et dimensionnement automatique (HPA)

Mise en situation :
L'application web ticket-store subit des pics de fréquentation imprévisibles lors des ouvertures de billetterie. L'équipe souhaite automatiser le dimensionnement des réplicas en fonction de l'utilisation du processeur, tout en garantissant un nombre minimal de 3 pods et un plafond de 15 pods.

Consignes :

  1. Identifiez le composant prérequis devant être actif sur le cluster pour permettre le fonctionnement de l'Auto-scaler (HorizontalPodAutoscaler).
  2. Rédigez le manifeste YAML de l'objet HorizontalPodAutoscaler ciblant le déploiement ticket-store avec un seuil cible d'utilisation CPU fixé à 70 %.
  3. Indiquez la section indispensable devant figurer dans la définition des conteneurs du Deployment pour que l'HPA puisse calculer l'utilisation relative des ressources.

??? success "Corrigé & Barème" - Composant prérequis (1 pt) : Le service Metrics Server doit être installé et opérationnel sur le cluster (installé par défaut dans k3s) pour collecter les métriques cpu et memory. - Manifeste YAML HPA (2 pts) : yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ticket-store-hpa namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ticket-store minReplicas: 3 maxReplicas: 15 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - Exigence au niveau du Deployment (2 pts) : Chaque conteneur doit obligatoirement définir la section resources.requests.cpu. Sans la déclaration explicite des requêtes (requests), l'HPA ne peut pas calculer le pourcentage d'utilisation et reste à l'état <unknown>.

Cas 1.4 : Ingress Traefik et gestion du routage par sous-domaine

Mise en situation :
Dans un cluster k3s utilisant le contrôleur d'Ingress par défaut (Traefik), vous devez exposer deux microservices : api-service (port 8080) et web-ui (port 80). Le trafic arrivant sur api.entreprise.local doit être dirigé vers api-service, tandis que le trafic sur app.entreprise.local doit cibler web-ui.

Consignes :

  1. Écrivez le manifeste YAML de la ressource Ingress gérant ces deux règles de routage.
  2. Expliquez quelle configuration locale sur le poste client ou le réseau entreprise est nécessaire pour tester la résolution de ces deux noms de domaine pointant vers l'IP du nœud k3s.

??? success "Corrigé & Barème" - Manifeste Ingress (3 pts) : yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress namespace: default spec: rules: - host: api.entreprise.local http: paths: - path: / pathType: Prefix backend: service: name: api-service port: number: 8080 - host: app.entreprise.local http: paths: - path: / pathType: Prefix backend: service: name: web-ui port: number: 80 - Résolution DNS locale (2 pts) : Il faut ajouter des entrées dans le fichier /etc/hosts (ou équivalent Windows) sur la machine de test pour mapper les deux FQDN vers l'IP de la machine hôte k3s (ex. <IP_NOEUD_K3S> api.entreprise.local app.entreprise.local), ou configurer une redirection DNS wildcard/locale.

Niveau Difficile

Cas 1.5 : Panne réseau inter-nœuds et partitionnement du cluster

Mise en situation :
Dans un cluster k3s multi-nœuds (1 Control Plane + 3 Workers), la liaison réseau physique entre le Worker 3 et le reste du réseau est subitement coupée. Les applications clientes subissent des lenteurs et des alertes se déclenchent.

Consignes :

  1. Décrivez la séquence chronologique d'actions exécutées par le Control Plane (kube-controller-manager) vis-à-vis du nœud Worker 3 déconnecté (délais, statuts NodeCondition).
  2. Expliquez ce qui arrive aux Pods gérés par un Deployment situés sur ce nœud impacté, versus des Pods gérés par un StatefulSet.
  3. Quelle commande permet d'accélérer ou de forcer le nettoyage du nœud si le matériel est définitivement perdu, et quel est le risque majeur pour un StatefulSet ?

??? success "Corrigé & Barème" - Séquence du Control Plane (2 pts) : - Le kubelet du Worker 3 cesse d'envoyer ses pings de santé (nodeStatusUpdateFrequency). - Après environ 40 secondes, le statut du nœud passe à NotReady ou Unknown. - Après l'expiration du délai de grâce des pods (pod-eviction-timeout, par défaut 5 minutes), le controller-manager marque les pods du nœud pour suppression (Terminating). - Différence Deployment vs StatefulSet (2 pts) : - Deployment : Le contrôleur crée immédiatement de nouveaux pods de remplacement sur les travailleurs sains restants pour restaurer le nombre de réplicas. - StatefulSet : Le contrôleur ne recréera PAS automatiquement les pods tant qu'il n'a pas la garantie absolue que les anciens pods sont arrêtés, pour éviter que deux instances avec le même nom d'index et le même stockage persistant ne fonctionnent en même temps (risque de corruption de données / Split-Brain). - Suppression forcée et risque (1 pt) : On peut exécuter kubectl delete pod <pod-name> --force --grace-period=0. Le risque majeur est la corruption irréversible des données si l'ancien pod était toujours actif et écrivait sur le volume persistant.

Cas 1.6 : Refactorisation d'une application monolithique vers une architecture tolérante aux pannes

Mise en situation :
Une application critique en mono-instance subit des interruptions à chaque maintenance de nœud k3s. Vous êtes chargé de re-concevoir son déploiement pour garantir une disponibilité maximale (HA) sur un cluster à 3 nœuds.

Consignes :

  1. Proposez une configuration basée sur le découpage en 3 réplicas avec une règle de répartition stricte empêchant deux réplicas de s'exécuter sur la même machine physique (podAntiAffinity).
  2. Associez-y la définition d'un budget de disponibilité (PodDisruptionBudget) garantissant qu'au moins 2 réplicas restent actifs en permanence lors des opérations de maintenance (kubectl drain).
  3. Rédigez le fragment de manifeste YAML pour le PodDisruptionBudget.

??? success "Corrigé & Barème" - Stratégie PodAntiAffinity (2 pts) : Configurer spec.template.spec.affinity.podAntiAffinity en mode requiredDuringSchedulingIgnoredDuringExecution en ciblant la clé de topologie kubernetes.io/hostname et les étiquettes de l'application. - Rôle du PodDisruptionBudget (1.5 pt) : Le PDB bloque l'éviction de pods demandée par un kubectl drain si le nombre de pods sains tombe en dessous du seuil configuré, forçant l'administrateur à attendre que les réplicas de remplacement soient opérationnels. - Manifeste YAML du PDB (1.5 pt) : yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: app-pdb namespace: default spec: minAvailable: 2 selector: matchLabels: app: critical-app

Cas 1.7 : Analyse de saturation et blocage d'ordonnancement (Pending)

Mise en situation :
Après avoir appliqué un nouveau manifeste YAML pour le déploiement analytics-worker (10 réplicas demandés), vous constatez que 4 pods restent bloqués indéfiniment à l'état Pending. La commande kubectl get nodes indique que tous les nœuds sont bien au statut Ready.

Consignes :

  1. Indiquez la commande exacte pour analyser le motif du blocage retenu par le kube-scheduler.
  2. Si le message d'événement indique 0/3 nodes are available: 3 Insufficient memory, explicitez la différence entre l'utilisation mémoire réelle de l'hôte (free -m) et la réservation par Kubernetes (requests).
  3. Proposez 2 solutions techniques d'ingénierie pour résoudre le problème sans ajouter immédiatement de nouveau matériel physique.

??? success "Corrigé & Barème" - Commande d'analyse (1 pt) : kubectl describe pod <nom-du-pod-pending> et analyser la section finale Events. - Explication Requests vs Utilisation réelle (2 pts) : Le planificateur (scheduler) se base uniquement sur la somme des requêtes de ressources (resources.requests.memory) déclarées dans les manifestes, et non sur la consommation RAM réelle instantanée. Même si de la RAM physique est libre, si la somme des requests égale la capacité réservable du nœud, le scheduler refuse d'y placer de nouveaux pods. - Pistes de résolution (2 pts) : - Ajuster à la baisse le paramètre resources.requests.memory du conteneur en se basant sur les métriques de consommation réelle. - Ajuster le nombre de réplicas du déploiement (kubectl scale) ou réduire les réplicas d'autres applications sous-utilisées du cluster.