Déployer des clusters Kubernetes avec Talos Linux

Talos Linux est un système d’exploitation Linux moderne conçu spécifiquement pour exécuter Kubernetes. Il élimine la complexité des distributions traditionnelles en fournissant un OS minimal, immuable et entièrement géré via une API déclarative. Contrairement aux approches classiques nécessitant SSH et des configurations manuelles, Talos offre une expérience unifiée où chaque aspect du système est contrôlé par des manifestes YAML.

Historique de Talos Linux

Talos Linux a été créé par Sidero Labs pour répondre aux limites des approches traditionnelles de déploiement Kubernetes. Le projet est né d’une constatation simple : les distributions Linux classiques ont été conçues pour des cas d’usage généraux, avec des décennies d’héritage qui ne correspondent plus aux besoins des infrastructures cloud-native modernes.

Lancé publiquement en 2019, Talos a introduit plusieurs innovations majeures dans le domaine des systèmes d’exploitation pour conteneurs. Contrairement aux distributions minimalistes existantes qui se contentaient de réduire le nombre de paquets installés, Talos a été repensé from scratch avec les principes suivants :

• Immuabilité totale : Le système de fichiers racine est en lecture seule, éliminant toute modification manuelle non documentée
• API comme seul point d’entrée : Aucun shell interactif, toute opération passe par une API gRPC sécurisée et authentifiée
• Déclaratif pur : La configuration complète du système est décrite dans des fichiers YAML versionnables
• Sécurité par conception : Chiffrement des disques, certificats mutuels, principe du moindre privilège appliqué systématiquement

Depuis sa création, Talos a rapidement gagné en popularité dans les environnements bare-metal et edge computing où la sécurité, la reproductibilité et l’automatisation sont primordiales. Le projet est aujourd’hui largement adopté pour des déploiements Kubernetes en production, particulièrement dans les secteurs financier, industriel et gouvernemental où les exigences de conformité sont élevées.

L’évolution de Talos suit de près les versions de Kubernetes, avec un support des fonctionnalités les plus récentes et une compatibilité garantie. La communauté open source active contribue régulièrement à l’amélioration du projet, tandis que Sidero Labs fournit un support commercial et des outils complémentaires comme Sidero Metal pour la gestion d’infrastructures bare-metal à grande échelle.

Concepts clés de Talos Linux

Pour bien comprendre Talos, il est essentiel de saisir les concepts fondamentaux qui le différencient des approches traditionnelles :

• OS immuable : Le système de fichiers racine de Talos est monté en lecture seule. Aucune modification manuelle ne peut altérer l’état du système. Les mises à jour s’effectuent par remplacement complet de l’image système, garantissant qu’un nœud est toujours dans un état connu et reproductible. Cette immuabilité élimine la dérive de configuration qui affecte les systèmes traditionnels où des modifications accumulées au fil du temps créent des différences entre serveurs.
• Administration API-driven : Talos ne fournit aucun accès shell (pas de SSH, pas de console). Toute interaction avec le système s’effectue exclusivement via l’API Talos, une API gRPC sécurisée accessible par le client talosctl. Ce modèle garantit que toutes les opérations sont traçables, reproductibles et peuvent être automatisées. Chaque action administrative passe par la même interface, qu’il s’agisse de récupérer des logs, redémarrer un service ou mettre à jour le système.
• Machine Config : La configuration complète d’un nœud Talos est définie dans un fichier YAML appelé Machine Config. Ce manifeste déclaratif décrit tous les aspects du nœud : réseau, stockage, kubelet, certificats, utilisateurs API Talos, etc. En appliquant la même Machine Config à plusieurs nœuds, vous obtenez des machines strictement identiques. Cette approche déclarative s’intègre naturellement dans les workflows GitOps.
• Bootstrap etcd : Dans un cluster Kubernetes, etcd stocke tout l’état du cluster. Avec Talos, l’initialisation du quorum etcd est simplifiée : vous exécutez une seule commande bootstrap sur le premier control-plane, et les autres nœuds rejoignent automatiquement le cluster. Talos gère la formation du quorum, la distribution des certificats et la configuration réseau nécessaire.
• Endpoints et Nodes dans talosctl : La configuration talosctl utilise deux concepts distincts mais complémentaires. Les endpoints définissent les points d’accès à l’API Talos (typiquement des load balancers ou VIPs pour les clusters HA). Les nodes spécifient les machines cibles sur lesquelles exécuter les commandes. Dans un setup local, l’endpoint et le node peuvent être identiques (l’IP du nœud), mais en production, l’endpoint pointe vers un load balancer qui distribue les requêtes API, tandis que les nodes sont les adresses IP réelles des machines. Cette séparation permet d’interroger l’API via un point d’entrée unique (endpoint) tout en ciblant précisément des nœuds spécifiques pour les opérations de maintenance. Vous configurez les endpoints avec talosctl config endpoint <IP> et les nodes avec talosctl config nodes <IP1> <IP2>, ou via les options --endpoints et --nodes en ligne de commande.

Fonctionnalités de Talos Linux

Au-delà des concepts, Talos offre des fonctionnalités techniques concrètes :

• Sécurité renforcée : Désactivation totale de SSH, authentification mutuelle TLS pour toutes les communications API, support natif du chiffrement de disque avec TPM2 et KMS
• Gestion automatique des certificats : Génération, distribution et rotation automatiques des certificats Kubernetes et Talos sans intervention manuelle
• Support multi-plateforme : Déploiement sur bare-metal, cloud public (AWS, Azure, GCP, Outscale), plateformes de virtualisation (Proxmox, VMware, QEMU, Hyper-V) et architectures ARM64
• Mises à jour atomiques : Upgrades système et Kubernetes par remplacement complet d’image avec validation de santé automatique et rollback possible
• Diagnostics intégrés : Accès aux logs système, métriques, processus et état des services directement via talosctl sans shell
• Extensions système : Mécanisme d’extensions pour ajouter des drivers réseau personnalisés, modules de stockage ou agents de monitoring
• Mode maintenance : Possibilité de booter un nœud en mode maintenance pour récupération ou débogage avancé
• API versionnée : API Talos stable avec versioning sémantique garantissant la compatibilité

Différences avec Kubeadm et autres outils

Pour bien comprendre la valeur ajoutée de Talos, il est utile de le comparer avec kubeadm, l’outil standard de déploiement Kubernetes.

Avec kubeadm, vous installez d’abord une distribution Linux complète (Ubuntu, Debian, Rocky Linux), puis vous ajoutez le runtime de conteneurs (containerd ou CRI-O), et enfin vous exécutez les commandes kubeadm pour initialiser le cluster. Cette approche nécessite :

• La gestion des accès SSH pour administrer les machines
• L’installation et la maintenance de paquets système
• La configuration manuelle de systemd, réseau, firewall
• La rotation manuelle des certificats et la gestion des secrets
• Des procédures de mise à jour complexes touchant multiple couches

Avec Talos Linux, toute cette complexité disparaît. Le système d’exploitation, le runtime et Kubernetes sont livrés comme une image unique. Il n’y a qu’une seule Machine Config à appliquer pour définir complètement un nœud. Les mises à jour se font atomiquement en remplaçant l’image système complète. Les certificats sont automatiquement gérés et renouvelés.

Cette approche présente plusieurs avantages majeurs :

• Reproductibilité parfaite : Deux nœuds avec la même Machine Config sont strictement identiques
• Sécurité accrue : Surface d’attaque minimale, pas d’accès shell, audit trail complet via l’API
• Simplicité opérationnelle : Une seule interface (talosctl) pour toutes les opérations
• Conformité facilitée : Configuration versionnée et revue, état immuable vérifiable
• Automatisation native : API gRPC permettant l’intégration avec n’importe quel outil d’orchestration

Prérequis pour le déploiement local

Pour ce guide d’introduction, nous allons déployer un cluster Talos Linux localement avec Docker. Vous aurez besoin de :

• Machine hôte Linux avec support de virtualisation (KVM activé)
• Ressources minimales :
  • CPU : 8 cœurs physiques recommandés (6 minimum)
  • RAM : 16 Gio minimum (20 Gio recommandés)
  • Stockage : 50 Gio d’espace disque libre
• Logiciels requis :
  • QEMU
  • talosctl (client CLI Talos)
  • kubectl (client Kubernetes)

Notre cluster de test comprendra :

• 3 nœuds control-plane : 2 vCPU, 4 Gio RAM chacun
• 2 nœuds worker : 2 vCPU, 4 Gio RAM chacun

Cette configuration offre un quorum etcd à 3 membres (haute disponibilité) et permet de tester la répartition de charge sur les workers.

Installation des outils

Talos fournit une commande intégrée pour créer rapidement un cluster local. Deux provisioners sont disponibles :

• docker : Utilise des conteneurs Docker (par défaut, simple et rapide)
• qemu : Utilise KVM/QEMU avec des VMs complètes (plus proche de la production mais complexe sous WSL)

Choix du provisioner

Utilisez Docker si :

• Vous êtes sous Windows avec WSL2 (setup QEMU très complexe)
• Vous voulez démarrer rapidement sans configuration système
• Vous avez des ressources limitées

Utilisez QEMU si :

• Vous tournez sur Linux natif (Ubuntu, Fedora, Debian, etc.)
• Vous voulez une expérience identique à un déploiement production
• Vous avez besoin de tester des fonctionnalités bas niveau (réseau, stockage)

Le provisioner QEMU crée de vraies VMs avec KVM, ce qui est plus proche des environnements cloud réels. Cependant, sous WSL, la configuration de KVM nécessite des manipulations avancées (nested virtualization, drivers, réseau) qui dépassent le cadre de ce guide d’introduction.

Installation de KVM/QEMU

Pour installer KVM/QEMU sur votre distribution Linux, consultez le guide complet : Maîtriser KVM pour la virtualisation Linux.

Ce guide couvre :

• Installation sur Ubuntu/Debian, Fedora/RHEL, Arch Linux
• Configuration de libvirt et permissions
• Validation du support de virtualisation
• Gestion des réseaux virtuels

Installation de Docker

Pour utiliser le provisioner docker (recommandé pour ce guide), vous devez avoir Docker installé sur votre système.

Pour une installation complète selon votre distribution Linux, consultez notre guide détaillé : Maîtriser Docker.

Ce guide couvre :

• Installation sur Ubuntu/Debian, Fedora/RHEL, Arch Linux
• Configuration sans sudo (groupe docker)
• Bonnes pratiques de sécurité
• Gestion des réseaux et volumes
• Commandes essentielles

Installation de talosctl

talosctl est le client CLI pour interagir avec l’API Talos :

# Télécharger la dernière version de talosctl
curl -sL https://talos.dev/install | sh

# Vérifier l'installation
talosctl version --client

Activer l’autocomplétion

L’autocomplétion améliore considérablement l’expérience d’utilisation de talosctl en permettant la complétion automatique des commandes, options et ressources.

Pour Bash :

# Générer et installer l'autocomplétion
talosctl completion bash | sudo tee /etc/bash_completion.d/talosctl > /dev/null

# Recharger le shell ou sourcer le fichier
source /etc/bash_completion.d/talosctl

Pour Zsh :

# Créer le dossier de complétion s'il n'existe pas
mkdir -p ~/.zsh/completion

# Générer le fichier de complétion
talosctl completion zsh > ~/.zsh/completion/_talosctl

# Ajouter à votre ~/.zshrc si ce n'est pas déjà fait
echo 'fpath=(~/.zsh/completion $fpath)' >> ~/.zshrc
echo 'autoload -Uz compinit && compinit' >> ~/.zshrc

# Recharger la configuration
source ~/.zshrc

Pour Fish :

# Générer et installer l'autocomplétion
talosctl completion fish > ~/.config/fish/completions/talosctl.fish

# Recharger Fish
source ~/.config/fish/config.fish

Installation de kubectl

kubectl est le client CLI pour interagir avec Kubernetes.

Pour une installation complète et des guides d’utilisation détaillés, consultez notre série de guides : Maîtriser kubectl de A à Z.

Ces guides couvrent :

• Installation sur toutes les distributions Linux
• Configuration et gestion des contextes
• Commandes essentielles et avancées
• Plugins et outils complémentaires
• Cheat sheet complet

Création du cluster local avec talosctl

Création du cluster avec Docker

# Créer un dossier pour le projet
mkdir -p ~/talos-lab
cd ~/talos-lab

# Créer le cluster Talos avec 3 control-planes et 2 workers
talosctl cluster create \
  --provisioner docker \
  --name talos-lab \
  --controlplanes 3 \
  --workers 2

# La commande télécharge l'image Talos et crée les conteneurs
# Cela prend environ 3-5 minutes en fonction de vos ressources système

Cette commande effectue automatiquement :

• Téléchargement de l’image Talos pour Docker
• Création d’un réseau Docker bridge pour le cluster
• Création de 5 conteneurs (3 control-planes + 2 workers)
• Génération des Machine Configs
• Application des configs aux nœuds
• Bootstrap du cluster etcd
• Installation du CNI (Flannel par défaut)

Vous devez voir la progression dans la sortie console. Une fois terminée, le commande affiche un résumé avec les adresses IP des nœuds.

validating CIDR and reserving IPs
generating PKI and tokens
creating state directory in "/home/outscale/.talos/clusters/talos-lab"
downloading ghcr.io/siderolabs/talos:v1.11.3
creating network talos-lab
creating controlplane nodes
creating worker nodes
waiting for API
bootstrapping cluster
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: OK
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: OK
waiting for no diagnostics: OK
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: OK
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: OK
waiting for all k8s nodes to report ready: OK
waiting for kube-proxy to report ready: OK
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: OK

merging kubeconfig into "/home/outscale/.kube/config"
renamed cluster "talos-lab" -> "talos-lab-1"
renamed auth info "admin@talos-lab" -> "admin@talos-lab-1"
renamed context "admin@talos-lab" -> "admin@talos-lab-1"
PROVISIONER           docker
NAME                  talos-lab
NETWORK NAME          talos-lab
NETWORK CIDR          10.5.0.0/24
NETWORK GATEWAY       10.5.0.1
NETWORK MTU           1500
KUBERNETES ENDPOINT   https://127.0.0.1:34977

NODES:

NAME                        TYPE           IP         CPU    RAM      DISK
/talos-lab-controlplane-1   controlplane   10.5.0.2   2.00   2.1 GB   -
/talos-lab-controlplane-2   controlplane   10.5.0.3   2.00   2.1 GB   -
/talos-lab-controlplane-3   controlplane   10.5.0.4   2.00   2.1 GB   -
/talos-lab-worker-1         worker         10.5.0.5   2.00   2.1 GB   -
/talos-lab-worker-2         worker         10.5.0.6   2.00   2.1 GB   -

Création du cluster avec QEMU

Si vous utilisez Linux en natif (pas WSL), vous pouvez utiliser le provisioner QEMU pour une expérience plus proche de la production :

sudo -E talosctl cluster create \
  --name talos-lab \
  --provisioner qemu \
  --controlplanes 3 \
  --workers 2 \
  --cpus 2 \
  --memory 4096 \
  --disk 20480

Les VMs QEMU simulent un environnement réel avec boot UEFI, réseau virtuel et stockage persistant. C’est le setup recommandé pour valider des configurations avant un déploiement production.

Vérification du cluster

Une fois la création terminée, vérifiez l’état du cluster :

# La commande talosctl cluster show affiche le résumé du cluster
talosctl cluster show --name talos-lab

# Le fichier talosconfig a été créé automatiquement
export TALOSCONFIG=~/.talos/config

# Configurer les nœuds pour talosctl (requis)
talosctl config nodes 10.5.0.2

# Lister les nœuds via l'API Talos (interroge un seul nœud pour éviter les doublons)
talosctl get members

# Récupérer le kubeconfig
talosctl kubeconfig

# Vérifier les nœuds Kubernetes
kubectl get nodes

Résultat attendu :

NAME                       STATUS   ROLES           AGE     VERSION
talos-lab-controlplane-1   Ready    control-plane   7m29s   v1.34.1
talos-lab-controlplane-2   Ready    control-plane   7m29s   v1.34.1
talos-lab-controlplane-3   Ready    control-plane   7m26s   v1.34.1
talos-lab-worker-1         Ready    <none>          7m24s   v1.34.1
talos-lab-worker-2         Ready    <none>          7m25s   v1.34.1

Services Talos disponibles

Talos expose plusieurs services système essentiels via son API. Vous pouvez lister l’état de tous les services sur un nœud :

# Liste complète des services et leur état
talosctl --nodes 10.5.0.2 services

NODE       SERVICE      STATE     HEALTH   LAST CHANGE   LAST EVENT
10.5.0.2   apid         Running   OK       18m55s ago    Health check successful
10.5.0.2   containerd   Running   OK       18m56s ago    Health check successful
10.5.0.2   cri          Running   OK       18m55s ago    Health check successful
10.5.0.2   etcd         Running   OK       18m21s ago    Health check successful
10.5.0.2   kubelet      Running   OK       18m24s ago    Health check successful
10.5.0.2   machined     Running   OK       18m56s ago    Health check successful
10.5.0.2   trustd       Running   OK       18m55s ago    Health check successful

Les services principaux que vous verrez :

• apid : API Talos (endpoint gRPC pour toutes les commandes talosctl)
• containerd : Moteur de conteneurs (runtime pour Kubernetes et services système)
• cri : Interface Container Runtime (implémentation CRI pour kubelet)
• etcd : Base de données distribuée du control plane Kubernetes
• kubelet : Agent Kubernetes sur chaque nœud
• machined : Daemon principal Talos (gestion configuration et séquence boot)
• trustd : Service de gestion des certificats et PKI Talos

En cas de dysfonctionnement, vous pouvez interroger l’état de chaque service pour diagnostiquer les problèmes.

Plus loin

Ce type de provisionnement automatisé est idéal pour des environnements de test et de développement. Pour des déploiements en production, nous verrons dans une autre guide comment déployer Talos sur des serveurs bare-metal ou dans le cloud avec des outils comme Terraform et Ansible.

Opérations sur le cluster local

Maintenant que le cluster est opérationnel, explorons les opérations courantes avec Talos. Contrairement aux distributions Linux traditionnelles où vous utiliseriez SSH pour accéder aux machines, Talos fonctionne exclusivement via son API gRPC. Toutes les commandes talosctl communiquent avec l’API Talos sur chaque nœud, garantissant traçabilité et reproductibilité.

Accès aux logs et diagnostics

L’API Talos expose les logs système et les informations de diagnostic sans nécessiter d’accès shell. Le client talosctl se connecte au nœud spécifié via --nodes et interroge l’API pour récupérer les données demandées.

# Messages du noyau
talosctl --nodes 10.5.0.2 dmesg

# État du service etcd
talosctl --nodes 10.5.0.2 service etcd status

# Logs du kubelet sur un des services du control-plane
talosctl --nodes 10.5.0.2 logs kubelet # ou etcd

# Lister les processus en cours
talosctl --nodes 10.5.0.2 ps

Ces commandes sont l’équivalent de journalctl, ps, dmesg et systemctl status sur un système Linux classique, mais accessibles uniquement via l’API sécurisée. Aucun processus shell n’est exécuté sur le nœud cible.

Tester le déploiement d’une application

Une fois le cluster opérationnel avec son CNI installé, déployons une application pour valider la connectivité réseau entre pods et services.

# Créer un Deployment nginx
kubectl create deployment nginx --image=nginx:alpine --replicas=3

# Exposer via un Service
kubectl expose deployment nginx --port=80 --type=NodePort

# Vérifier les pods
kubectl get pods -o wide

# Accéder au service (récupérer le NodePort)
kubectl get svc nginx
PORT=$(kubectl get svc nginx -o jsonpath='{.spec.ports[0].nodePort}')

# Tester l'accès (depuis l'hôte KVM)
curl http://10.5.0.4:$PORT

Le Service de type NodePort expose l’application sur un port aléatoire (30000-32767) de chaque nœud. Les 3 réplicas nginx sont répartis sur les workers par le scheduler Kubernetes. Le CNI (Flannel ou Cilium) gère le routage réseau entre pods et l’accès externe via NodePort. Nous verrons dans un autre guide comment configurer un Ingress avec un load balancer pour un accès plus avancé.

Nettoyage

Pour supprimer complètement le cluster :

# Détruire le cluster et nettoyer les ressources
talosctl cluster destroy --name talos-lab

# Les conteneurs Docker sont automatiquement supprimés
# Vérifier qu'il ne reste rien
docker ps -a | grep talos-lab
docker prune -f

Aller plus loin : déploiement production

Ce guide vous a permis de découvrir Talos Linux dans un environnement local contrôlé. Pour un déploiement en production sur une infrastructure cloud avec :

• Architecture multi-zone hautement disponible
• Réseau isolé avec peering
• Load balancer HAProxy
• Provisionnement Infrastructure as Code avec Terraform
• Configurations avancées (chiffrement disque, RBAC, monitoring)

C’est par là : Talos Linux ☁️ : cluster Kubernetes multi-AZ

Conclusion

Talos Linux simplifie radicalement le déploiement et la gestion de Kubernetes en éliminant les couches de complexité des distributions traditionnelles. L’approche immuable et API-driven garantit :

• Reproductibilité : Chaque nœud est strictement identique
• Sécurité : Aucun accès shell, surface d’attaque minimale
• Simplicité : Une seule interface (talosctl) pour toutes les opérations
• GitOps natif : Configuration complète versionnée en YAML

Ce cluster local vous permet d’expérimenter Talos dans un environnement sûr avant de passer à un déploiement production. N’hésitez pas à tester les différentes fonctionnalités, casser le cluster et le reconstruire : c’est le meilleur moyen d’apprendre !

Plus d’infos

• Documentation officielle Talos : Talos Linux Documentation ↗
• Sidero Labs (créateur de Talos) : Sidero Labs ↗
• Les nombreux articles de Quentin Joly sur Talos Linux : Articles Talos Linux ↗