Quiz : Kubernetes, les fondamentaux

Le contrôleur de ReplicaSet constate que le nombre de pods observé (1) diffère de l'état voulu (2) et en crée un ; l'ordonnanceur le place sur un autre nœud. C'est la réconciliation : une panne n'est qu'un écart de plus entre l'état voulu et l'état observé. Leçons 1 et 5.

Pas nécessairement : apply réussit dès que l'objet est enregistré dans etcd par le serveur d'API. Les contrôleurs, l'ordonnanceur et le kubelet font le reste ensuite, et leurs échecs (image introuvable, sonde qui échoue) se lisent dans les statuts et les événements. kubectl rollout status attend la fin réelle. Leçons 2 et 5.

etcd s'accorde par Raft et exige une majorité pour écrire. Avec 3 membres, on survit à la perte d'un ; avec 4, la majorité est 3 et l'on ne survit toujours qu'à la perte d'un : le quatrième ajoute du coût sans ajouter de tolérance. Leçon 2.

Des clusters (adresse, autorité de certification), des utilisateurs (identifiants) et des contextes qui associent un cluster, un utilisateur et un namespace. Celui de kind contient un certificat d'administrateur : quiconque le possède a tous les droits sur le cluster. Leçon 3.

Si la base tombe, toutes les sondes de vie échouent, et le kubelet redémarre tous les pods en boucle, sans rien réparer et en ajoutant de la charge au moment du rétablissement. /sante sert de sonde de disponibilité : un pod sans base est retiré du trafic, pas redémarré. La sonde de vie ne teste que le processus lui-même. Leçon 4.

CrashLoopBackOff est un symptôme : le conteneur s'arrête et le kubelet attend de plus en plus longtemps avant de le relancer (jusqu'à 5 minutes). La cause est dans kubectl logs --previous (les journaux de l'exécution précédente) et dans kubectl describe pod (code de sortie, OOMKilled, événements). Leçons 4 et 12.

La sonde de disponibilité : un nouveau pod n'est ajouté aux points de terminaison du Service, et compté comme disponible pour passer à la vague suivante, qu'une fois prêt. Si la nouvelle version n'est jamais prête, le déploiement s'arrête avec les anciens pods encore en service, puis progressDeadlineSeconds le signale. Leçon 5.

Quand un pod s'arrête, le retrait des points de terminaison et l'envoi de SIGTERM se font en parallèle. Pendant quelques instants, kube-proxy et le contrôleur d'entrée peuvent encore envoyer des requêtes vers un processus qui s'arrête. L'attente du preStop laisse la propagation se faire avant que l'application ne refuse les connexions. Leçons 4 et 5.

L'API le refuse : le sélecteur d'un Deployment est immuable. Il faut créer un nouveau Deployment, d'où l'intérêt de ne mettre dans le sélecteur que des étiquettes stables (le nom de l'application et son composant, jamais la version). Leçon 5.

Un sélecteur qui ne correspond aux étiquettes d'aucun pod (faute de frappe, générateur qui a mis app: <nom>), ou des pods qui existent mais ne sont pas prêts (sonde de disponibilité en échec). Ce n'est presque jamais un problème de réseau. kubectl get endpointslices -l kubernetes.io/service-name=<service> le montre. Leçons 6 et 12.

L'adresse du Service est virtuelle : aucune interface ne la porte. kube-proxy programme dans chaque nœud une traduction d'adresse de destination pour les ports du Service, en TCP ou UDP ; un paquet ICMP n'est pas traduit et ne trouve personne. Leçon 6.

Pas le base64, qui n'est qu'un encodage. Ce qui le protège : le chiffrement au repos dans etcd, le RBAC (qui peut lire les Secrets), le cloisonnement par namespace (toute personne qui peut créer un pod dans le namespace peut monter ses Secrets), et en amont un gestionnaire de secrets plutôt que des Secrets commités. Leçon 7.

Non : les variables d'environnement sont lues au démarrage du conteneur. Seuls les fichiers montés depuis la ConfigMap sont mis à jour, après un délai. Il faut recréer les pods (kubectl rollout restart deployment/signalements) ou utiliser des ConfigMaps immuables à nom versionné. Leçon 7.

L'ordonnanceur ne regarde que les requests : il place le pod sur un nœud dont la capacité allouable non réservée les couvre. Le noyau applique les limits par les cgroups : au-delà de la limite de processeur, le conteneur est étranglé ; au-delà de la limite de mémoire, il est tué (OOMKilled, code 137). Leçon 8.

BestEffort : il ne réserve rien, et il est le premier évincé ou tué quand le nœud manque de mémoire. Une request de mémoire est une assurance. Leçon 8.

C'est un volume bloc zonal, en accès RWO (ou RWOP). Avec WaitForFirstConsumer, il est créé dans la zone du premier pod qui l'utilise ; ensuite, le pod qui le monte ne peut être placé que dans cette zone, et un seul nœud à la fois peut l'attacher. Leçon 9.

Au démarrage de chaque pod, plusieurs répliques lanceraient la migration en même temps, une mise à l'échelle la relancerait, et un échec ferait boucler tous les pods. Un Job l'exécute une fois, jusqu'à son succès, avec une politique de réessai, et le déploiement de l'application peut attendre sa fin. Leçon 10.

Une identité stable par pod (numéro, nom DNS par un Service headless) et un volume stable par pod (volumeClaimTemplates), avec des créations et mises à jour ordonnées. Il ne réplique pas les données, ne les sauvegarde pas et ne gère pas la bascule : c'est le travail de la base elle-même, d'un opérateur, ou d'un service managé. Leçon 10.

L'API Ingress est gelée et le projet ingress-nginx n'est plus maintenu depuis mars 2026. Gateway API est l'API d'exposition qui évolue : elle sépare la classe (GatewayClass), le point d'entrée (Gateway) et les routes (HTTPRoute) selon les rôles, et Traefik, utilisé par Lyneko, l'implémente. Leçon 11.

Des requests qu'aucun nœud ne peut satisfaire, un PVC non lié, des teintes sans tolérance, une affinité ou une contrainte de répartition impossible. L'événement FailedScheduling de kubectl describe pod explique combien de nœuds ont été écartés et pourquoi. Leçon 12.