Kubernetes a une réputation de super-pouvoir qui se retourne contre son porteur. Le cluster monté en suivant un tutoriel tourne très bien le premier mois. Puis une version de Kubernetes sort, un certificat expire, un noeud tombe un dimanche, et l'on découvre que personne ne sait plus comment il a été construit ni s'il se restaure.
Ce guide décrit la plateforme que nous avons construite pour nos clients développeurs : deux clusters Kubernetes sur un cluster Proxmox VE avec Ceph, entièrement décrits dans un dépôt Git, qui se mettent à jour seuls la nuit et dont la sauvegarde a été restaurée. Il ne remplace pas la documentation de chaque outil : il dit ce que nous avons choisi, dans quel ordre, et surtout ce qui nous a coûté du temps.
01À qui s'adresse ce guide
Aux administrateurs qui exploitent déjà Proxmox VE, connaissent les bases de Kubernetes et veulent offrir à leurs développeurs une plateforme où l'on déploie sans ticket. Si votre cluster Proxmox n'est pas encore monté, commencez par notre guide cluster Proxmox VE : tout ce qui suit s'appuie dessus.
Côté développeurs, le guide compagnon déployer ses applications montre la plateforme depuis l'autre côté du guichet.
02La plateforme visée
| Brique | Outil retenu | Rôle |
|---|---|---|
| Système des noeuds | Talos Linux | Immuable, sans SSH, piloté par API |
| Provisionnement | OpenTofu | VM Proxmox et configuration Talos, en code |
| Secrets | SOPS et age | Un seul fichier chiffré, versionné avec le reste |
| Réseau des pods | Cilium | CNI, remplacement de kube-proxy, adresses de service |
| Stockage | ceph-csi | Volumes RBD dans le Ceph de Proxmox |
| Entrée HTTP | Traefik | Ingress, journaux d'accès |
| Certificats et DNS | cert-manager, external-dns | Let's Encrypt et zone DNS automatiques |
| Protection | CrowdSec | Blocage des IP malveillantes devant chaque application |
| Console | Rancher | Interface web, droits des équipes |
| Déploiement | Argo CD | GitOps : le dépôt fait foi |
| Mises à jour | Renovate et tuppr | Proposées le jour, appliquées la nuit |
| Sauvegardes | Velero et talos-backup | Objets, volumes et etcd vers un S3 externe |
03Nos quatre principes
- Tout est code. Une VM, une valeur Helm, une règle d'anti-affinité : si ce n'est pas dans le dépôt, ça n'existe pas. Reconstruire la plateforme complète tient en quatre commandes.
- Aucun secret en clair. Ni dans Git, ni dans l'historique du terminal, ni
dans un fichier temporaire oublié dans
/tmp. - Tout se met à jour, tout le temps. Une plateforme qui ne bouge pas vieillit, et une plateforme qui vieillit finit par se faire visiter.
- Une sauvegarde n'existe que restaurée. Avant, c'est une rumeur.
04Les six chapitres
Architecture et choix
Pourquoi Talos, pourquoi deux clusters, le réseau VXLAN et son routeur, Ceph en direct, et les versions volontairement plafonnées.
CHAPITRE 02Provisionner par le code
Le dépôt, les secrets SOPS, OpenTofu pour les VM et la configuration Talos, la haute disponibilité Proxmox avec anti-affinité.
CHAPITRE 03Le socle du cluster
Cilium, ceph-csi, Traefik, cert-manager, external-dns et CrowdSec, installés par un script idempotent dans le bon ordre.
CHAPITRE 04Rancher et Argo CD
Un cluster de gestion, la console Rancher pour les humains, Argo CD pour que le dépôt fasse foi, et les accès des développeurs.
CHAPITRE 05Mises à jour automatiques
Renovate propose chaque version en merge request, tuppr met à jour Talos et Kubernetes la nuit, un noeud à la fois.
CHAPITRE 06Sauvegardes et reprise
Un S3 Garage hors du cluster, Velero pour les objets et les volumes, etcd chiffré toutes les six heures, et les restaurations.
05Ce que ce guide ne couvre pas
- L'observabilité (métriques, tableaux de bord, alertes sur les sauvegardes et les mises à jour) et le durcissement des accès (authentification unique avec double facteur, revue de l'accès à Proxmox). Ces deux briques feront l'objet d'une page dédiée.
- Le dépôt complet, ligne à ligne. Ce guide montre l'architecture et les extraits qui
comptent ; les valeurs d'exemple (
exemple.fr, adresses203.0.113.xréservées à la documentation) sont à remplacer par les vôtres. - Les clusters managés des grands fournisseurs : très bien, mais ce n'est pas le sujet.
Une plateforme Kubernetes, sans y laisser vos nuits
Nous concevons, montons et exploitons des plateformes Kubernetes sur Proxmox VE pour des équipes qui veulent se consacrer à leur code : mises à jour nocturnes, sauvegardes testées, déploiement en GitOps. Reprise d'un cluster existant, plateforme clé en main ou astreinte : nous intervenons au forfait comme au long cours.