Déployer un cluster Talos Linux hautement disponible sur Proxmox

Talos Linux est un système d’exploitation conçu pour ne faire qu’une chose : exécuter Kubernetes. Il n’a ni shell, ni gestionnaire de paquets, ni accès SSH. Toute la configuration passe par une API déclarative, et c’est précisément ce qui le rend intéressant en exploitation.

Pourquoi Talos plutôt qu’une distribution généraliste

Sur une distribution classique, un nœud dérive. Quelqu’un se connecte, corrige un problème à chaud, et la machine ne ressemble plus à ses voisines. Six mois plus tard, personne ne sait plus reproduire l’état courant.

Talos supprime le problème à la racine : il n’y a pas d’endroit où se connecter. Un nœud est entièrement décrit par un fichier de configuration, et le remplacer revient à réappliquer ce fichier.

Préparer les machines virtuelles

Trois machines virtuelles suffisent pour un plan de contrôle hautement disponible. Le quorum etcd exige un nombre impair de membres, et trois est le minimum permettant de perdre un nœud.

Chaque machine doit disposer d’au moins deux cœurs et quatre gigaoctets de mémoire vive. Le plan de contrôle est plus gourmand qu’il n’y paraît, surtout lorsque le nombre d’objets dans etcd augmente.

Pensez à activer l’agent QEMU et à désactiver le démarrage sécurisé, faute de quoi l’image ne démarrera pas.

Générer la configuration

La commande de génération produit trois fichiers : la configuration des nœuds de contrôle, celle des workers, et le fichier de configuration client.

talosctl gen config homelab https://192.168.1.10:6443 \
  --output-dir ./talos-config

L’adresse fournie est le point d’entrée de l’API Kubernetes. En haute disponibilité, elle doit pointer vers une adresse virtuelle partagée, pas vers un nœud particulier — sinon la perte de ce nœud rend le cluster injoignable alors qu’il fonctionne parfaitement.

Appliquer et amorcer

La configuration s’applique nœud par nœud. Le premier nœud de contrôle doit ensuite être amorcé une seule fois, ce qui initialise etcd.

talosctl apply-config --insecure --nodes 192.168.1.11 \
  --file ./talos-config/controlplane.yaml

talosctl bootstrap --nodes 192.168.1.11

N’exécutez l’amorçage que sur un seul nœud. Le lancer sur deux nœuds crée deux grappes etcd distinctes qui ne se rejoindront jamais, et la seule sortie propre est de tout recommencer.

Vérifier

talosctl health --nodes 192.168.1.11
kubectl get nodes

Les nœuds apparaissent d’abord en NotReady : c’est normal tant qu’aucun greffon réseau n’est installé. Kubernetes considère qu’un nœud sans réseau de pods n’est pas prêt à recevoir de charge, et il a raison.

Et ensuite

L’installation d’un greffon réseau débloque les nœuds. À partir de là, le cluster est fonctionnel et la suite — stockage, ingress, déploiement continu — relève d’un socle GitOps, que je détaille dans un autre guide.

Le point à retenir : la totalité de ce qui précède tient dans des fichiers versionnés. Reconstruire le cluster ne demande aucune mémoire ni aucune note.