Quoi ?

• Un cluster Kubernetes sur ProxmoxVE (Kimsufi @OVHcloud)

Quoi ?

• Un cluster Kubernetes sur ProxmoxVE (Kimsufi @OVHcloud)
• Des VMs Talos provisionnées par OpenTofu

Quoi ?

• Un cluster Kubernetes sur ProxmoxVE (Kimsufi @OVHcloud)
• Des VMs Talos provisionnées par OpenTofu
• Un CNI (Container Network Interface) : Cilium

Quoi ?

• Un cluster Kubernetes sur ProxmoxVE (Kimsufi @OVHcloud)
• Des VMs Talos provisionnées par OpenTofu
• Un CNI (Container Network Interface) : Cilium
• Un ingress controller : Traefik

Quoi ?

• Un cluster Kubernetes sur ProxmoxVE (Kimsufi @OVHcloud)
• Des VMs Talos provisionnées par OpenTofu
• Un CNI (Container Network Interface) : Cilium
• Un ingress controller : Traefik
• Une application web pour le fun

Disclaimer

• Ce talk montre un use case
• Proxmox peut être remplacé par une autre plateforme
• OpenTofu peut être remplacé par un autre outil d'IaC
• Talos peut être remplacé par ...
• Ma démo, mes IP, mes domaines = utilisez les vôtres
• ⚠️ On va déployer une 'prod' lite et épurée

Pourquoi Proxmox ?

• Open source, largement adopté

Pourquoi Proxmox ?

• Open source, largement adopté
• Gratuit et pleinement fonctionnel, support entreprise disponible

Pourquoi Proxmox ?

• Open source, largement adopté
• Gratuit et pleinement fonctionnel, support entreprise disponible
• API complète → facilement automatisable avec OpenTofu

Pourquoi Proxmox ?

• Open source, largement adopté
• Gratuit et pleinement fonctionnel, support entreprise disponible
• API complète → facilement automatisable avec OpenTofu
• Alternative crédible à VMware depuis Broadcom

Pourquoi Proxmox ?

• Open source, largement adopté
• Gratuit et pleinement fonctionnel, support entreprise disponible
• API complète → facilement automatisable avec OpenTofu
• Alternative crédible à VMware depuis Broadcom
• Basé sur des standards Linux : Debian, KVM, Ceph…

Pourquoi Proxmox ?

• Open source, largement adopté
• Gratuit et pleinement fonctionnel, support entreprise disponible
• API complète → facilement automatisable avec OpenTofu
• Alternative crédible à VMware depuis Broadcom
• Basé sur des standards Linux : Debian, KVM, Ceph…
• Simple à déployer et à administrer

Info : Proxmox n'est pas requis pour utiliser Talos.

Pourquoi des VMs ?

• pour une démo : je casse, je recrée, je rejoue

Pourquoi des VMs ?

• pour une démo : je casse, je recrée, je rejoue
• pour l'automatisation : OpenTofu pilote Proxmox par API

Pourquoi des VMs ?

• pour une démo : je casse, je recrée, je rejoue
• pour l'automatisation : OpenTofu pilote Proxmox par API
• pour mutualiser : Talos, Linux, Windows sur le même cluster

Pourquoi des VMs ?

• pour une démo : je casse, je recrée, je rejoue
• pour l'automatisation : OpenTofu pilote Proxmox par API
• pour mutualiser : Talos, Linux, Windows sur le même cluster
• pour segmenter : qualif, démo, test, chacun son cluster Kubernetes

Pourquoi des VMs ?

• pour une démo : je casse, je recrée, je rejoue
• pour l'automatisation : OpenTofu pilote Proxmox par API
• pour mutualiser : Talos, Linux, Windows sur le même cluster
• pour segmenter : qualif, démo, test, chacun son cluster Kubernetes
• et si besoin : Talos fonctionne aussi en bare metal

Pourquoi OpenTofu ?

• Infrastructure déclarative

Pourquoi OpenTofu ?

• Infrastructure déclarative
• Plan avant application

Pourquoi OpenTofu ?

• Infrastructure déclarative
• Plan avant application
• Reproductible & versionnable

Pourquoi OpenTofu ?

• Infrastructure déclarative
• Plan avant application
• Reproductible & versionnable
• Automatisable / CI-CD

Pourquoi OpenTofu ?

• Infrastructure déclarative
• Plan avant application
• Reproductible & versionnable
• Automatisable / CI-CD
• Écosystème de providers & modules

Pourquoi OpenTofu ?

• Infrastructure déclarative
• Plan avant application
• Reproductible & versionnable
• Automatisable / CI-CD
• Écosystème de providers & modules
• Open source (Linux Foundation)

Info : OpenTofu n'est pas requis pour utiliser Talos.

Bring your own stack

Proxmox + OpenTofu + Talos, c'est mon use case.

• Proxmox → VMware, Bare metal, Cloud, ...

Bring your own stack

Proxmox + OpenTofu + Talos, c'est mon use case.

• Proxmox → VMware, Bare metal, Cloud, ...
• OpenTofu → Pulumi, Ansible, Puppet, Crossplane, ...

Bring your own stack

Proxmox + OpenTofu + Talos, c'est mon use case.

• Proxmox → VMware, Bare metal, Cloud, ...
• OpenTofu → Pulumi, Ansible, Puppet, Crossplane, ...
• Talos → Talos

Bring your own stack

Proxmox + OpenTofu + Talos, c'est mon use case.

• Proxmox → VMware, Bare metal, Cloud, ...
• OpenTofu → Pulumi, Ansible, Puppet, Crossplane, ...
• Talos → Talos
• Cilium → Flannel, Calico, ... avec adaptation de kube-proxy

Bring your own stack

Proxmox + OpenTofu + Talos, c'est mon use case.

• Proxmox → VMware, Bare metal, Cloud, ...
• OpenTofu → Pulumi, Ansible, Puppet, Crossplane, ...
• Talos → Talos
• Cilium → Flannel, Calico, ... avec adaptation de kube-proxy
• Traefik → HAproxy, Envoy Gateway, Kong, ...

Talos n'impose pas une plateforme, il standardise le nœud Kubernetes.

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert
• Comptes locaux

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert
• Comptes locaux
• Shell root

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert
• Comptes locaux
• Shell root
• Paquets installables

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert
• Comptes locaux
• Shell root
• Paquets installables
• Configuration modifiable à la main

Et sans Talos ?

Sur un OS classique, le nœud peut devenir un objet que l'on corrige à la main :

• SSH ouvert
• Comptes locaux
• Shell root
• Paquets installables
• Configuration modifiable à la main
• Drift invisible

Le port 22 c'est pratique, comme une porte de garage ouverte.

La dérive silencieuse

Une fois connecté, tout devient modifiable sans laisser de trace :

• Kubelet et container runtime → ce qui fait tourner les conteneurs

La dérive silencieuse

Une fois connecté, tout devient modifiable sans laisser de trace :

• Kubelet et container runtime → ce qui fait tourner les conteneurs
• Certificats → l'identité du cluster

La dérive silencieuse

Une fois connecté, tout devient modifiable sans laisser de trace :

• Kubelet et container runtime → ce qui fait tourner les conteneurs
• Certificats → l'identité du cluster
• Kernel et systemd → le système entier

La dérive silencieuse

Une fois connecté, tout devient modifiable sans laisser de trace :

• Kubelet et container runtime → ce qui fait tourner les conteneurs
• Certificats → l'identité du cluster
• Kernel et systemd → le système entier
• Règles réseau → le pare-feu

La dérive silencieuse

Une fois connecté, tout devient modifiable sans laisser de trace :

• Kubelet et container runtime → ce qui fait tourner les conteneurs
• Certificats → l'identité du cluster
• Kernel et systemd → le système entier
• Règles réseau → le pare-feu
• Des fichiers changés « juste pour tester »

La dette technique devient une surface d'attaque.

Un risque, pas une fatalité : un cluster sur OS classique peut être impeccable.

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)
• Configuration déclarative et versionnable

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)
• Configuration déclarative et versionnable
• Bootstrap reproductible

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)
• Configuration déclarative et versionnable
• Bootstrap reproductible
• Upgrades Talos et Kubernetes

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)
• Configuration déclarative et versionnable
• Bootstrap reproductible
• Upgrades Talos et Kubernetes
• Health checks intégrés

Pourquoi Talos ?

C'est un OS spécialisé pour Kubernetes qui apporte une expérience proche du K8s managé :

• API pour piloter les nœuds (et CLI dédiée : talosctl)
• Configuration déclarative et versionnable
• Bootstrap reproductible
• Upgrades Talos et Kubernetes
• Health checks intégrés
• Peu de colle maison autour du lifecycle

Installable presque partout : Proxmox, VMware, bare metal, cloud, ...

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS
• Pas de SSH ni de shell interactif

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS
• Pas de SSH ni de shell interactif
• Configuration déclarative et auditable

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS
• Pas de SSH ni de shell interactif
• Configuration déclarative et auditable
• Système immuable

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS
• Pas de SSH ni de shell interactif
• Configuration déclarative et auditable
• Système immuable
• Base pensée pour les recommandations CIS

Et côté sécurité ?

Il réduit la surface d'attaque du système hôte :

• Accès admin uniquement via API mTLS
• Pas de SSH ni de shell interactif
• Configuration déclarative et auditable
• Système immuable
• Base pensée pour les recommandations CIS
• Pod Security Admission activé par défaut : Baseline imposé, Restricted en warning/audit
• Conçu pour limiter le drift

Sécurité by design

Par contre ...

Il ne remplace pas une bonne hygiène de sécurité :

• NetworkPolicies
• Gestion des secrets
• Scans d'images
• Bon sens en production
• ...

Architecture de la démo

Serveur Proxmox
  |-- talos-cp-1    10.10.10.101
  |-- talos-cp-2    10.10.10.102
  |-- talos-cp-3    10.10.10.103
  |-- talos-wkr-1   10.10.10.111
  |-- VIP API       10.10.10.10
  `-- Traefik LB    10.10.10.200

La démo en 5 étapes

opentofu/talos/
  01-proxmox-talos/          # VMs + Talos + bootstrap K8s
  02-cilium-traefik/         # Cilium + Traefik via Helm/OpenTofu
  03-deploy-application/     # App whoami via OpenTofu/Kubernetes provider
  04-add-talos-worker-node/  # Ajout d'un worker Talos
  05-upgrade-talos-and-k8s/  # Upgrade Talos + Kubernetes
  scripts/                   # Runbook exécutable de démo

• proxmox.tf : VMs, disque, réseau, image Talos
• talos.tf : MachineConfig, bootstrap, kubeconfig
• helm.tf : Cilium et Traefik
• upgrade.env : versions cibles Talos et Kubernetes

Démo 1 : créer le cluster Kubernetes

./scripts/01-proxmox-talos.sh

On part d'un Proxmox vide et on arrive à un cluster Kubernetes utilisable.

• tofu init, tofu plan, tofu apply
• Création des VMs Proxmox
• Application des MachineConfigs Talos
• Bootstrap etcd/Kubernetes
• Export talosconfig et kubeconfig

Démo 2 : ajouter un CNI et un ingress controller

./scripts/02-cilium-traefik.sh

Talos démarre Kubernetes sans CNI.

• tofu init, tofu plan, tofu apply
• Les composants sont installés via Helm
• Cilium remplace kube-proxy
• Cilium annonce l'IP LoadBalancer en L2
• Traefik est exposé sur 10.10.10.200
• CoreDNS est configuré pour se répartir sur plusieurs nœuds

Démo 3 : déployer une application

./scripts/03-deploy-application.sh

On peut déployer ce qu'on veut comme application.

• tofu init, tofu plan, tofu apply
• Namespace whoami
• Deployment whoami, 3 réplicas
• Service ClusterIP
• IngressRoute Traefik
• Host demo-meetup.calmops.fr

Démo 4 : ajouter un nœud worker

./scripts/04-add-talos-worker-node.sh

Ajouter un nœud, c'est une commande.

• tofu init, tofu plan, tofu apply
• Crée la VM Proxmox du nouveau worker
• Réutilise les secrets Talos du cluster
• Applique la MachineConfig worker
• Vérifie l'arrivée du nœud

Démo 5 : mettre à jour Talos + Kubernetes

./scripts/05-upgrade-talos.sh
./scripts/05-upgrade-k8s.sh

Créer c'est bien, gérer le cycle de vie c'est mieux.

• talosctl upgrade -n <NODE_IP> --image <TALOS_IMAGE> --preserve
• talosctl -n <NODE_IP> upgrade-k8s --to <K8S_VERSION>
• Paramètres dans 05-upgrade-talos-and-k8s/upgrade.env
• 05-upgrade-talos.sh met à jour talosctl, puis lance talosctl upgrade
• 05-upgrade-k8s.sh met à jour kubectl, puis lance talosctl upgrade-k8s
• Vérification avec talosctl health et kubectl get nodes

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées
• State OpenTofu distant

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées
• State OpenTofu distant
• Secrets hors repo

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées
• State OpenTofu distant
• Secrets hors repo
• Supervision, logs, alerting

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées
• State OpenTofu distant
• Secrets hors repo
• Supervision, logs, alerting
• Politique d'upgrade et PRA documentés

Et maintenant si on veut mettre en prod ?

• Un vrai cluster Proxmox
• Sauvegarde et restauration etcd testées
• State OpenTofu distant
• Secrets hors repo
• Supervision, logs, alerting
• Politique d'upgrade et PRA documentés
• ...

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.
2. OpenTofu rend le déploiement rejouable, auditable et versionnable.

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.
2. OpenTofu rend le déploiement rejouable, auditable et versionnable.
3. Proxmox donne une plateforme simple et API-friendly pour ce use case.

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.
2. OpenTofu rend le déploiement rejouable, auditable et versionnable.
3. Proxmox donne une plateforme simple et API-friendly pour ce use case.
4. Les VMs rendent les clusters éphémères et faciles à multiplier.

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.
2. OpenTofu rend le déploiement rejouable, auditable et versionnable.
3. Proxmox donne une plateforme simple et API-friendly pour ce use case.
4. Les VMs rendent les clusters éphémères et faciles à multiplier.
5. Sécurisé by design ne veut pas dire sécurisé sans discipline.

Ce qu'il faut retenir

1. Talos réduit le drift et la surface d'attaque des nœuds Kubernetes.
2. OpenTofu rend le déploiement rejouable, auditable et versionnable.
3. Proxmox donne une plateforme simple et API-friendly pour ce use case.
4. Les VMs rendent les clusters éphémères et faciles à multiplier.
5. Sécurisé by design ne veut pas dire sécurisé sans discipline.
6. Pour l'équipe : moins de corrections manuelles, des upgrades cadrés, moins de logique maison autour du lifecycle Kubernetes.

Liens : docs

Liens : pour aller plus loin