ITSkillsCenter
Self-hosting

Provisionner des VM Talos Linux pour Kubernetes sur Proxmox

12 دقائق للقراءة

Article principal · Ce tutoriel fait partie de la série Kubernetes domestique sur Proxmox VE. Tutoriel précédent : Installer Proxmox VE 9.1. Tutoriel suivant : kubeadm vs k3s.

Talos Linux est un système d’exploitation immuable conçu uniquement pour Kubernetes. Pas de shell utilisateur, pas de SSH, pas de gestionnaire de paquets : tout passe par une API gRPC pilotée depuis l’outil talosctl. Cette discipline élimine des classes entières d’erreurs (mises à jour partielles, dérives de configuration, intrusions par compromission de session shell). La version 1.13.0, sortie le 27 avril 2026, embarque par défaut Kubernetes 1.36.0 et bénéficie d’un noyau compilé avec Clang/ThinLTO. Ce tutoriel décrit la création de six machines virtuelles Talos sur Proxmox, leur configuration en mode controlplane ou worker, et le bootstrap initial du cluster Kubernetes.

Prérequis et préparation du poste de travail

Côté serveur : un Proxmox VE 9.1 fonctionnel avec un pool ZFS prêt à recevoir les disques de VM (cf. tutoriel précédent) et au moins 24 Gio de RAM disponible (4×3 Gio pour les workers, 3×2 Gio pour le control plane).

Côté poste de travail : installer talosctl et kubectl. Ce sont les deux seuls outils nécessaires pour administrer le cluster.

# Installer talosctl 1.13.0 (Linux x86_64)
curl -sL https://github.com/siderolabs/talos/releases/download/v1.13.0/talosctl-linux-amd64 \
  -o /usr/local/bin/talosctl
chmod +x /usr/local/bin/talosctl
talosctl version --client

# Installer kubectl 1.36 (compatible avec K8s 1.36 embarqué dans Talos 1.13)
curl -sL https://dl.k8s.io/release/v1.36.0/bin/linux/amd64/kubectl \
  -o /usr/local/bin/kubectl
chmod +x /usr/local/bin/kubectl
kubectl version --client

Les deux commandes --version --client doivent retourner respectivement 1.13.0 et v1.36.0. C’est la confirmation que les binaires sont en place et exécutables.

Étape 1 — Télécharger l’image Talos pour Proxmox

Talos publie des images dédiées par hyperviseur. Pour Proxmox, on télécharge l’image disque qcow2, qu’on importe ensuite directement dans une VM. Sider Labs distribue une image générique nocloud-amd64.iso et un disque nocloud-amd64.qcow2 qui se compose avec un boot ISO de configuration.

# Sur Proxmox, dans /var/lib/vz/template/iso
cd /var/lib/vz/template/iso
wget https://github.com/siderolabs/talos/releases/download/v1.13.0/metal-amd64.iso
ls -la metal-amd64.iso
# Doit afficher environ 80 Mio

L’image metal-amd64.iso est l’image bare-metal de Talos : elle démarre la machine en mode « maintenance » sans configuration, prête à recevoir une machineconfig par l’API. Cette image apparaîtra ensuite dans Proxmox sous le stockage local, section ISO Images.

Étape 2 — Créer une VM template Talos

Plutôt que de créer six VM à la main, on crée un template puis on clone. Sur l’interface web Proxmox : Create VM. Renseigner les écrans suivants :

# General
Node: pve01
VM ID: 9000
Name: talos-template

# OS
Use CD/DVD disc image: ISO local: metal-amd64.iso
Guest OS Type: Linux 6.x - 2.6 Kernel

# System
BIOS: OVMF (UEFI)
Machine: q35
Add EFI Disk: Yes (storage vmpool)
SCSI Controller: VirtIO SCSI (et NON « VirtIO SCSI single » qui peut bloquer le bootstrap Talos sur Proxmox)
Qemu Agent: Enabled

# Disks
SCSI 0: vmpool, 32 GiB, Discard=on, SSD emulation=on, IO thread=on

# CPU
Sockets: 1
Cores: 4
Type: host  # essentiel pour les workloads K8s, expose toutes les instructions du CPU hôte

# Memory
Memory: 4096 MiB
Ballooning: désactivé

# Network
Bridge: vmbr0
Model: VirtIO (paravirtualized)
Firewall: désactivé pour cette VM (Cilium gère la sécurité réseau plus tard)

Valider la création. Avant de démarrer, ouvrir l’onglet Hardware de la VM et vérifier que tout est cohérent. Convertir ensuite la VM en template via VM 9000 → More → Convert to template. Le template talos-template est désormais cloné.

Étape 3 — Cloner les six VM

Trois clones pour le control plane, trois pour les workers. Sur chacune, ajuster le profil RAM/CPU au rôle.

# Sur la console Proxmox, cloner en lot via la CLI pvesh
for i in 1 2 3; do
  pvesh create /nodes/pve01/qemu/9000/clone \
    -newid 100$i -name talos-cp-$i -full -storage vmpool
done

for i in 1 2 3; do
  pvesh create /nodes/pve01/qemu/9000/clone \
    -newid 110$i -name talos-wk-$i -full -storage vmpool
done

# Ajuster les workers : 6 GiB RAM, 4 vCPU, +1 disque de 32 Gio pour Rook-Ceph
for i in 1 2 3; do
  qm set 110$i -memory 6144 -cores 4
  qm set 110$i -scsi1 vmpool:32,discard=on,ssd=1
done

À la fin, six VM apparaissent dans l’arborescence Proxmox : talos-cp-1, talos-cp-2, talos-cp-3, talos-wk-1, talos-wk-2, talos-wk-3. Démarrer les six VM. Chacune obtient une adresse IP par DHCP et passe en mode maintenance Talos. Noter les IP attribuées (visible sur la console Proxmox de chaque VM).

Pour la suite, on suppose les IP suivantes (à adapter) : control plane 192.168.1.61/62/63, workers 192.168.1.71/72/73, et une VIP 192.168.1.60 qui sera l’endpoint stable du Kubernetes API server.

Étape 4 — Générer la configuration Talos

Talos est piloté par deux fichiers YAML : controlplane.yaml (appliqué aux nœuds control plane) et worker.yaml (appliqué aux workers). Ils sont générés en une commande, paramétrés par le nom du cluster et l’endpoint d’API server.

mkdir -p ~/talos-homelab && cd ~/talos-homelab

talosctl gen config homelab https://192.168.1.60:6443 \
  --kubernetes-version 1.36.0 \
  --install-disk /dev/sda \
  --output-types controlplane,worker,talosconfig

ls -la
# controlplane.yaml  worker.yaml  talosconfig

Trois fichiers apparaissent. controlplane.yaml et worker.yaml portent les secrets et certificats du cluster — ils sont à protéger comme un mot de passe maître. talosconfig est le fichier de config local de talosctl, équivalent au kubeconfig mais pour piloter les nœuds Talos eux-mêmes.

Configurer talosctl pour qu’il sache à quels endpoints s’adresser :

talosctl --talosconfig=./talosconfig \
  config endpoint 192.168.1.61 192.168.1.62 192.168.1.63
talosctl --talosconfig=./talosconfig \
  config node 192.168.1.61 192.168.1.62 192.168.1.63 \
                 192.168.1.71 192.168.1.72 192.168.1.73
export TALOSCONFIG=$(pwd)/talosconfig

L’export TALOSCONFIG permet d’omettre l’option --talosconfig dans toutes les commandes suivantes.

Étape 5 — Appliquer la configuration sur chaque nœud

Chaque VM est en mode maintenance et écoute sur le port 50000 en attendant sa machineconfig. On l’envoie nœud par nœud.

# Control plane
for ip in 192.168.1.61 192.168.1.62 192.168.1.63; do
  talosctl apply-config --insecure -n $ip --file controlplane.yaml
done

# Workers
for ip in 192.168.1.71 192.168.1.72 192.168.1.73; do
  talosctl apply-config --insecure -n $ip --file worker.yaml
done

Le drapeau --insecure est nécessaire pour le tout premier contact (les certificats mutuels n’existent pas encore). Après l’apply, chaque VM redémarre, installe Talos sur /dev/sda, puis redémarre une seconde fois sur le système installé. Compter trois à cinq minutes par nœud.

Étape 6 — Bootstrap etcd sur le premier control plane

À ce stade, les six nœuds sont actifs mais le cluster Kubernetes n’est pas encore initialisé : etcd n’a pas de membre actif. La commande bootstrap initialise etcd sur le premier control plane uniquement, qui agira comme leader initial.

talosctl bootstrap -n 192.168.1.61

# Surveiller la progression
talosctl health -n 192.168.1.61
# Doit progresser de "discovered nodes" → "etcd to be healthy" → "kubernetes is healthy"

L’opération prend environ deux minutes. À la fin, talosctl health affiche healthy sur toutes les checks. Les deux autres control plane rejoignent etcd automatiquement parce que la machineconfig leur a indiqué l’endpoint commun. Si la santé reste bloquée plus de cinq minutes, inspecter les logs avec talosctl logs -n 192.168.1.61 etcd.

Étape 7 — Récupérer le kubeconfig et vérifier le cluster

Le cluster Kubernetes répond désormais sur la VIP. Récupérer le kubeconfig pour que kubectl puisse interagir avec lui.

talosctl kubeconfig ~/.kube/config -n 192.168.1.61

kubectl get nodes -o wide
# Six nœuds doivent apparaître, tous en STATUS Ready (ou NotReady tant que le CNI n'est pas installé)

kubectl get pods -A
# Les pods kube-system sont là : kube-apiserver, kube-controller-manager, etcd...
# Les pods CoreDNS resteront Pending tant que le CNI n'est pas installé : c'est normal

Voir les six nœuds et l’API server qui répond confirme que le cluster est opérationnel au niveau control plane. Le statut NotReady sur les nœuds est attendu : il signifie qu’aucun CNI n’a encore créé le réseau de pods. C’est l’étape suivante du parcours, traitée dans le tutoriel Déployer Cilium CNI avec eBPF.

Étape 8 — Sauvegarder les fichiers sensibles

Trois fichiers ne doivent jamais être perdus, sous peine de devoir reconstruire le cluster : controlplane.yaml, worker.yaml et talosconfig. Ils contiennent l’ensemble des secrets et certificats. Les chiffrer avec age ou sops et les stocker hors du serveur.

# Exemple avec age (clé asymétrique simple)
age-keygen -o ~/.age/talos-key.txt
PUBLIC_KEY=$(grep "public key" ~/.age/talos-key.txt | awk '{print $4}')

cd ~/talos-homelab
tar czf - controlplane.yaml worker.yaml talosconfig | \
  age -r $PUBLIC_KEY -o talos-secrets.age

# Conserver talos-secrets.age et la clé privée séparément
# (clé USB chiffrée, gestionnaire de mots de passe, etc.)

L’archive chiffrée fait quelques kilooctets. Une copie sur un support externe et une copie dans un service de sauvegarde personnel mettent l’environnement à l’abri d’une perte du poste de travail.

Erreurs fréquentes et résolutions

Symptôme Cause Résolution
talosctl apply-config retourne connection refused VM non démarrée ou IP différente de celle attendue Vérifier la console Proxmox de la VM, relever la vraie IP affichée à l’écran
Le bootstrap reste à etcd to be healthy indéfiniment Disque /dev/sda inexistant, l’install n’a pas eu lieu Vérifier --install-disk, l’ajuster avec talosctl edit machineconfig au besoin
kubectl indique x509 certificate signed by unknown authority Mauvais kubeconfig importé Régénérer avec talosctl kubeconfig --force
Les nœuds restent NotReady après plus de 10 minutes Pas de CNI installé Passer au tutoriel Cilium
talosctl health remonte component apid is unhealthy Réseau de la VM coupé pendant l’apply Refaire talosctl reset sur le nœud puis réappliquer la config

Pour la suite du parcours

Le cluster Kubernetes est en place : six nœuds Talos, control plane HA, kubectl fonctionnel. La prochaine décision concerne la distribution Kubernetes elle-même : le tutoriel kubeadm vs k3s : choisir sa distribution Kubernetes compare les compromis et explique pourquoi Talos+kubeadm reste le plus représentatif d’un cluster d’entreprise. Pour la vue d’ensemble, retourner au guide principal Kubernetes domestique sur Proxmox VE.

Ressources et documentation officielle

Pourquoi Talos plutôt qu’un Ubuntu installé à la main

Le choix de Talos comme système d’exploitation des nœuds Kubernetes mérite d’être justifié, parce qu’il rompt avec les habitudes d’administration Linux classiques. Trois propriétés expliquent pourquoi Talos est un excellent choix pour un environnement domestique qui se veut sérieux.

La première est l’immuabilité du système de fichiers. Le rootfs Talos est en lecture seule. Aucun processus, même root, ne peut modifier un binaire système. Les modifications se font exclusivement par mise à jour atomique de l’image entière (talosctl upgrade). C’est l’élimination d’une cause majeure de dérive : sur un Ubuntu administré pendant six mois, on retrouve toujours des fichiers de config oubliés, des paquets installés ad hoc, des cron jobs créés en urgence. Sur Talos, l’état du système à un instant T est exactement celui décrit dans la machineconfig — ni plus, ni moins.

La deuxième est l’absence de SSH et de shell. La surface d’attaque réseau est réduite à deux ports : 50000 (API Talos, mTLS obligatoire) et 6443 (Kubernetes API). Aucune session shell n’est possible, donc aucune attaque par compromission de mot de passe SSH ou par injection de commande dans sudoers. Toutes les opérations passent par talosctl qui parle l’API gRPC chiffrée. Ce modèle correspond exactement à ce que les fournisseurs cloud font sur leurs nœuds managés.

La troisième est la configuration déclarative complète. Le fichier controlplane.yaml décrit l’intégralité du nœud : version Kubernetes, paramètres kubelet, registres d’images, certificats, options réseau, labels et taints. Pour reconstruire un cluster identique sur du nouveau matériel, il suffit de réappliquer cette config. Pas de checklist mentale, pas de oubli d’option --feature-gates qui changera le comportement six mois plus tard.

L’inconvénient est le coût d’apprentissage initial. talosctl n’est pas kubectl ni ssh. Les premiers diagnostics se font avec talosctl logs <service>, talosctl dmesg, talosctl restart <service>. La documentation Sider Labs est claire mais n’a pas la profondeur de la documentation Ubuntu accumulée depuis vingt ans. Pour un débutant, deux à trois semaines d’usage régulier suffisent à devenir à l’aise.

Variantes de déploiement à connaître

L’architecture six nœuds décrite est l’option par défaut recommandée. Trois variantes méritent d’être mentionnées parce qu’elles correspondent à des contextes domestiques courants.

Single-node Talos pour démarrer petit : on peut tester Talos sur une seule VM qui assume à la fois le rôle control plane et worker. La config se génère avec l’option --with-cluster-discovery=false et l’on retire le taint node-role.kubernetes.io/control-plane après bootstrap pour permettre au scheduler d’y placer des pods. Pratique pour une démo ou un labo léger ; à éviter pour héberger des services qu’on ne veut pas voir disparaître.

Hybride control plane Talos + workers Ubuntu : si l’on a déjà des serveurs Ubuntu en place qu’on veut intégrer comme workers, on peut conserver Talos pour le control plane et joindre les Ubuntu comme nœuds via kubeadm join. La cohabitation fonctionne ; on perd l’immuabilité sur les workers, ce qui est un compromis acceptable si l’on a investi dans une stack Ansible mature.

Cluster sur ARM (Ampere, Raspberry Pi 5) : Talos publie des images arm64. La procédure est identique en remplaçant amd64 par arm64 dans toutes les URL et options --install-disk. Attention : certaines images de charges (par exemple kube-prometheus-stack ou Velero) ont une couverture arm64 plus jeune. Vérifier la disponibilité avant de migrer une charge critique.

Quel que soit le scénario, l’enchaînement reste identique : Proxmox prêt, image Talos téléchargée, VM provisionnées, machineconfig générée et appliquée, bootstrap, kubeconfig récupéré. C’est cette répétabilité qui rend l’environnement maintenable sur la durée.

#2026 #cluster-k8s-homelab-proxmox #cluster-satellite #homelab #Kubernetes #Proxmox #self-hosting #Talos Linux #Tutoriel
Sponsoriser ce contenu

Cet emplacement est à vous

Position premium en fin d'article — c'est l'instant où les lecteurs sont le plus engagés. Réservez cet espace pour votre marque, votre formation ou votre offre.

Recevoir nos tarifs
Publicité