Tout le monde dit faire du GitOps. De l’infra as code. Des déploiements immutables. Du bétail, pas des animaux de compagnie

Et puis y a un incident et quelqu’un SSH sur un node pour “checker un truc vite fait”

Le check rapide devient un fix à la main. Ça marche. Personne documente. Trois mois après on remplace le node et le problème revient. Ça te parle?

Talos Linux fait autrement: pas de SSH, pas de shell, pas de package manager. Impossible de tricher, même si t’en as envie

L’illusion du “c’est plus rapide”

SSH ça a l’air rapide. Tu te co, tu mates les logs, tu touches à une config, tu sors. Cinq minutes et c’est plié

Sauf que non. T’as rien résolu, t’as planqué le problème

En vrai ça donne ça:

• 5 min pour SSH et bricoler
• 30 min pour te rappeler ce que t’as touché
• 2h pour documenter comme il faut (spoiler: tu le feras pas)
• 0 min pour mettre à jour ton automation (parce que “c’est juste ce node-là”)

Le fix reste sur ce node. Ton config management sait pas. Les autres nodes ont pas le fix. T’as créé un flocon de neige

Prochain incident sur un autre node? Même problème, même bidouille, même absence de doc. Et voilà, t’en as deux

J’ai vu des clusters où plus personne ose reboot certains nodes parce qu’ils ont “des configs spéciales”. C’est pas de l’infra ça. C’est une bombe à retardement

Du déclaratif, mais pour de vrai

La plupart des équipes se disent déclaratives mais leurs nodes disent autre chose. Ansible a tourné une fois à l’install, peut-être une autre fois pendant une “fenêtre de maintenance”. Entre les deux? Ça s’accumule, les petits changements à la main

Talos fait l’inverse. Tout l’état du node vient d’un fichier machine config. Point. Pas de modifs au runtime, pas d’install de packages, pas de fichiers édités à la main. Le système, c’est sa config

machine:
  type: worker
  kubelet:
    extraArgs:
      rotate-server-certificates: true
  network:
    hostname: worker-01
    interfaces:
      - interface: eth0
        dhcp: true
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.9.0

Cette config définit tout. Tu l’appliques, t’as exactement cet état. Tu la réappliques, même état. Tu la colles sur dix nodes, t’as dix systèmes identiques

Zéro drift. Zéro “ouais mais ce node il est différent parce que…“. Zéro surprise

Et sans shell, tu fais comment?

Première question que tout le monde pose. Logique, un shell c’est pratique

Talos remplace ça par talosctl, un CLI qui cause à l’API Talos. Tout ce que tu faisais en SSH, tu le fais avec

Voir les services:

talosctl services -n 10.0.0.5

Choper les logs:

talosctl logs kubelet -n 10.0.0.5

Messages kernel:

talosctl dmesg -n 10.0.0.5

Ressources système:

talosctl memory -n 10.0.0.5
talosctl cpu -n 10.0.0.5

La diff: c’est du read-only. Tu vois tout mais tu modifies rien directement. Les changements passent par la machine config

Au début ça fait bizarre. Et puis tu te rends compte que t’es plus tenté de “juste régler ce truc vite fait”. Soit tu fixes proprement dans la config, soit tu fixes pas

Des upgrades qui cassent pas les pieds

Les upgrades de nodes à l’ancienne, c’est toute une histoire. Tu mets à jour les packages, tu croises les doigts, tu reboot, tu pries. Peut-être que t’as de l’automation. Peut-être que ça marche à peu près

Avec Talos, les upgrades sont atomiques:

talosctl upgrade --image ghcr.io/siderolabs/installer:v1.9.1 -n 10.0.0.5

L’OS entier est remplacé. Pas patché, remplacé. Si ça foire, rollback instantané vu que l’ancienne image est encore là

Ça marche parce qu’il y a rien à garder. Pas de packages custom, pas de configs bidouillées, pas d’état en dehors de ce que Kubernetes gère. Le node est jetable, c’est fait pour

Mes upgrades Talos, je les fais comme mes upgrades de containers: je pull la nouvelle image, je remplace, terminé. Pas de créneau de maintenance, pas de “pourvu qu’apt pète rien”

Les alternatives

Ubuntu/Debian: Une distro complète, ça veut dire une surface d’attaque complète. Un package manager, ça veut dire du drift potentiel. Un accès shell, ça veut dire que quelqu’un va s’en servir en plein incident

Flatcar Container Linux: Mieux. Minimal, quasi-immutable, pensé pour les containers. Mais t’as toujours le shell, donc tu peux toujours tricher. Et tu le feras, à 2h du mat quand ça crame

Bottlerocket: La réponse d’AWS au problème. Bonne conception, même philosophie que Talos. Mais c’est AWS only. Multi-cloud ou on-prem, c’est mort

Talos tourne partout: bare metal, AWS, GCP, Azure, Hetzner, ton home lab. Même OS, mêmes outils, même façon de bosser

Temps d’apprentissage vs gain opérationnel

Talos, ça s’apprend. Compte deux jours pour être à l’aise, une semaine pour être vraiment efficace. Faut piger le format machine config, le modèle API, comment marchent les upgrades

Mais en échange t’as:

• Fini le “pourquoi ce node est différent”
• Fini les enquêtes sur le config drift
• Fini les accès SSH à auditer
• Fini le stress des mises à jour de packages
• Les upgrades passent de “maintenance planifiée” à “tiens je le fais là”

Le temps que tu mets à apprendre Talos, tu le rattrapes dès le premier mois à pas debugger des incohérences entre nodes

Quand éviter Talos

Matos exotique: Talos supporte pas mal de trucs, mais si t’as besoin de modules kernel ou de drivers pas inclus, faudra build des images custom. C’est faisable mais ça rajoute de la complexité

Équipe pas prête: Si ton équipe a besoin du shell pour debugger, Talos va leur donner l’impression de bosser les mains attachées. Faut d’abord avoir une observabilité correcte, des logs et métriques accessibles sans toucher aux nodes

Dépendances legacy: Y a des workloads qui veulent modifier l’host. Vieux agents de monitoring, certains drivers storage, tout ce qui part du principe qu’il peut écrire sur le filesystem. Faut repenser tout ça avant que Talos soit viable

Pourquoi c’est bien que ce soit ennuyeux

Une infra ennuyeuse, c’est une bonne infra. T’as pas envie que ton OS te fasse des surprises. Tu veux qu’il fasse tourner des containers et qu’il te foute la paix

Talos c’est ennuyeux. Chaque node est pareil. Les upgrades sont prévisibles. Y a rien à debugger côté OS parce qu’il y a rien de custom côté OS

Ton cluster Kubernetes devient le seul truc qui compte. Les nodes en dessous sont interchangeables. T’en butes un, t’en relances un autre, état identique en quelques minutes. C’est le modèle bétail vraiment appliqué, pas juste évoqué en réunion

Les équipes que j’ai vues passer à Talos passent moins de temps à gérer les nodes et plus de temps sur l’applicatif. Pas parce que Talos est magique, mais parce qu’il supprime la tentation de faire vite fait mal fait

Tu peux pas SSH pour régler un truc. Donc tu le règles proprement. Et ce qui est réglé proprement, ça revient pas