Architecture et choix

01Vue d'ensemble

La plateforme tient dans un cluster Proxmox VE de quatre noeuds avec Ceph. Elle porte deux clusters Kubernetes, chacun dans son propre réseau privé, et une VM routeur qui fait le lien avec Internet.

                     Internet
                        |
        203.0.113.35   sortie et WireGuard
        203.0.113.47   ingress demo
        203.0.113.51   ingress mgmt
                        |
             +----------------------+
             |      VM routeur      |  nftables :
             |  Debian, HA Proxmox  |  NAT, DNAT, hairpin
             +----------------------+
                 |              |
      VXLAN 10.20.0.0/24   VXLAN 10.20.1.0/24
      +---------------+    +--------------------+
      | cluster mgmt  |    | cluster demo       |
      | Rancher       |    | 3 control planes   |
      | Argo CD       |    | 2 workers          |
      | Renovate      |    | applications       |
      +---------------+    +--------------------+
                 \              /
              Ceph du cluster Proxmox (pool k8s)

02Pourquoi Talos Linux

Talos est un système conçu pour une seule chose : faire tourner Kubernetes. Pas de shell, pas de SSH, pas de gestionnaire de paquets. Tout passe par une API, et la configuration d'un noeud est un document YAML déclaratif. Les mises à jour remplacent le système entier, avec retour arrière automatique si le noeud ne redémarre pas.

Pour une plateforme qui doit se mettre à jour seule, c'est exactement ce qu'il faut : il n'y a rien à dériver, rien à bricoler à la main, et un noeud se reconstruit en deux minutes. L'absence de SSH déroute la première semaine, comme un super-héros à qui l'on aurait confisqué sa cape. La deuxième semaine, on ne veut plus revenir en arrière.

L'image des VM vient de l'Image Factory de Talos, au format nocloud pour l'initialisation par cloud-init, avec l'extension qemu-guest-agent pour que Proxmox voie l'adresse des VM et les arrête proprement.

03Deux clusters plutôt qu'un

Un cluster qui se gère lui-même a un défaut : le jour où il tombe, ses outils de gestion tombent avec lui. Nous séparons donc :

• le cluster demo, qui porte les applications et rien d'autre ;
• le cluster mgmt, le QG, qui héberge Rancher, Argo CD et Renovate, et pilote demo à distance.

Si demo casse, la console et le GitOps restent debout pour le réparer. Et l'on peut ajouter demain un cluster de production sans réinstaller les outils.

04Réseau : SDN VXLAN et routeur

Les noeuds Proxmox sont reliés par un réseau privé (le vRack chez OVH, un VLAN dédié ailleurs) en MTU 9000. Le SDN de Proxmox y crée une zone VXLAN, et un VNet par cluster. L'encapsulation VXLAN coûte 50 octets : la zone et les interfaces des VM sont donc en MTU 8950, sans quoi les gros paquets disparaissent sans bruit.

Petite convention qui évite bien des recherches : l'identifiant de chaque VM vaut VNI × 1000 + dernier octet de son IP. Le premier control plane de demo, en 10.20.1.11, est donc la VM 5001011.

Une VM routeur Debian relie ces réseaux à Internet. Elle porte les IP publiques, fait le NAT sortant, redirige les ports 80 et 443 de chaque IP d'ingress vers le cluster concerné, et termine le tunnel WireGuard du poste d'administration. C'est un point unique, protégé par la haute disponibilité de Proxmox : si son hôte tombe, elle redémarre ailleurs en deux minutes.

table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat;
    # ingress demo : l'IP publique vers l'adresse de service de Traefik
    ip daddr 203.0.113.47 tcp dport { 80, 443 } dnat to 10.20.1.100
  }
  chain postrouting {
    type nat hook postrouting priority srcnat;
    # hairpin : un pod qui appelle l'IP publique de son propre cluster
    ip saddr 10.20.1.0/24 ip daddr 10.20.1.100 masquerade
    # sortie de tous les clusters par une seule IP
    ip saddr 10.20.0.0/16 oifname "eth0" snat to 203.0.113.35
  }
}

Dans le cluster, Cilium attribue l'adresse 10.20.1.100 au service Traefik et l'annonce en ARP sur le VNet : le routeur n'a besoin de rien connaître d'autre. L'IP de sortie unique a un autre avantage : c'est la seule adresse à autoriser chez les fournisseurs externes (API DNS, stockage de sauvegarde).

05Stockage : Ceph en direct

Le cluster Proxmox a déjà un Ceph. Plutôt que d'ajouter une couche, les volumes Kubernetes sont des images RBD créées directement par ceph-csi dans un pool dédié, avec un utilisateur Ceph limité à ce pool :

pveceph pool create k8s --application rbd
ceph auth get-or-create client.k8s \
  mon 'profile rbd' osd 'profile rbd pool=k8s' mgr 'profile rbd pool=k8s'

Résultat : des volumes répliqués trois fois, extensibles à chaud, avec instantanés, et une clé qui ne peut rien faire d'autre que gérer les images de son pool.

06Des versions volontairement plafonnées

La version la plus récente n'est pas toujours la plus héroïque. Rancher accepte chaque nouvelle version de Kubernetes avec quelques semaines de retard : sans plafond, la mise à jour automatique pousserait les clusters dans une version que la console refuse. Le chapitre 05 montre comment ces plafonds sont posés, et levés le moment venu.