Construire un cluster Kubernetes domestique sur Proxmox VE

Faire tourner Kubernetes à la maison, sur du matériel qu’on possède réellement, change la manière dont on apprend et opère cette plateforme. On ne loue plus des nœuds managés à un fournisseur cloud : on installe l’hyperviseur, on découpe les machines virtuelles, on bootstrappe le control plane, on choisit son CNI, on monte du stockage distribué, on outille la livraison continue. Chaque couche devient explicite. Et chaque couche révèle une décision qu’on ignorait quand un service managé la prenait à notre place.

Proxmox VE 9.1 est aujourd’hui l’un des meilleurs choix pour cette base. C’est un hyperviseur libre basé sur Debian 13 « Trixie », noyau Linux 6.17.2, qui combine virtualisation KVM, conteneurs LXC, ZFS natif, Ceph intégré et une interface web complète. Il accepte du matériel grand public — un mini-PC Intel N150, un Dell OptiPlex d’occasion, un NUC, un serveur Supermicro silencieux — et offre suffisamment de fonctionnalités d’entreprise pour qu’un cluster monté chez soi reflète honnêtement ce qu’on retrouve en production.

Ce guide pose la vue d’ensemble : pourquoi cette architecture a du sens, quelles sont les décisions structurantes à prendre avant la première installation, comment s’enchaînent les huit étapes du parcours, et où chaque tutoriel détaillé prend le relais. Les choix techniques de référence sont datés mai 2026 et s’appuient sur les versions stables actuelles : Proxmox VE 9.1, Talos Linux 1.13.0 (qui embarque Kubernetes 1.36.0), kubeadm sur Kubernetes 1.35, k3s v1.35.4+k3s1, Cilium 1.19.3, Rook 1.19.5, Argo CD 3.4, kube-prometheus-stack 84.5.0 et Velero 1.18.

Pourquoi un Kubernetes domestique mérite votre temps

L’argument financier vient en premier mais n’est pas le plus important. Un cluster managé chez un fournisseur cloud, même d’entrée de gamme, coûte plusieurs dizaines d’euros par mois dès qu’on ajoute des disques persistants et un load balancer. Multiplié sur un an, on dépasse facilement le prix d’un mini-PC d’occasion à 200 €. À la maison, l’électricité d’un nœud silencieux à 15 W tourne autour de deux à trois euros par mois. La balance penche très vite du côté du matériel possédé dès qu’on apprend, qu’on expérimente, ou qu’on héberge des services personnels.

L’argument pédagogique pèse plus lourd. Sur un cluster managé, le control plane est invisible. Les certificats sont gérés. Le réseau fonctionne. Le stockage est attaché. Quand quelque chose casse en production, on ne sait pas par où regarder parce qu’on n’a jamais vu les briques fonctionner séparément. Une infrastructure Proxmox+Kubernetes maison force à croiser les couches : on configure soi-même l’IOMMU et le bridge réseau de l’hyperviseur, on génère le secret de bootstrap des nœuds Talos, on installe Cilium puis on observe les politiques eBPF dans le kernel, on déploie Rook puis on regarde les OSD se former sur Ceph. Le savoir devient opérationnel.

L’argument souveraineté arrive en troisième. Pour un freelance ou une petite structure, héberger Gitea, Vaultwarden, Nextcloud, un serveur mail, un bastion VPN ou des outils internes sur sa propre infrastructure évite de disperser des données sensibles chez plusieurs fournisseurs. Kubernetes apporte la primitive de redéploiement reproductible : un nœud meurt, on le remplace, les pods reviennent. C’est la résilience qu’on attendrait d’un cloud, mais sans louer de cloud.

L’architecture cible en une vue

L’architecture qu’on cible dans ce parcours est simple et reproductible. Un seul serveur physique fait tourner Proxmox VE 9.1. Sur cet hyperviseur, on découpe six machines virtuelles : trois forment le control plane Kubernetes (haute disponibilité d’etcd, scheduler et API server), trois forment les workers où s’exécutent les pods. Chaque VM consomme deux à quatre vCPU et quatre à huit Gio de RAM. Les disques sont stockés sur un pool ZFS local de l’hyperviseur, ce qui apporte snapshots et compression « gratuits ».

Au-dessus, on installe Talos Linux 1.13 — un système d’exploitation immuable et minimal conçu uniquement pour Kubernetes — ou bien Ubuntu 24.04 LTS si on préfère un système plus familier piloté par kubeadm. Sur ce socle, Kubernetes 1.35 ou 1.36 fournit les API. Cilium 1.19 prend la place du CNI et apporte des politiques réseau eBPF performantes. Rook 1.19 déploie un cluster Ceph qui tourne dans Kubernetes lui-même et expose des volumes persistants, du stockage objet S3-compatible et un système de fichiers partagé. Argo CD 3.4 synchronise les manifestes depuis un dépôt Git. Le kube-prometheus-stack 84.5.0 fournit Prometheus, Grafana et l’Alertmanager. Velero 1.18 sauvegarde l’ensemble vers un bucket S3 distant.

Si l’on dispose de plusieurs machines physiques, l’architecture monte d’un cran : trois nœuds Proxmox montés en cluster, chacun hébergeant une partie du control plane et des workers, ce qui apporte la haute disponibilité matérielle. Le parcours décrit ici reste valide, on duplique simplement la procédure d’installation Proxmox sur chaque hôte avant de déclarer le cluster d’hyperviseurs.

Choisir son matériel sans surpayer

Le critère qui décide tout est la quantité de RAM. Kubernetes consomme rapidement. Le control plane à lui seul réclame un minimum de deux Gio par nœud sur Talos, plutôt quatre sur Ubuntu+kubeadm. Un cluster fonctionnel avec ses six VM, Rook, Prometheus et trois ou quatre charges utiles tient honnêtement sur 32 Gio de RAM physique, est confortable à 64 Gio, et devient une vraie maquette à 128 Gio.

Pour un budget contenu, un mini-PC neuf à base d’Intel N150 ou N200 avec 32 Gio de DDR5 et un SSD NVMe d’un Tio coûte environ 350 € en mai 2026 et consomme moins de quinze watts en charge moyenne. C’est suffisant pour un cluster d’apprentissage. Pour passer à 64 Gio, le marché de l’occasion offre d’excellents Dell OptiPlex 7080 ou HP EliteDesk 800 G9 entre 200 et 400 €, généralement extensibles à 64 ou 128 Gio. Pour qui veut du matériel serveur silencieux, un Supermicro X11 ou X12 d’occasion en boîtier Fractal Define accepte 256 Gio d’ECC, du double SFP+ et plusieurs disques pour Ceph : on monte alors une vraie plateforme à demeure.

Le stockage compte presque autant. Pour Ceph distribué avec Rook, prévoir au minimum trois disques dédiés, idéalement des NVMe ou des SATA SSD. Mélanger un SSD pour le système Proxmox et le stockage des VM avec deux ou trois disques rotatifs pour Ceph reste possible mais réduit la latence. Le réseau, lui, peut commencer à 1 Gbps : le passage à 2,5 Gbps ou 10 Gbps devient pertinent quand Ceph monte en charge.

Le parcours en huit tutoriels

La construction d’un environnement Kubernetes domestique cohérent ne tient pas dans un seul article. Chaque grande brique mérite un tutoriel pas-à-pas dédié, qu’on suit dans l’ordre ou qu’on lit séparément quand on cherche à creuser un point précis. Voici l’enchaînement recommandé :

1. Installer Proxmox VE 9.1 sur serveur domestique — du téléchargement de l’ISO à la configuration ZFS, en passant par le réseau bridgé et l’accès web sécurisé.
2. Provisionner des VM Talos Linux pour Kubernetes — créer six machines immuables prêtes à recevoir Talos, avec les bons disques, vCPU et profils CPU.
3. kubeadm vs k3s : choisir sa distribution Kubernetes — comprendre les différences réelles entre la distribution de référence et la distribution allégée pour décider sans regrets.
4. Déployer Cilium CNI avec eBPF sur Kubernetes — installer le réseau, activer Hubble pour l’observabilité, écrire les premières politiques de sécurité réseau.
5. Stockage persistant avec Rook-Ceph sur Kubernetes — préparer les disques, déployer l’opérateur Rook, créer les pools de blocs et le bucket S3 interne.
6. Bootstrap GitOps avec Argo CD sur Kubernetes — installer Argo CD, structurer le dépôt Git, créer la première Application qui se synchronise toute seule.
7. Observabilité Kubernetes avec kube-prometheus-stack — déployer Prometheus, Grafana, Alertmanager et exposer les dashboards par Ingress.
8. Sauvegardes Kubernetes avec Velero — sauvegarder les namespaces et les volumes persistants vers un stockage objet distant, tester une restauration complète.

Suivre l’ordre minimise les frustrations : chaque étape installe le préalable de la suivante. Sauter directement à Argo CD sans CNI fonctionnel donne des erreurs cryptiques. Démarrer Velero sans stockage objet fait perdre une heure. La séquence est conçue pour qu’à chaque palier, le cluster soit utilisable.

Les concepts à maîtriser avant de poser le premier nœud

Comprendre Kubernetes au niveau de l’utilisateur — déployer un fichier YAML, lire un statut de pod — n’est pas le même exercice que d’opérer un cluster soi-même. Il faut connaître ce qui tourne en dessous pour diagnostiquer quand ça casse. Cinq concepts servent de boussole pendant tout le parcours.

Le control plane est l’orchestrateur. Il est composé de l’API server (point d’entrée HTTPS unique), d’etcd (la base clé-valeur qui stocke l’état désiré du cluster), du scheduler (qui choisit sur quel nœud placer chaque pod) et du controller manager (qui boucle pour rapprocher l’état réel de l’état désiré). En haute disponibilité, on en déploie trois copies. C’est la couche qu’on doit absolument sauvegarder, parce que perdre etcd revient à perdre la déclaration entière du cluster.

Le kubelet est l’agent installé sur chaque worker. Il discute avec l’API server, demande quels pods il doit faire tourner, parle au runtime de conteneurs (containerd dans toutes les distributions modernes) et remonte la santé du nœud. Quand un pod est Pending sans raison apparente, c’est presque toujours soit un problème d’API server, soit un kubelet qui n’a pas pu démarrer, soit une mauvaise classe de stockage.

Le CNI (Container Network Interface) est la couche qui donne une adresse IP à chaque pod et qui route les paquets entre nœuds. Cilium, qu’on installera, utilise eBPF pour faire ce travail directement dans le kernel Linux : c’est rapide, observable et programmable. Le choix du CNI est structurant parce qu’on ne le change pas en cours de route sans douleur.

Le CSI (Container Storage Interface) est l’équivalent pour le stockage. Les drivers CSI exposent du stockage à Kubernetes sous forme de StorageClass et de PersistentVolumeClaim. Rook-Ceph fournira un driver CSI qui crée à la demande des volumes RBD (blocs) ou CephFS (fichier partagé). Sans CSI, on ne peut faire tourner que des charges éphémères.

L’Ingress enfin est ce qui expose les services HTTPS au monde extérieur. Un Ingress controller (souvent Nginx, Traefik ou ingress-nginx) traduit les règles déclaratives en configuration de reverse proxy. C’est par là que vos applications répondent à https://gitea.exemple.lan plutôt qu’à 10.96.42.17:3000.

Trois décisions structurantes qu’il faut prendre tôt

Avant d’écrire le moindre fichier YAML, trois choix conditionnent l’expérience qu’on aura. Les remettre en cause à mi-parcours coûte cher. Mieux vaut les trancher en connaissance de cause.

Système d’exploitation des nœuds : Talos ou Ubuntu ? Talos Linux 1.13 est immuable, sans shell, sans paquets traditionnels, configuré entièrement par fichier YAML déclaratif et géré à distance par l’outil talosctl. C’est le choix qu’on fait quand on accepte de ne plus jamais ouvrir de session SSH sur un nœud. La récompense : surface d’attaque minuscule, mises à jour atomiques, rollback en une commande, comportement reproductible. Ubuntu 24.04 LTS combiné à kubeadm est le choix opposé : on garde un Linux familier, on installe les paquets soi-même, on opère par SSH. C’est plus pédagogique au début et plus tolérant aux ajustements manuels, mais on porte la sécurité du système sur ses épaules.

Distribution Kubernetes : kubeadm ou k3s ? kubeadm est l’outil de référence du projet Kubernetes, utilisé sur Talos comme sur Ubuntu, qui produit un cluster « standard ». k3s est une distribution allégée portée par SUSE, packagée en un seul binaire, qui démarre en moins d’une minute et tient dans 512 Mio de RAM par nœud. k3s embarque par défaut Flannel comme CNI, Traefik comme Ingress et SQLite comme stockage etcd remplaçable. Le tutoriel comparatif détaille les compromis ; en règle générale, k3s gagne pour l’apprentissage rapide ou les nœuds très contraints, kubeadm gagne pour rester proche de ce qu’on retrouve en production d’entreprise.

Stockage : ZFS local sur Proxmox ou Ceph distribué via Rook ? Pour un single node, ZFS local sur Proxmox suffit largement et offre des snapshots instantanés très utiles. Pour préparer des charges qui doivent survivre à la perte d’un nœud, Rook-Ceph apporte une vraie réplication à trois copies entre workers, du stockage objet S3-compatible et un système de fichiers partagé. Beaucoup de configurations domestiques combinent les deux : ZFS sous l’hyperviseur pour les disques des VM, Rook-Ceph dans Kubernetes pour les volumes persistants des charges utiles.

La sécurité de base à appliquer dès le départ

Un cluster Kubernetes non sécurisé exposé sur Internet est compromis en quelques heures, même chez soi derrière un routeur grand public. L’erreur classique consiste à ouvrir le port 6443 vers l’extérieur pour accéder à kubectl en déplacement : c’est ouvrir l’API server au monde entier. Quatre garde-fous se mettent en place dès la première installation et restent jusqu’à la fin de vie du cluster.

D’abord, l’isolement réseau : le cluster vit sur un VLAN dédié de son réseau domestique, distinct du Wi-Fi familial. L’accès depuis l’extérieur passe exclusivement par un VPN (WireGuard sur le routeur ou Tailscale sur chaque nœud). Aucune redirection de port direct vers les nœuds.

Ensuite, la rotation des secrets : Talos régénère ses certificats internes automatiquement ; sur Ubuntu+kubeadm, prévoir kubeadm certs renew tous les onze mois. Les kubeconfig admin distribués à des appareils mobiles doivent avoir une durée de vie courte (quelques jours) et être révocables.

Les politiques d’admission, ensuite, refusent par défaut les pods privilégiés. On active le Pod Security Admission en mode restricted sur tous les namespaces métier, et on ajoute OPA Gatekeeper ou Kyverno pour les règles spécifiques (interdire les images non signées, forcer les resources.limits, refuser les services exposés en NodePort).

Enfin, l’observabilité de la sécurité : Falco surveille les syscalls suspectes au niveau du noyau, Trivy scanne les images au déploiement. Le tutoriel Falco runtime security et audit Kubernetes détaille cette couche, qui s’installe une fois le cluster productif.

Erreurs fréquentes qu’on rencontre tous

Questions qui reviennent souvent

Est-ce que Proxmox est obligatoire, on ne pourrait pas installer Kubernetes en bare-metal ? C’est tout à fait possible. La couche d’hyperviseur n’est utile que pour découper un même serveur physique en plusieurs nœuds logiques, faire des snapshots faciles, et tester rapidement des configurations. En bare-metal sur trois machines physiques séparées, on saute Proxmox et on installe Talos directement sur chaque hôte. Le reste du parcours reste identique.

Quelle distribution Kubernetes consomme le moins de RAM ? k3s est sans concurrence sur ce critère. Un nœud k3s avec une charge légère tient sur 512 Mio de RAM. Pour comparaison, un nœud kubeadm démarre rarement en dessous d’un Gio, et un nœud Talos+kubeadm autour de 1,5 Gio.

Faut-il vraiment trois control plane, ou un seul suffit chez soi ? Un seul control plane fonctionne parfaitement pour apprendre. La perte de ce nœud arrête le cluster mais ne perd pas les données. Pour héberger des services qu’on ne veut pas voir tomber pendant les pannes électriques ou les redémarrages, trois control plane apportent la haute disponibilité d’etcd. Le coût en RAM est raisonnable : trois fois deux Gio.

Peut-on faire tourner du GPU dans ce cluster ? Oui, à condition de passer le GPU à une VM via PCI passthrough Proxmox, puis d’installer le NVIDIA device plugin Kubernetes dans cette VM. C’est utile pour héberger des modèles d’inférence locaux ou faire du transcoding vidéo. La configuration IOMMU côté Proxmox doit être faite avant la création de la VM.

À quelle fréquence faut-il mettre à jour ? Kubernetes sort une mineure tous les quatre mois. Sur du domestique, une montée par semestre suffit largement. Talos rend ces montées presque indolores avec sa procédure d’upgrade atomique. Sur kubeadm, prévoir une à deux heures par montée.

Le bruit et la consommation électrique sont-ils gérables en appartement ? Avec un mini-PC moderne en boîtier sans ventilateur ou en ventilateur PWM, le bruit est inférieur à 25 dB et la consommation tourne entre 12 et 30 W au repos. C’est compatible avec un salon. Les vrais serveurs rack sont à proscrire pour des raisons sonores.

Ressources et références officielles

• Documentation Proxmox VE 9 : pve.proxmox.com/pve-docs
• Notes de version Proxmox VE 9.1 : proxmox.com
• Documentation Talos Linux : talos.dev/v1.13
• Documentation officielle Kubernetes 1.35 : kubernetes.io/docs
• k3s release notes : docs.k3s.io
• Cilium documentation : docs.cilium.io/v1.19
• Rook documentation : rook.io
• Argo CD documentation : argo-cd.readthedocs.io
• kube-prometheus-stack chart : prometheus-community sur GitHub
• Velero documentation : velero.io/docs

Une fois le cluster productif, par où continuer

Atteindre la fin du parcours en huit tutoriels donne un cluster fonctionnel, sauvegardé, observé, et qui se déploie depuis un dépôt Git. C’est un point d’arrivée raisonnable. Mais c’est aussi un point de départ pour aller plus loin, parce que la vraie valeur d’une plateforme se révèle dans ce qu’on déploie au-dessus et dans la rigueur opérationnelle qu’on y apporte au fil des mois.

La première extension naturelle concerne la sécurité durcie. Une fois Cilium en place, on active Cilium Network Policies par défaut deny pour chaque namespace métier, on installe Falco pour la détection de comportements anormaux au niveau du noyau, on met Trivy ou Grype dans la chaîne CI pour scanner les images avant push, et on signe les images avec Cosign pour vérifier l’origine au déploiement. Le cluster CKS (Certified Kubernetes Security Specialist) déjà publié sur ce blog couvre chacune de ces briques avec des tutoriels dédiés.

La seconde extension concerne le réseau et l’exposition. Pour rendre des services accessibles depuis l’extérieur sans ouvrir directement le routeur, on installe MetalLB (load balancer logiciel) ou Cilium en mode L2 announcement, puis cert-manager qui obtient automatiquement des certificats Let’s Encrypt. Pour les charges qui sortent vers l’extérieur, on configure un egress gateway Cilium qui force tout le trafic sortant à passer par une IP dédiée — utile quand on s’authentifie chez des fournisseurs qui filtrent par IP source.

La troisième extension concerne les charges réelles à héberger. Gitea ou Forgejo pour le code et la CI, Vaultwarden pour les mots de passe, Nextcloud pour le partage de fichiers, Immich pour les photos, Paperless-ngx pour les documents, Jellyfin pour le multimédia familial. Chacune devient une Application Argo CD synchronisée depuis le dépôt Git, avec des volumes persistants Rook et des sauvegardes Velero programmées chaque nuit. C’est à ce moment qu’on récolte le bénéfice du parcours initial : ajouter un nouveau service prend dix minutes et un commit, pas une journée d’installation manuelle.

La quatrième extension concerne la résilience matérielle. Si l’on a démarré sur un seul nœud Proxmox, c’est l’occasion de passer à trois hôtes Proxmox en cluster avec migration live des VM, de remplacer le bridge réseau par un OVS avec VLAN dédié, et de poser un onduleur (UPS) qui pilote l’arrêt propre des nœuds via NUT. Ces étapes sont rarement faites au début parce qu’elles n’apportent pas de fonctionnalité visible, mais elles déterminent la durée de vie réelle du cluster.