Kubernetes

K8s, du grec « timonier » : orchestrateur de conteneurs

Décrire le résultat, pas les gestes

On ne lui dit pas « démarre ce programme sur telle machine ». On lui écrit ce que l’on veut obtenir : trois exemplaires du conteneur de paiement, deux de celui du site, joignables à telle adresse. Il compare sans cesse ce qui tourne à ce qui est demandé, et corrige l’écart de lui-même, sans qu’un administrateur ait à intervenir.

Ce qu’il apporte réellement

Trois choses qui se voient à l’usage : une panne matérielle ne coupe plus le service, puisque la brique perdue est relancée ailleurs en quelques secondes ; une montée de charge s’absorbe en ajoutant des exemplaires plutôt qu’en changeant de serveur ; et une nouvelle version se déploie brique par brique, sans fenêtre d’interruption annoncée aux utilisateurs. C’est ce qui l’a rendu incontournable dans les architectures distribuées.

Une machinerie qui vit sa vie

La contrepartie est que les services y naissent et disparaissent sans intervention humaine, par dizaines, parfois par centaines. Ce qui est lancé pour un essai peut continuer de tourner des mois plus tard, avec ses accès et son code d’origine, sans figurer dans le moindre schéma. L’inventaire ne dérive pas par négligence : il dérive parce que le système est fait pour créer tout seul.

Ce que l’on peut demander à qui l’exploite

La liste de ce qui tourne aujourd’hui dans le cluster, avec pour chaque service le responsable, la version et la date prévue de son retrait. Cette liste existe techniquement — l’orchestrateur la connaît en permanence, c’est même son métier. La produire est l’affaire d’une commande ; la relire et la nettoyer est une décision de direction.

Mise à jour : 27 septembre 2026