Posts on Matteo ZINUTTI

Passer un GPU NVIDIA dans un cluster Kubernetes

Fri, 09 Oct 2026 00:00:00 +0000

Série “Un cluster Kubernetes avec GPU pour faire de l’inférence LLM”

Déployer un cluster Kubernetes immuable avec Talos sur Proxmox

Passer un GPU NVIDIA dans un cluster Kubernetes (cet article)

Piloter un cluster Kubernetes en GitOps avec Flux (En cours d’écriture)

Inférence LLM auto-hébergée sur Kubernetes (En cours d’écriture)

Introduction

Le cluster Talos déployé dans la partie 1 est opérationnel, mais le nœud talos-gpu-01 ne voit pour l’instant aucune carte graphique. Dans cet article, je détaille comment j’ai rendu une GeForce RTX 3050 utilisable par les pods Kubernetes, en partant de l’hôte Proxmox. Le travail se découpe en quatre étapes : détacher la carte de l’hôte, l’attacher à la VM avec OpenTofu, charger les modules NVIDIA dans Talos, puis exposer le GPU au scheduler Kubernetes.

Le chemin du GPU, de l'hôte Proxmox au pod Kubernetes

Avant de passer aux commandes, j’explique ce que fait le passthrough, d’où viennent la plupart des contraintes rencontrées ensuite, comme la désactivation du ballooning ou la vérification des groupes IOMMU.

Contexte

L’objectif final de cette série est de faire tourner de l’inférence LLM en local dans mon homelab, ce qui demande un GPU accessible depuis le cluster. Pour donner une carte graphique à une VM, il existe deux grandes approches : la partager entre plusieurs VMs avec du vGPU, ou la dédier entièrement à une seule VM avec du PCI passthrough.

Dans mon cas, le choix était vite fait. NVIDIA ne propose le vGPU que sur ses gammes datacenter et professionnelles, il n’est pas disponible sur une GeForce. Il reste donc le passthrough, avec une conséquence directe : la carte est dédiée à la VM talos-gpu-01, l’hôte Proxmox n’y a plus accès et aucune autre VM ne peut la partager.

Le matériel utilisé est une GeForce RTX 3050 que j’avais sous la main.

Prérequis

Un CPU et une carte mère supportant l’IOMMU (VT-d chez Intel, AMD-Vi chez AMD), activée dans le BIOS.
Le cluster Talos de la partie 1.
Un GPU qui n’est pas utilisé pour l’affichage de l’hôte. Dans mon cas, l’hôte Proxmox tourne sans écran et le GPU intégré du processeur est désactivé dans le BIOS, la RTX 3050 est donc la seule carte graphique de la machine.

Comprendre le passthrough

Un périphérique PCIe comme un GPU ne passe pas par le CPU pour lire ou écrire en mémoire. Il utilise le DMA (Direct Memory Access) pour accéder directement à la RAM, ce qui lui permet de transférer de gros volumes de données sans occuper le processeur.

Dans une VM, ce fonctionnement pose un problème. Les adresses mémoire que voit le système invité sont des adresses physiques invité (GPA, Guest Physical Address), qui ne correspondent pas aux adresses physiques réelles de l’hôte (HPA, Host Physical Address). Pour les accès du CPU, la traduction GPA vers HPA est faite par le matériel grâce à EPT (Extended Page Tables) chez Intel ou NPT (Nested Page Tables) chez AMD, une seconde table de pages que le processeur parcourt en plus de celle de l’invité. Un périphérique qui fait du DMA ne passe pas par cette traduction : si le driver de la VM donne une adresse GPA au GPU, la carte écrit à cette adresse dans la RAM de l’hôte, qui correspond à tout autre chose.

C’est le rôle de l’IOMMU (Input-Output Memory Management Unit). Elle fait pour les périphériques ce que la MMU (Memory Management Unit), le composant du processeur qui traduit les adresses virtuelles en adresses physiques, fait pour le CPU : elle traduit les adresses utilisées par le périphérique en adresses physiques réelles, et elle limite le périphérique aux zones mémoire qui lui ont été attribuées. Le GPU passé à la VM ne peut donc écrire que dans la mémoire de cette VM.

Cette isolation ne se fait pas par périphérique mais par groupe IOMMU. Un groupe rassemble les périphériques que le matériel n’est pas capable d’isoler les uns des autres, par exemple parce qu’ils peuvent communiquer entre eux sans passer par l’IOMMU. L’unité qu’on peut passer à une VM est donc le groupe entier, et il faut vérifier le contenu du groupe de la carte avant de commencer.

Enfin, côté hôte, la carte ne doit être prise par aucun driver graphique (nouveau ou nvidia). C’est le driver vfio-pci qui en prend possession. Il fait partie de VFIO (Virtual Function I/O), le framework du noyau Linux qui donne à un programme hors du noyau, ici QEMU, l’accès direct à un périphérique, en s’appuyant sur l’IOMMU pour limiter ce que le périphérique peut atteindre en mémoire. C’est par ce biais que QEMU présente la carte à la VM.

Traduction d'adresses : accès CPU et accès DMA du GPU

Pourquoi le ballooning doit être désactivé

Le ballooning permet à Proxmox de récupérer à chaud de la RAM inutilisée par une VM, grâce à un driver présent dans l’invité qui rend des pages mémoire à l’hôte. Avec un périphérique passé via VFIO, ce mécanisme ne peut plus fonctionner : le GPU peut écrire à tout moment dans les pages de la VM sans passer par le CPU, donc l’hôte n’a aucun moyen de savoir si une page est encore utilisée par la carte. Toute la mémoire de la VM est donc épinglée (pinned) au démarrage et ne peut plus être rendue à l’hôte.

Dans le provider bpg/proxmox, c’est l’argument floating du bloc memory qui contrôle le ballooning, et la valeur 0 le désactive. Je l’ai mis à 0 dans la ressource qui crée les nœuds Talos, donc sur les trois nœuds et pas uniquement sur le nœud GPU :

1
2
3
4
5


#talos.tf
memory {
 dedicated = each.value.memory
 floating = 0
}

Cela a une conséquence sur le dimensionnement : les 12 GB de RAM du nœud talos-gpu-01 sont réservés en permanence sur l’hôte, même quand le nœud ne fait rien.

Maintenant que le fonctionnement est posé, passons à la préparation de l’hôte Proxmox.

Étape 1 : préparer l’hôte Proxmox

Vérifier l’IOMMU et les groupes

La première chose à faire est d’identifier la carte et le groupe IOMMU auquel elle appartient :

1
2
3
4
5


# La carte et ses fonctions
lspci -nn | grep -i nvidia

# Le groupe IOMMU auquel elle appartient
find /sys/kernel/iommu_groups -type l | grep '01:00'

Ce qui donne dans mon cas :

1
2
3
4
5


01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [Geforce RTX 3050] [10de:2507] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA106 High Definition Audio Controller [10de:228e] (rev a1)

/sys/kernel/iommu_groups/10/devices/0000:01:00.0
/sys/kernel/iommu_groups/10/devices/0000:01:00.1

La carte expose deux fonctions : 01:00.0 pour la partie vidéo et 01:00.1 pour le contrôleur audio HDMI. Les deux sont seules dans le groupe IOMMU 10, ce qui veut dire que le groupe peut être passé à la VM tel quel, sans embarquer d’autre périphérique de l’hôte.

Si d’autres périphériques partageaient ce groupe, par exemple un contrôleur USB, il faudrait les passer eux aussi à la VM. Le patch ACS override est souvent proposé sur les forums pour découper artificiellement les groupes, mais il demande au noyau d’ignorer une isolation que le matériel ne garantit pas, les périphériques du groupe pouvant toujours communiquer entre eux. Le wiki Proxmox le présente d’ailleurs comme une dernière option, qui n’est pas sans risques.

Attacher la carte à vfio-pci

J’ai configuré l’hôte Proxmox pour que vfio-pci prenne la carte avant tout autre driver. Cette partie n’est pas gérée par mon code OpenTofu, je l’ai faite directement sur l’hôte Proxmox.

D’après la documentation Proxmox, l’IOMMU est activée par défaut sur Intel à partir du noyau 6.8, l’option intel_iommu=on que l’on trouve dans beaucoup de guides n’est donc plus nécessaire. Le seul paramètre utile est iommu=pt, qui limite la traduction d’adresses aux périphériques passés à une VM et peut améliorer les performances des autres.

Les paramètres du noyau se passent par la ligne de commande que GRUB, le chargeur de démarrage de l’hôte, transmet au noyau à chaque boot. Quand l’hôte démarre avec GRUB, ce qui est mon cas, elle se définit dans /etc/default/grub :

1
2


#/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt"

GRUB_CMDLINE_LINUX_DEFAULT s’applique aux entrées de démarrage normales, mais pas au mode de récupération. quiet est présent par défaut sur Debian et Proxmox : il réduit les messages du noyau affichés à l’écran pendant le démarrage, sans rien changer à ce qui est enregistré dans les logs.

Le dmesg de l’hôte confirme que l’IOMMU est active, avec le mode passthrough demandé, et que les périphériques sont répartis en groupes IOMMU :

1
2
3


[ 0.284240] iommu: Default domain type: Passthrough (set via kernel command line)
[ 0.329656] pci 0000:00:00.0: Adding to iommu group 0
[ 0.329665] pci 0000:00:01.0: Adding to iommu group 1

Les modules VFIO sont chargés au démarrage via /etc/modules : vfio pour le cœur du framework, vfio_iommu_type1 pour piloter l’IOMMU, et vfio_pci pour les périphériques PCI :

1
2
3
4


#/etc/modules
vfio
vfio_iommu_type1
vfio_pci

Pour que vfio-pci réserve la carte, je lui donne les identifiants des deux fonctions, la partie vidéo 10de:2507 et la partie audio 10de:228e :

1
2


#/etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:2507,10de:228e disable_vga=1

L’option disable_vga=1 empêche vfio-pci d’exposer les ressources VGA historiques de la carte à l’hôte. En complément, je bloque les drivers graphiques NVIDIA côté hôte pour qu’aucun ne prenne la carte au démarrage :

1
2
3


#/etc/modprobe.d/blacklist.conf
blacklist nouveau
blacklist nvidia*

Les modifications de /etc/modules et de /etc/modprobe.d/ ne sont prises en compte qu’après régénération de l’initramfs (update-initramfs -u -k all), et celles de /etc/default/grub après un update-grub. Après le redémarrage de l’hôte, la vérification se fait avec :

1

lspci -nnk -s 01:00

Ce qui donne dans mon cas :

1
2
3
4
5
6
7
8


01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [Geforce RTX 3050] [10de:2507] (rev a1)
 Subsystem: NVIDIA Corporation GA106 [Geforce RTX 3050] [10de:2507]
 Kernel driver in use: vfio-pci
 Kernel modules: nvidiafb, nouveau
01:00.1 Audio device [0403]: NVIDIA Corporation GA106 High Definition Audio Controller [10de:228e] (rev a1)
 Subsystem: NVIDIA Corporation Device [10de:2507]
 Kernel driver in use: vfio-pci
 Kernel modules: snd_hda_intel

Les deux fonctions sont bien prises par vfio-pci. La ligne Kernel modules liste les drivers capables de gérer la carte, pas ceux qui sont chargés : nouveau et nvidiafb sont bloqués et n’apparaissent pas dans lsmod.

⚠️ Avertissement

Tant que lspci -nnk n’affiche pas Kernel driver in use: vfio-pci sur les deux fonctions, il ne sert à rien de continuer. La VM démarrera peut-être, mais la carte ne sera pas utilisable.

L’hôte est prêt, la carte peut maintenant être attachée à la VM.

Étape 2 : attacher le GPU à la VM avec OpenTofu

Pourquoi un hardware mapping et pas un ID PCI

Le provider bpg/proxmox propose deux manières de déclarer un périphérique dans le bloc hostpci d’une VM : son ID PCI brut avec l’argument id, ou un hardware mapping déclaré au niveau du cluster Proxmox avec l’argument mapping.

La documentation du provider précise que id n’est pas compatible avec une authentification par token API et qu’il demande le compte root avec son mot de passe. Toute mon IaC s’authentifie avec le token de l’utilisateur terraform@pve, je suis donc parti sur le mapping, qui était la seule option sans changer l’authentification du provider.

Le mapping est déclaré avec la ressource proxmox_hardware_mapping_pci :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


#hardware_mapping.tf
resource "proxmox_hardware_mapping_pci" "this" {
 ...
 for_each = var.pci_hardware_mappings

 name = each.key
 comment = each.value.comment

 map = [
 {
 node = coalesce(each.value.node, var.proxmox_node)
 path = each.value.path
 id = each.value.id
 iommu_group = each.value.iommu_group
 subsystem_id = each.value.subsystem_id
 }
 ]
}

Les valeurs sont renseignées dans les variables :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#variables.auto.tfvars
pci_hardware_mappings = {
 gpu = {
 comment = "GeForce RTX 3050 - managed by Terraform"
 path = "0000:01:00"
 id = "10de:2507"
 iommu_group = 10
 subsystem_id = "10de:2507"
 }
}

Le path est déclaré sans numéro de fonction (0000:01:00 et non 0000:01:00.0), ce qui couvre les deux fonctions de la carte d’un coup.

Les arguments iommu_group et subsystem_id sont optionnels pour l’API, mais sans eux Proxmox affiche le mapping comme incomplet dans l’interface. Je les ai donc renseignés à partir des commandes lspci -nnv -s 0000:01:00 et find /sys/kernel/iommu_groups -type l.

Les privilèges Proxmox

Le rôle utilisé par OpenTofu doit recevoir trois privilèges supplémentaires :

1
2
3
4


#users.tf
"Mapping.Audit",
"Mapping.Modify",
"Mapping.Use",

Mapping.Audit : lire les mappings existants.
Mapping.Modify : créer, modifier et supprimer un mapping.
Mapping.Use : attacher un mapping à une VM, en plus des droits habituels de modification de la VM.

Sans Mapping.Use, le mapping est bien créé mais l’attachement à la VM échoue.

Le bloc hostpci

Côté VM, une seule ressource sert les trois nœuds Talos. Le bloc hostpci est donc dynamique : il est généré à partir de la liste hostpci de chaque nœud, qui vaut [] par défaut. Les deux nœuds sans carte n’ont ainsi aucun périphérique attaché.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


#talos.tf
dynamic "hostpci" {
 for_each = { for device in each.value.hostpci : device.device => device }

 content {
 device = hostpci.value.device
 mapping = proxmox_hardware_mapping_pci.this[hostpci.value.mapping].name
 pcie = hostpci.value.pcie
 rombar = hostpci.value.rombar
 xvga = hostpci.value.xvga
 }
}

Dans la partie 1, j’avais annoncé une sixième validation sur la variable talos_nodes. La voici, elle vérifie que chaque hostpci.mapping correspond bien à un mapping déclaré :

1
2
3
4
5
6
7
8
9


#variables.tf
validation {
 condition = alltrue(flatten([
 for node in var.talos_nodes : [
 for device in node.hostpci : contains(keys(var.pci_hardware_mappings), device.mapping)
 ]
 ]))
 error_message = "Every Talos node hostpci.mapping must be a key of var.pci_hardware_mappings."
}

Une faute de frappe dans le nom du mapping est ainsi détectée au plan, et pas sous la forme d’une erreur d’API au milieu de l’apply.

Une fois le pipeline passé, la configuration de la VM côté Proxmox reflète ce qui a été déclaré :

1

qm config 123 | grep -E '^(hostpci|balloon|memory)'

1
2
3


balloon: 0
hostpci0: mapping=gpu,pcie=1,rombar=1,x-vga=0
memory: 12288

Le périphérique est référencé par le nom du mapping et non par son adresse PCI, et balloon: 0 correspond au floating = 0 du bloc memory.

La carte est désormais attachée à la VM, il reste à la rendre utilisable par Talos.

Étape 3 : les modules NVIDIA dans Talos

Un schematic dédié au nœud GPU

Comme expliqué dans la partie 1, les extensions NVIDIA ne sont pas dans l’image de base : les nœuds sans carte remontaient des erreurs de chargement des modules à chaque démarrage. Le nœud talos-gpu-01 utilise donc son propre schematic :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


#variables.auto.tfvars
{
 hostname = "talos-gpu-01"
 ip = "192.168.1.123"
 cores = 4
 memory = 12 * 1024,
 disk_size = 100,
 role = "worker"
 schematic_id = "a31d81eceab05afdc2c59b0002701173e117a5fb81bdc1f64062d27655145848" # With NVIDIA GPU support
 hostpci = [
 {
 device = "hostpci0"
 mapping = "gpu"
 }
 ]
}

Ce schematic ajoute deux extensions à qemu-guest-agent : nvidia-open-gpu-kernel-modules-production pour les drivers, et nvidia-container-toolkit-production pour que le runtime de conteneurs sache exposer la carte aux pods.

📝 Note

J’utilise les drivers open source de NVIDIA. Ils prennent en charge les GPU à partir de l’architecture Turing, ce qui inclut la RTX 3050 (Ampere). Sur du matériel plus ancien, il faut passer sur les extensions propriétaires.

Charger les modules

Les extensions embarquent les modules noyau mais ne les chargent pas. C’est le rôle d’un patch de machine config, placé au niveau nœud et non au niveau worker/ :

1
2
3
4
5
6
7
8


# patches/nodes/talos-gpu-01/30-nvidia-modules.yaml.tftpl
machine:
 kernel:
 modules:
 - name: nvidia
 - name: nvidia_uvm
 - name: nvidia_drm
 - name: nvidia_modeset

Ce patch utilise le niveau nodes/ présenté dans la partie 1 : placé sous worker/, il serait aussi appliqué à talos-worker-01, dont l’image ne contient pas les extensions.

La liste des modules est celle de la documentation Talos. Le module nvidia_uvm est celui qu’utilise CUDA pour gérer la mémoire unifiée.

Appliquer et vérifier

Le schematic et le patch sont déployés par le pipeline GitLab CI décrit dans la partie 1, comme le reste de la configuration des nœuds. Je vérifie ensuite que les extensions sont bien présentes dans l’image du nœud :

1

talosctl -n 192.168.1.123 get extensions

Ce qui donne le résultat suivant :

1
2
3
4
5
6


NODE NAMESPACE TYPE ID VERSION NAME VERSION
192.168.1.123 runtime ExtensionStatus 0 1 nvidia-container-toolkit-production 595.71.05-v1.19.1
192.168.1.123 runtime ExtensionStatus 1 1 nvidia-open-gpu-kernel-modules-production 595.71.05-v1.13.8
192.168.1.123 runtime ExtensionStatus 2 1 qemu-guest-agent 11.0.2
192.168.1.123 runtime ExtensionStatus 3 1 schematic a31d81eceab05afdc2c59b0002701173e117a5fb81bdc1f64062d27655145848
192.168.1.123 runtime ExtensionStatus modules.dep 1 modules.dep 6.18.42-talos

Les deux extensions NVIDIA sont en version 595.71.05, le numéro du driver, et l’ID schematic est bien celui déclaré pour ce nœud. Les quatre modules du patch doivent ensuite être chargés :

1

talosctl -n 192.168.1.123 get loadedkernelmodules | grep -i nvidia

1
2
3
4


192.168.1.123 runtime LoadedKernelModule nvidia 2 Live
192.168.1.123 runtime LoadedKernelModule nvidia_drm 2 Live
192.168.1.123 runtime LoadedKernelModule nvidia_modeset 2 Live
192.168.1.123 runtime LoadedKernelModule nvidia_uvm 1 Live

Enfin, le fichier /proc/driver/nvidia/version n’existe que si le module nvidia est chargé, et il donne la version exacte du driver :

1

talosctl -n 192.168.1.123 read /proc/driver/nvidia/version

1
2


NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 595.71.05 Release Build (dvs-builder@U22-I3-G08-03-1) Fri Apr 24 06:42:30 UTC 2026
GCC version: Selected multilib: .;@m64

La mention Open Kernel Module confirme que ce sont bien les drivers open source qui tournent.

Le driver est chargé dans la VM, la dernière étape consiste à le faire connaître à Kubernetes.

Étape 4 : exposer le GPU à Kubernetes

Des modules chargés sur le nœud ne suffisent pas. Le scheduler Kubernetes ne connaît que le CPU et la mémoire, et pour qu’il puisse allouer un GPU à un pod, il faut une ressource étendue nvidia.com/gpu publiée sur le nœud par un device plugin. Un device plugin est un composant qui tourne sur le nœud, déclare au kubelet les GPU disponibles et leur état, puis choisit quelle carte attribuer à chaque pod qui en demande une.

NVIDIA GPU Operator

Pour ce faire, j’ai utilisé le NVIDIA GPU Operator plutôt que le seul device plugin NVIDIA, pour deux raisons : c’est la méthode décrite dans la documentation Talos, et l’opérateur déploie aussi le DCGM exporter, qui me permet de récupérer les métriques du GPU dans Prometheus.

Par défaut, l’opérateur installe lui-même les drivers et le container toolkit sur les nœuds, mais sur Talos ces deux composants sont déjà fournis par les extensions système. Il faut donc les désactiver pour éviter les conflits, comme l’indique la documentation Talos :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


kubectl create namespace gpu-operator
kubectl label --overwrite namespace gpu-operator pod-security.kubernetes.io/enforce=privileged

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install gpu-operator nvidia/gpu-operator \
 --namespace gpu-operator \
 --version v26.3.3 \
 --set driver.enabled=false \
 --set toolkit.enabled=false \
 --set hostPaths.driverInstallDir=/usr/local \
 --set dcgmExporter.serviceMonitor.enabled=true

driver.enabled=false et toolkit.enabled=false : les drivers et le toolkit viennent des extensions Talos.
hostPaths.driverInstallDir=/usr/local : l’extension Talos installe les fichiers du driver dans /usr/local, alors que l’opérateur les cherche par défaut dans /run/nvidia/driver.
dcgmExporter.serviceMonitor.enabled=true : crée le ServiceMonitor qui permet à Prometheus de collecter les métriques du GPU.
Le namespace doit autoriser les pods privilégiés, car les composants de l’opérateur accèdent au matériel du nœud.

📝 Note

La documentation Talos demande une version du GPU Operator supérieure ou égale à v26.3.1.

Je n’ai pas eu besoin de nodeSelector pour cibler le nœud GPU. L’opérateur déploie d’abord Node Feature Discovery sur tous les nœuds, qui détecte les périphériques PCI de chacun. L’opérateur ajoute ensuite le label nvidia.com/gpu.present=true aux nœuds qui ont une carte NVIDIA, et ne déploie ses composants (device plugin, DCGM exporter, validation) que sur ces nœuds :

1

kubectl get pods -n gpu-operator -o wide

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gpu-feature-discovery-9ll6h 1/1 Running 0 52d 10.244.0.134 talos-gpu-01 <none> <none>
gpu-operator-57d75775c8-ls7hf 1/1 Running 0 4d12h 10.244.2.150 talos-controlplane-01 <none> <none>
gpu-operator-node-feature-discovery-gc-847bb8f7b6-9gmkf 1/1 Running 0 4d12h 10.244.0.231 talos-gpu-01 <none> <none>
gpu-operator-node-feature-discovery-master-d98f944cd-vhzdw 1/1 Running 0 4d12h 10.244.2.188 talos-controlplane-01 <none> <none>
gpu-operator-node-feature-discovery-worker-kvvfl 1/1 Running 0 52d 10.244.0.249 talos-gpu-01 <none> <none>
gpu-operator-node-feature-discovery-worker-ntvzt 1/1 Running 0 52d 10.244.2.39 talos-controlplane-01 <none> <none>
gpu-operator-node-feature-discovery-worker-s95fk 1/1 Running 0 52d 10.244.1.208 talos-worker-01 <none> <none>
nvidia-cuda-validator-gfd6h 0/1 Completed 0 6m42s 10.244.0.109 talos-gpu-01 <none> <none>
nvidia-dcgm-exporter-rkt88 1/1 Running 0 52d 10.244.0.161 talos-gpu-01 <none> <none>
nvidia-device-plugin-daemonset-pgnqw 1/1 Running 0 52d 10.244.0.164 talos-gpu-01 <none> <none>
nvidia-operator-validator-xqdd8 1/1 Running 0 52d 10.244.0.50 talos-gpu-01 <none> <none>

Seuls les workers NFD tournent sur les trois nœuds, tous les composants NVIDIA sont sur talos-gpu-01. Le pod nvidia-cuda-validator en Completed est normal : il lance un programme CUDA de test sur la carte, puis s’arrête.

Vérifier l’allocation

La ressource nvidia.com/gpu doit apparaître dans la capacité du nœud :

1

kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, gpu: .status.capacity."nvidia.com/gpu"}'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
 "name": "talos-controlplane-01",
 "gpu": null
}
{
 "name": "talos-gpu-01",
 "gpu": "1"
}
{
 "name": "talos-worker-01",
 "gpu": null
}

Le nœud talos-gpu-01 expose un GPU, les deux autres nœuds n’ont pas la ressource. Les labels ajoutés au nœud par le GPU Feature Discovery donnent aussi le détail de la carte vue par Kubernetes :

1

kubectl get node talos-gpu-01 --show-labels | tr ',' '\n' | grep nvidia.com

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


...
nvidia.com/cuda.driver-version.full=595.71.05
...
nvidia.com/cuda.runtime-version.full=13.2
...
nvidia.com/gpu.count=1
...
nvidia.com/gpu.family=ampere
...
nvidia.com/gpu.memory=8192
...
nvidia.com/gpu.product=NVIDIA-GeForce-RTX-3050
...

Le label nvidia.com/cuda.runtime-version.full=13.2 donne la version CUDA maximale supportée par le driver, ce qui sert à choisir l’image du pod de test.

Pour valider toute la chaîne, je lance un pod de test qui exécute nvidia-smi (NVIDIA System Management Interface), l’outil en ligne de commande livré avec le driver qui affiche les cartes visibles, la version du driver, l’occupation mémoire et les processus en cours. Si la commande voit la carte depuis un conteneur, c’est que le driver, le runtime et l’allocation fonctionnent :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: v1
kind: Pod
metadata:
 name: nvidia-smi
spec:
 restartPolicy: Never
 containers:
 - name: nvidia-smi
 image: nvidia/cuda:13.2.1-base-ubuntu24.04
 command: ["nvidia-smi"]
 resources:
 limits:
 nvidia.com/gpu: 1

Le champ nvidia.com/gpu: 1 dans les limits suffit : le pod demande la ressource publiée par le device plugin, le scheduler ne peut donc le placer que sur talos-gpu-01, et le GPU lui est réservé tant qu’il tourne.

La documentation Talos ajoute aussi runtimeClassName: nvidia à son pod de test, pour passer par le runtime NVIDIA que l’extension nvidia-container-toolkit déclare dans containerd. Sur mon cluster, ce n’est pas nécessaire, car CDI (Container Device Interface) est activé dans le GPU Operator :

1

kubectl get clusterpolicy -o jsonpath='{.items[0].spec.cdi}'

1

{"default":false,"enabled":true,"nriPluginEnabled":false}

Avec CDI, le device plugin indique à containerd quels fichiers de périphérique et quelles libs du driver ajouter au conteneur, et containerd les injecte lui-même avec son runtime par défaut. C’est aussi de cette manière que le binaire nvidia-smi, absent de l’image nvidia/cuda, se retrouve dans le conteneur. D’après la documentation NVIDIA sur CDI, c’est le fonctionnement par défaut depuis la version v25.10.0 du GPU Operator, et runtimeClassName: nvidia ne reste nécessaire que pour les conteneurs qui accèdent aux GPU par la variable d’environnement NVIDIA_VISIBLE_DEVICES sans passer par le device plugin, comme les agents de supervision.

Une fois le pod terminé, ses logs contiennent la sortie de nvidia-smi :

1

kubectl logs nvidia-smi

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.71.05 Driver Version: 595.71.05 CUDA Version: 13.2 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 3050 On | 00000000:01:00.0 Off | N/A |
| 0% 45C P8 7W / 130W | 1MiB / 8192MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+

Le conteneur voit la RTX 3050 avec ses 8 GB de mémoire, le driver 595.71.05 fourni par l’extension Talos et CUDA 13.2. Toute la chaîne fonctionne, de vfio-pci sur l’hôte Proxmox jusqu’au pod.

Conclusion

Le GPU est désormais allouable par le scheduler : le cluster expose une ressource nvidia.com/gpu sur le nœud talos-gpu-01, et un pod peut la demander comme il demanderait du CPU ou de la mémoire.

Il n’y a qu’une seule ressource nvidia.com/gpu dans tout le cluster, ce qui veut dire qu’un seul pod à la fois peut utiliser la carte. Pour la partager entre plusieurs pods, le GPU Operator propose du time-slicing, où les pods se partagent la carte à tour de rôle, et NVIDIA propose aussi MPS (Multi-Process Service), qui fait tourner les processus CUDA de plusieurs pods en même temps sur la carte. Ce sont des pistes que je n’ai pas encore mises en place.

De mon côté, cette partie m’a beaucoup appris sur le matériel. Mes connaissances en virtualisation restaient jusque-là à un niveau assez haut, celui de l’hyperviseur, et je ne connaissais pas les mécanismes bas niveau sur lesquels repose le passthrough, comme les entrées/sorties des périphériques, le DMA, la MMU ou l’IOMMU.

À ce stade, l’infrastructure est entièrement décrite en OpenTofu, mais tout ce qui tourne dans le cluster a été installé avec des helm install lancés à la main. C’est le même problème de dérive de configuration que Talos règle au niveau de l’OS, qui se retrouve un étage plus haut. La partie 3 met donc en place du GitOps avec Flux avant d’aller plus loin vers l’inférence.

Liens utiles

Déployer un cluster Kubernetes immuable avec Talos sur Proxmox

Fri, 02 Oct 2026 13:33:17 +0000

Série “Un cluster Kubernetes avec GPU pour faire de l’inférence LLM”

Déployer un cluster Kubernetes immuable avec Talos sur Proxmox (cet article)

Passer un GPU NVIDIA dans un cluster Kubernetes

Piloter un cluster Kubernetes en GitOps avec Flux (En cours d’écriture)

Inférence LLM auto-hébergée sur Kubernetes (En cours d’écriture)

Introduction

Après avoir déployé un cluster Kubernetes sur Proxmox avec Kubespray, j’ai voulu régler un point qui me gênait : la maintenance de l’OS sous le cluster. Dans cet article, je reprends le sujet depuis zéro avec Talos Linux, une distribution immuable dédiée à Kubernetes, que je provisionne entièrement avec OpenTofu.

Cet article est le premier d’une série dont l’objectif final est de faire tourner de l’inférence LLM en local, sur un GPU passé au cluster. Le but est de me former au MLOps et au déploiement de workloads d’IA sur Kubernetes. Le cluster décrit ici en est la base, et il contient donc déjà un nœud prévu pour le GPU.

Contexte

Mon précédent article détaillait le déploiement d’un cluster Kubernetes avec Kubespray. Le résultat était reproductible, mais l’automatisation s’arrêtait à l’OS : les trois VMs Debian restaient des systèmes classiques, avec leurs mises à jour de paquets, leur accès SSH et une configuration qui pouvait dériver entre deux lancements du playbook.

Avec Talos, l’OS n’est plus administrable directement : il n’y a ni shell, ni SSH, ni gestionnaire de paquets. La seule interface est une API gRPC, et toute la machine est décrite par un fichier de configuration YAML appliqué de manière déclarative. Pour modifier un nœud, je modifie sa configuration et Talos l’applique.

Talos n’est pas meilleur que Kubespray dans l’absolu. Je perds la possibilité d’intervenir à la main sur un nœud, mais en échange je sais qu’aucun nœud n’a été modifié en dehors du code.

Composants

Composant	Version	Rôle
Proxmox	9.1	Hyperviseur
Talos Linux	1.13.8	OS des nœuds
Kubernetes	v1.36.2	Orchestrateur
OpenTofu	1.11.5	Création des VMs et configuration Talos
Provider `bpg/proxmox`	0.114.0	Pilotage de Proxmox
Provider `siderolabs/talos`	0.12	Pilotage de Talos
Composant GitLab CI OpenTofu	4.5.0	Pipeline de déploiement
Cilium	1.20.2	CNI, remplace kube-proxy

J’ai choisi OpenTofu plutôt que Terraform pour rester cohérent avec ma ligne sur les logiciels open source et leurs licences. Depuis que HashiCorp a passé Terraform sous licence BUSL en 2023, OpenTofu est le fork qui reste sous licence MPL 2.0. Son évolution est aussi davantage guidée par les demandes de fonctionnalités de la communauté, alors que celle de Terraform s’oriente vers les offres Enterprise et Cloud de HashiCorp, qui ne m’intéressent pas.

Talos Linux

Talos est une distribution Linux qui ne contient que ce qu’il faut pour faire tourner Kubernetes : un noyau, son propre système d’init, containerd et les composants du cluster. Quelques-unes de ses propriétés expliquent la plupart des choix faits dans la suite de l’article :

Le système de fichiers racine est en lecture seule, monté depuis une image squashfs. Les données qui doivent persister (etcd, images de conteneurs) sont écrites sous /var, sur une partition dédiée. Il n’y a donc aucun endroit où déposer un binaire ou modifier un fichier de configuration à la main.
Les mises à jour suivent un schéma A/B. La nouvelle version est installée à côté de la version en cours, et si la mise à jour échoue, le nœud peut redémarrer sur l’ancienne.
Il n’y a pas de systemd. Le kubelet, etcd, containerd et l’API Talos sont gérés par machined, et leur configuration vient entièrement de la machine config. Il n’est pas possible d’ajouter un service ou d’en surcharger un.
L’administration passe uniquement par une API gRPC, exposée sur le port 50000 de chaque nœud avec une authentification TLS mutuelle. Le fichier talosconfig utilisé par talosctl contient la CA du cluster et un certificat client, et sans ce fichier, un nœud Talos refuse toute connexion.

Toute la configuration d’un nœud tient donc dans un seul fichier YAML, la machine config, qui comporte deux grandes sections : machine.* pour le nœud lui-même (réseau, disques, kubelet, modules noyau) et cluster.* pour le cluster Kubernetes (CNI, kube-proxy, manifests additionnels).

Configuration machine et configuration cluster

Ces deux sections sont dans le même fichier, mais elles ne sont pas appliquées de la même manière :

machine.* est réconcilié en continu. Les contrôleurs de Talos surveillent la configuration et ajustent l’état du nœud. Un patch qui modifie machine.network ou machine.kubelet est appliqué immédiatement, parfois après le redémarrage du service concerné.
cluster.* n’est lu qu’au bootstrap. Au moment du talos_machine_bootstrap, Talos génère des manifests Kubernetes à partir de cette section et les applique au cluster. La section reste ensuite dans la configuration, mais elle n’est plus relue.

En pratique, modifier cluster.network.cni.name sur un cluster déjà démarré ne supprime pas le CNI en place, et Talos n’affiche aucune erreur ni aucun avertissement. Les manifests générés à partir de cluster.* ne sont rejoués, avec suppression de ceux qui ne sont plus générés, que pendant un talosctl upgrade-k8s.

Les deux cycles de vie de la machine config

Architecture cible

Rôle	Hostname	VM ID	IP	vCPU	RAM	Disque
Control plane	`talos-controlplane-01`	121	192.168.1.121	2	4 GB	50 GB
Worker	`talos-worker-01`	122	192.168.1.122	4	8 GB	100 GB
Worker GPU	`talos-gpu-01`	123	192.168.1.123	4	12 GB	100 GB

L’API Kubernetes ne répond pas sur l’IP d’un nœud mais sur une VIP, 192.168.1.120. Cette adresse est réservée, et les nœuds commencent donc à .121.

📝 Note

Il n’y a qu’un seul control plane, comme dans mon article sur Kubespray, et pour la même raison : c’est un homelab. J’ai quand même configuré la VIP dès la création, car elle est inscrite dans la configuration de chaque nœud et la mettre en place plus tard obligerait à reconfigurer tout le cluster.

Un nœud GPU déclaré dès le départ

Le troisième nœud s’appelle talos-gpu-01, même si aucune carte graphique n’est utilisée dans cet article. Il se distingue déjà des deux autres sur trois points :

12 GB de RAM au lieu de 8. Le passthrough PCI impose de désactiver le ballooning, donc cette mémoire sera réservée en permanence sur l’hôte. J’ai préféré dimensionner le nœud tout de suite en conséquence.
Une image Talos différente. Les modules NVIDIA sont fournis par des extensions système, qui sont intégrées à l’image au moment de sa construction. Ce nœud a donc sa propre image.
Un patch de configuration qui ne concerne que lui. Charger les modules NVIDIA sur un nœud sans carte produit une erreur à chaque démarrage.

Ce dernier point a une conséquence sur la façon d’organiser la configuration : dès qu’un nœud est différent des autres, une configuration par rôle ne suffit plus. Je détaille la solution dans la partie sur les patches.

Provisionnement avec OpenTofu

Les images : Talos Image Factory

Une image Talos ne peut pas être modifiée après coup. Pour ajouter qemu-guest-agent ou les modules NVIDIA, il faut une image qui les contient déjà, et c’est le rôle de l’Image Factory : on lui envoie une liste d’extensions, et elle renvoie un schematic ID, un hash qui identifie cette liste. Ce hash permet ensuite de construire l’URL de l’image pour n’importe quelle version de Talos.

Schematic	Extensions	Nœuds
`ce4c9805...`	`qemu-guest-agent`	controlplane-01, worker-01
`a31d81ec...`	`qemu-guest-agent`, `nvidia-open-gpu-kernel-modules-production`, `nvidia-container-toolkit-production`	gpu-01

L’image téléchargée est un disque brut compressé, nocloud-amd64.raw.xz. Elle change deux choses par rapport à mes déploiements précédents :

nocloud est la plateforme cible. Avec elle, Talos lit sa configuration réseau initiale sur le lecteur cloud-init fourni par Proxmox, ce qui rend le nœud joignable dès le premier démarrage, avant qu’il ait reçu sa machine config.
Il n’y a plus de template. Mes VMs Debian sont clonées depuis un template construit avec Packer, alors que les nœuds Talos importent directement cette image comme disque scsi0. Je n’ai donc plus de template à reconstruire pour ce cluster : pour changer de version de Talos, je modifie une variable.

Le téléchargement utilise un for_each sur les schematics réellement utilisés, ce qui évite de télécharger deux fois la même image quand plusieurs nœuds partagent le même schematic :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


#image.tf
locals {
 talos_schematics = toset([
 for node in var.talos_nodes : coalesce(node.schematic_id, var.talos_image_factory_id)
 ])
}

resource "proxmox_download_file" "talos_image" {
 for_each = local.talos_schematics

 content_type = "iso"
 datastore_id = "local"
 file_name = "talos-${var.talos_version}-${substr(each.key, 0, 8)}-nocloud-amd64.img"
 node_name = var.proxmox_node
 url = "https://factory.talos.dev/image/${each.key}/v${var.talos_version}/nocloud-amd64.raw.xz"
 overwrite = false
 decompression_algorithm = "zst"
}

L’image est téléchargée au format .raw.xz, alors que decompression_algorithm vaut zst. Le provider n’accepte que gz, lzo, zst et bz2, mais la décompression zst de Proxmox sait aussi traiter une archive xz. Ce comportement n’est pas documenté, je l’ai trouvé dans une discussion du provider bpg sur les images compressées en xz.

La topologie dans une variable

Toute la topologie du cluster est décrite dans une seule variable. Pour ajouter un nœud, il suffit d’ajouter un objet à cette liste :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#variables.tf
variable "talos_nodes" {
 type = list(object({
 hostname = string
 ip = string
 cores = number
 memory = number
 vm_id = optional(number)
 disk_size = optional(number, 40)
 role = optional(string, "controlplane")

 # Schematic Image Factory. `null` retombe sur var.talos_image_factory_id.
 schematic_id = optional(string)

 # Périphériques PCI passés au nœud (partie 2).
 hostpci = optional(list(object({
 device = string
 mapping = string
 pcie = optional(bool, true)
 rombar = optional(bool, true)
 xvga = optional(bool, false)
 })), [])
 }))

 validation {
 condition = !contains([for node in var.talos_nodes : node.ip], var.talos_vip)
 error_message = "The Talos VIP must not collide with a node IP address."
 }
 ...
}

J’ai ajouté plus de validations que d’habitude sur cette variable, cinq au total :

role doit valoir controlplane ou worker
les hostnames doivent être uniques
les IPs doivent être uniques
il doit y avoir au moins un controlplane
la VIP ne doit pas correspondre à l’IP d’un nœud

Sans ces validations, chacune de ces erreurs apparaîtrait au milieu d’un apply, sous la forme d’une erreur d’API Proxmox peu explicite, avec une partie de l’infrastructure déjà créée. Avec elles, l’erreur est détectée au plan, avant toute modification. Une sixième validation arrive dans la partie 2, pour vérifier que chaque hostpci.mapping correspond bien à un mapping déclaré.

Les VMs

Une seule ressource crée les trois nœuds :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


#talos.tf
resource "proxmox_virtual_environment_vm" "talos" {
 depends_on = [
 proxmox_download_file.talos_image,
 proxmox_virtual_environment_pool.TALOS,
 ]
 for_each = { for node in var.talos_nodes : node.hostname => node }

 name = each.key
 node_name = var.proxmox_node
 vm_id = tonumber(split(".", each.value.ip)[3])
 machine = "q35"
 ...

 bios = "ovmf"
 efi_disk {
 datastore_id = var.proxmox_datastore
 type = "4m"
 }

 memory {
 dedicated = each.value.memory
 floating = 0
 }

 disk {
 datastore_id = var.proxmox_datastore
 interface = "scsi0"
 size = each.value.disk_size
 file_id = proxmox_download_file.talos_image[coalesce(each.value.schematic_id, var.talos_image_factory_id)].id
 discard = "on"
 ssd = true
 iothread = true
 ...
 }

 initialization {
 datastore_id = var.proxmox_datastore
 ip_config {
 ipv4 {
 address = "${each.value.ip}/24"
 gateway = var.talos_gateway
 }
 }
 dns {
 servers = var.talos_nameservers
 }
 }
 ...
}

Il n’y a pas de bloc clone. Le disque système est l’image téléchargée plus haut, référencée par son file_id, et c’est ce qui remplace le template.
machine = "q35" et bios = "ovmf" avec un efi_disk. Les VMs démarrent en UEFI, et le firmware OVMF a besoin d’un disque EFI pour stocker ses variables.
Le vm_id est dérivé du dernier octet de l’IP. 192.168.1.123 donne la VM 123, ce qui me permet de faire directement le lien entre l’interface Proxmox et le réseau.
floating = 0 désactive le ballooning, ce qui est obligatoire pour le nœud GPU de la partie 2.

📝 Note

Le lecteur cloud-init d’un nœud Talos ne sert pas à configurer Talos. Il donne seulement une IP statique au nœud au premier démarrage, pour qu’il soit joignable en mode maintenance. Toute la configuration est ensuite appliquée par l’API Talos, via le provider siderolabs/talos.

Les VMs sont prêtes à démarrer, il reste maintenant à leur fournir leur configuration.

La configuration machine

Générer les secrets et la configuration de base

Le provider siderolabs/talos enchaîne six ressources, dans cet ordre :

1
2
3
4
5
6


talos_machine_secrets # CA, clés et tokens du cluster
 └─> data.talos_client_configuration # le talosconfig de talosctl
 └─> data.talos_machine_configuration # une config de base, par rôle
 └─> talos_machine_configuration_apply # appliquée par nœud, avec les patches
 └─> talos_machine_bootstrap # init d'etcd, une seule fois
 └─> talos_cluster_kubeconfig # le kubeconfig admin

talos_machine_secrets génère tout le matériel cryptographique du cluster : les CA de Kubernetes, de Talos et d’etcd, ainsi que les tokens d’enrôlement des nœuds. Ces secrets ne sont écrits nulle part sur le disque, ils sont stockés dans le state OpenTofu et n’en sortent que par les outputs.

Le bootstrap et la récupération du kubeconfig n’ont pas de for_each, car ce sont des opérations qui concernent le cluster entier. Elles ciblent un seul control plane, le premier de la liste :

1
2
3
4
5


#talos.tf
locals {
 talos_controlplanes = [for node in var.talos_nodes : node if node.role == "controlplane"]
 talos_first_controlplane = local.talos_controlplanes[0].ip
}

La ressource talos_machine_configuration_apply reçoit son argument node depuis la variable talos_nodes, et pas depuis un attribut de la VM. OpenTofu ne voit donc aucune dépendance entre les deux, et peut essayer d’appliquer la configuration à une IP qui ne répond pas encore. J’ai donc ajouté un depends_on explicite sur les VMs :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#talos.tf
resource "talos_machine_configuration_apply" "this" {
 depends_on = [proxmox_virtual_environment_vm.talos]
 for_each = { for node in var.talos_nodes : node.hostname => node }

 client_configuration = talos_machine_secrets.this.client_configuration
 machine_configuration_input = data.talos_machine_configuration.this[each.value.role].machine_configuration
 node = each.value.ip

 config_patches = [
 for patch in local.talos_patch_files[each.key] :
 templatefile(patch, {
 hostname = each.key
 node_ip = each.value.ip
 role = each.value.role
 vip = var.talos_vip
 gateway = var.talos_gateway
 nameservers = var.talos_nameservers
 })
 ]
}

Les patches, en trois niveaux

Une liste de patches par rôle ne suffit plus dès qu’un seul nœud a du matériel spécifique. J’ai donc organisé les patches en trois niveaux, du plus général au plus spécifique :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


tofu/patches/
├── common/ # tous les nœuds
│ └── 40-kubelet.yaml.tftpl
├── controlplane/ # les control planes
│ ├── 10-network-vip.yaml.tftpl
│ ├── 20-cluster-cni-proxy.yaml.tftpl
│ └── 30-extra-manifests.yaml.tftpl
├── worker/ # les workers
└── nodes/
 └── talos-gpu-01/ # ce nœud précis
 └── 30-nvidia-modules.yaml.tftpl

La liste des patches de chaque nœud est construite avec fileset :

1
2
3
4
5
6
7
8
9


#talos.tf
talos_patch_files = {
 for node in var.talos_nodes :
 node.hostname => concat(
 [for f in fileset("${path.module}/patches/common", "*.yaml.tftpl") : "${path.module}/patches/common/${f}"],
 [for f in fileset("${path.module}/patches/${node.role}", "*.yaml.tftpl") : "${path.module}/patches/${node.role}/${f}"],
 [for f in fileset("${path.module}/patches/nodes/${node.hostname}", "*.yaml.tftpl") : "${path.module}/patches/nodes/${node.hostname}/${f}"],
 )
}

Ce fonctionnement repose sur trois propriétés de fileset :

Les fichiers sont triés par ordre alphabétique, donc le préfixe numérique de chaque fichier fixe l’ordre de fusion. Pour une même clé, c’est le dernier patch qui l’emporte : le niveau nœud écrase le niveau rôle, qui écrase le niveau commun. Je laisse des trous dans la numérotation (10, 20, 30) pour pouvoir intercaler un patch plus tard.
Un répertoire absent renvoie un ensemble vide, sans erreur. Les trois niveaux sont donc facultatifs, ce qui est pratique puisque Git ne versionne pas les répertoires vides.
Ajouter un patch ne demande aucune modification du code. Il suffit de déposer un fichier dans le bon répertoire, talos.tf reste inchangé.

C’est le nœud GPU qui m’a amené à créer le niveau nodes/ : un patch NVIDIA placé sous worker/ serait aussi appliqué à talos-worker-01, dont l’image ne contient pas les extensions, et ce nœud échouerait à charger les modules à chaque démarrage.

La VIP

Talos gère la VIP lui-même, sans keepalived ni load balancer externe. Les control planes choisissent le nœud qui porte la VIP par une élection dans etcd : un seul la détient à un instant donné, et elle bascule automatiquement sur un autre control plane si ce nœud disparaît.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# patches/controlplane/10-network-vip.yaml.tftpl
machine:
 network:
 interfaces:
 - deviceSelector:
 physical: true
 dhcp: false
 addresses:
 - ${node_ip}/24
 routes:
 - network: 0.0.0.0/0
 gateway: ${gateway}
 vip:
 ip: ${vip}
 nameservers: ${jsonencode(nameservers)}

L’interface est redéclarée en entier, et pas seulement complétée avec une entrée vip. La machine config est prioritaire sur la configuration réseau fournie par la plateforme nocloud : un patch qui ne contiendrait que la VIP ferait disparaître l’adressage statique fourni par le lecteur cloud-init, et le nœud deviendrait injoignable.

cluster_endpoint pointe lui aussi sur la VIP, et pas sur l’IP d’un nœud. Cette valeur est inscrite dans la configuration de tous les nœuds et dans le kubeconfig : si elle désignait un nœud précis, la perte de ce nœud couperait l’accès à l’API, et l’ajout d’un control plane obligerait à reconfigurer tout le cluster pour changer l’endpoint.

CNI et kube-proxy désactivés

1
2
3
4
5
6
7


# patches/controlplane/20-cluster-cni-proxy.yaml.tftpl
cluster:
 network:
 cni:
 name: none
 proxy:
 disabled: true

Par défaut, Talos installe Flannel comme CNI et kube-proxy. Je les remplace tous les deux par Cilium, donc je les désactive.

J’ai choisi Cilium pour trois raisons : il remplace kube-proxy, il gère les L2 announcements, que j’utilise plus tard dans la série pour annoncer les IP des services LoadBalancer sur mon réseau local, et le tout repose sur eBPF, une technologie sur laquelle je veux m’appuyer pour les évolutions de mon homelab.

Ce choix a deux conséquences :

les nœuds restent dans l’état NotReady tant qu’aucun CNI n’est installé, ce qui est normal
sans kube-proxy, le CNI doit joindre l’API server directement, car la ClusterIP du service kubernetes.default n’est pas encore routable au moment où il démarre. C’est le rôle de KubePrism, que je présente dans la partie sur Cilium.

Ce patch est placé sur les control planes car ces manifests sont générés au bootstrap, depuis un control plane. Comme tout ce qui est sous cluster.*, il n’a d’effet qu’à ce moment-là : appliqué à un cluster déjà démarré, il ne supprime rien.

Certificats serving du kubelet

Par défaut, le kubelet expose son endpoint :10250 avec un certificat auto-signé qu’aucune CA du cluster ne reconnaît. D’où l’option --kubelet-insecure-tls présente dans la plupart des installations de metrics-server : le client ne vérifie pas le certificat du serveur, donc n’importe quelle machine capable de s’intercaler sur le réseau peut se faire passer pour un kubelet.

La première partie de la solution se trouve côté nœud :

1
2
3
4
5


# patches/common/40-kubelet.yaml.tftpl
machine:
 kubelet:
 extraArgs:
 rotate-server-certificates: true

Avec cette option, le kubelet ne génère plus de certificat auto-signé et envoie une CSR à l’API server, avec le signer kubernetes.io/kubelet-serving. Le problème est que Kubernetes n’approuve jamais automatiquement les CSR de ce signer. Le kube-controller-manager sait signer le certificat, mais aucun composant du cluster ne l’approuve : les CSR restent en Pending et le kubelet garde son certificat auto-signé. C’est un choix volontaire du projet Kubernetes, qui laisse cette décision à chaque environnement.

La seconde partie se trouve donc côté cluster :

1
2
3
4
5


# patches/controlplane/30-extra-manifests.yaml.tftpl
cluster:
 extraManifests:
 - https://raw.githubusercontent.com/alex1989hu/kubelet-serving-cert-approver/v0.11.0/deploy/standalone-install.yaml
 - https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.9.0/components.yaml

kubelet-serving-cert-approver est un contrôleur qui approuve ces CSR. Il ne fait que les approuver : la signature reste faite par le kube-controller-manager, avec la clé de la CA du cluster. Avant d’approuver une demande, il vérifie qu’elle correspond bien à celle d’un kubelet :

l’organisation du sujet est system:nodes
le CN commence par system:node: et correspond exactement à l’utilisateur qui a soumis la CSR
les usages demandés sont ceux d’un certificat serveur
la demande ne contient pas de SAN de type email ou URI

En revanche, il ne vérifie pas que les adresses IP demandées dans les SAN appartiennent réellement au nœud, puisque son ClusterRole ne lui donne aucun accès aux objets Node. Un nœud déjà enrôlé dans le cluster peut donc obtenir un certificat valide pour l’IP d’un autre nœud.

Le gain de sécurité reste réel, mais il est limité : avant, n’importe quelle machine sur le réseau pouvait se faire passer pour un kubelet, alors qu’il faut maintenant disposer de l’identité d’un nœud du cluster. Dans mon cas, metrics-server vérifie désormais les certificats des kubelets avec la CA du cluster, sans --kubelet-insecure-tls.

Ces deux manifests doivent rester déployés en permanence, car la rotation des certificats est continue et chaque renouvellement produit une nouvelle CSR à approuver. Les URLs sont fixées sur une version précise, pour qu’un re-apply ne récupère pas un contenu différent et pour que Renovate puisse suivre les mises à jour.

La configuration est complète, je peux passer au déploiement.

Déploiement

Je ne lance pas d’apply en local. Le déploiement passe par un pipeline GitLab CI qui utilise le composant OpenTofu de GitLab :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#.gitlab-ci.yml
default:
 tags:
 - homelab

variables:
 TF_VAR_proxmox_endpoint: '${proxmox_endpoint}'
 TF_VAR_proxmox_api_token: '${proxmox_api_token}'
 TF_VAR_proxmox_ssh_private_key: '${proxmox_ssh_private_key}'

include:
 # renovate: datasource=gitlab-releases packageName=components/opentofu registryUrl=https://gitlab.com
 - component: $CI_SERVER_FQDN/components/opentofu/validate-plan-apply@4.5.0
 inputs:
 # renovate: datasource=gitlab-releases packageName=components/opentofu registryUrl=https://gitlab.com
 version: 4.5.0
 opentofu_version: 1.11.5
 root_dir: tofu/

stages: [validate, build, deploy]

workflow:
 rules:
 - changes:
 - tofu/**
 - when: never

Le template validate-plan-apply ajoute quatre jobs : fmt et validate dans le stage validate, plan dans build, puis apply dans deploy. Par défaut, apply n’existe que sur la branche principale et doit être lancé à la main : une merge request s’arrête donc au plan, et rien n’est appliqué tant que je n’ai pas déclenché le job.

Le reste de la configuration tient en cinq points :

Les jobs tournent sur mon propre runner, grâce au tag homelab : un runner GitLab avec l’executor Docker, hébergé sur mon Proxmox. Il est sur le même réseau que l’API Proxmox, que les runners partagés de GitLab ne pourraient pas joindre.
Le state est géré par GitLab. Le bloc backend "http" {} de providers.tf est vide, et c’est le composant qui renseigne l’adresse du state du projet et les identifiants du job au moment de l’exécution.
Les secrets restent dans GitLab. Le token de l’API Proxmox et la clé SSH sont des variables CI/CD, transmises à OpenTofu par les variables TF_VAR_*.
Le pipeline ne se déclenche que si tofu/ change, grâce à la règle workflow.
Les versions sont suivies par Renovate, grâce aux commentaires # renovate: placés au-dessus du composant.

Récupérer les accès

Les accès au cluster ne sont écrits nulle part sur le disque, ils sont dans le state, et il faut donc les extraire avec les outputs. Comme le state est stocké dans GitLab, je fais un tofu init local une seule fois, uniquement pour cette étape. GitLab fournit la commande d’init complète dans Operate > Terraform states, avec l’action Copy Terraform init command. Je récupère ensuite les deux fichiers :

1
2


tofu output -raw talosconfig > ../talos/config
tofu output -raw kubeconfig > ../talos/kubeconfig

Le talosconfig généré par data.talos_client_configuration contient deux listes : les endpoints, auxquels talosctl se connecte réellement et qui ne contiennent que des control planes, et les nodes, qui sont les cibles par défaut des commandes et qui sont jointes en passant par un endpoint. C’est ce qui permet d’interroger un worker sans s’y connecter directement.

Par exemple, pour lister les services de talos-worker-01 :

1

talosctl --talosconfig talos/config -e 192.168.1.121 -n 192.168.1.122 services

talosctl ouvre la connexion vers le control plane 192.168.1.121, qui relaie la requête jusqu’au worker 192.168.1.122. Sans -e, ce sont les endpoints du talosconfig qui sont utilisés, et -n suffit pour changer de cible.

Endpoint et node avec talosctl

Installer Cilium

Le cluster démarre sans CNI, les nœuds sont donc NotReady. J’installe Cilium avec Helm, en remplacement de kube-proxy :

1
2
3
4
5
6


helm repo add cilium https://helm.cilium.io/
helm repo update
helm install cilium cilium/cilium \
 --version 1.20.2 \
 --namespace kube-system \
 --values cilium-values.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#cilium-values.yaml
kubeProxyReplacement: true
k8sServiceHost: localhost
k8sServicePort: 7445

# Talos monte lui-même le cgroup2 et interdit à l'agent de le remonter.
cgroup:
 autoMount:
 enabled: false
 hostRoot: /sys/fs/cgroup

securityContext:
 capabilities:
 ciliumAgent:
 - CHOWN
 - KILL
 - NET_ADMIN
 - NET_RAW
 - IPC_LOCK
 - SYS_ADMIN
 - SYS_RESOURCE
 - DAC_OVERRIDE
 - FOWNER
 - SETGID
 - SETUID
 cleanCiliumState:
 - NET_ADMIN
 - SYS_ADMIN
 - SYS_RESOURCE

Les valeurs cgroup et securityContext sont spécifiques à Talos. Par défaut, le chart monte lui-même le cgroup2 et lance l’agent en mode privilégié, ce que Talos ne permet pas. J’ai repris la liste de capabilities de la documentation Talos pour Cilium plutôt que de la reconstruire.

Il reste le couple k8sServiceHost / k8sServicePort. On pourrait pointer Cilium sur la VIP en 6443, puisque c’est l’endpoint du cluster, mais ce n’est pas ce que recommande Talos. Cilium doit joindre l’API server avant que le réseau des pods existe, et la VIP dépend de l’élection etcd entre les control planes.

KubePrism répond à ce problème : c’est un load balancer local présent sur chaque nœud, qui écoute sur localhost:7445. Il choisit automatiquement parmi les endpoints disponibles (l’endpoint du cluster et chaque control plane), en écartant ceux qui ne répondent pas et en privilégiant les plus rapides. Il est activé par défaut, et la documentation Talos recommande de le donner comme endpoint aux CNI qui ont besoin de joindre l’API server, comme Cilium.

Accès à l'API Kubernetes

Vérification

Une fois Cilium installé, je vérifie l’état du cluster côté Talos avec talosctl health. J’ai retiré de la sortie les lignes de progression, pour ne garder que le résultat de chaque vérification :

1

talosctl --talosconfig talos/config -n 192.168.1.121 health

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


discovered nodes: ["192.168.1.120" "192.168.1.123" "192.168.1.122"]
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: OK
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: OK
waiting for no diagnostics: OK
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: OK
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: OK
waiting for all k8s nodes to report ready: SKIP
waiting for kube-proxy to report ready: SKIP
waiting for coredns to report ready: SKIP
waiting for all k8s nodes to report schedulable: OK

La première adresse listée est la VIP et non 192.168.1.121 : le control plane qui la détient l’annonce parmi ses adresses, et elle est triée en premier.

Les trois SKIP viennent des choix faits dans les patches. talosctl health ne vérifie pas l’état Ready des nœuds ni CoreDNS quand le CNI est déclaré à none, puisque ces vérifications dépendent d’un CNI que Talos n’a pas installé lui-même, et il ignore kube-proxy quand son DaemonSet n’existe pas. L’état des nœuds se vérifie donc côté Kubernetes :

1

kubectl get nodes

1
2
3
4


NAME STATUS ROLES AGE VERSION
talos-controlplane-01 Ready control-plane 47d v1.36.2
talos-gpu-01 Ready <none> 47d v1.36.2
talos-worker-01 Ready <none> 47d v1.36.2

Les trois nœuds sont Ready, ce qui confirme que Cilium fonctionne sur chacun d’eux.

Pièges rencontrés

La courbe d’apprentissage de Talos

La prise en main de Talos m’a demandé du temps. Sans shell ni SSH, aucun de mes réflexes habituels pour diagnostiquer un nœud ne s’applique, et il faut passer par talosctl pour tout ce qui se faisait avant directement sur la machine. Il faut donc apprendre une nouvelle CLI, de nouveaux concepts et un nouveau nommage.

Un premier déploiement sans le provider Talos

Mon premier déploiement n’utilisait pas le provider siderolabs/talos : OpenTofu créait les VMs, et je générais puis appliquais les configurations à la main avec talosctl. Le passage au provider a ramené toute la configuration des nœuds as code, avec le reste de l’infrastructure, et permet donc d’avoir un déploiement de bout en bout en un seul run OpenTofu.

Un seul schematic pour tous les nœuds

Au départ, tous les nœuds utilisaient le même schematic, celui qui contient les extensions NVIDIA. Les nœuds sans GPU remontaient alors des erreurs liées aux pilotes NVIDIA, puisqu’ils embarquaient des modules prévus pour une carte qu’ils n’ont pas. C’est ce qui m’a amené à associer à chaque nœud un schematic qui ne contient que les extensions dont il a besoin.

Conclusion

Le cluster est opérationnel, et par rapport à Kubespray, je n’ai plus d’OS à administrer : pas de mises à jour de paquets, pas de SSH ouvert, et la configuration des nœuds ne peut pas s’écarter de ce que décrit le code. Une mise à jour de Talos se résume à changer une version dans une variable, et chaque nœud bascule sur la nouvelle image.

Résumé du workflow de déploiement

Une fois tout en place, j’ai surtout été surpris par la facilité et la rapidité avec lesquelles un cluster Kubernetes se monte. Là où Kubespray enchaînait près de 600 tâches Ansible, un seul run du pipeline crée les VMs, applique les configurations et bootstrappe le cluster, et il ne reste plus qu’à installer Cilium.

Le nœud talos-gpu-01 tourne déjà, avec ses 12 GB de RAM réservés et son image qui contient les modules NVIDIA, mais il ne voit encore aucune carte graphique. Faire passer le GPU de l’hôte Proxmox jusqu’aux pods est le sujet de la partie 2.

Liens utiles

Garantir la qualité des Helm Charts

Mon, 11 May 2026 14:00:00 +0000

Introduction

En tant que SRE / Platform Engineer, l’une de mes responsabilités est de fournir des Helm charts fiables aux équipes de développement. Ces charts constituent la fondation du déploiement de leurs applications sur nos plateformes Kubernetes. Un chart défaillant, ce sont des applications impactées, des heures d’investigation, et une confiance érodée sur les composants mis à disposition.

Le déclencheur de cette réflexion vient d’un incident évitable, avec l’introduction de breaking changes non documentés qui ont cassé tous les déploiements utilisant ce chart, et nous a forcés à nous poser une question fondamentale : comment garantir la qualité des helm charts que nous fournissons ?

Contexte

Le problème

Gérer des Helm charts manuellement et sans validation automatisée présente plusieurs risques :

Breaking changes non documentés : Des modifications incompatibles peuvent être introduites sans que les équipes utilisatrices en soient informées.
Erreurs de syntaxe : Des fautes de frappe ou des erreurs YAML peuvent passer inaperçues jusqu’au déploiement en production.
Templates invalides : Des templates qui ne se rendent pas correctement ou génèrent des manifestes Kubernetes invalides.
Régression fonctionnelle : Des modifications qui cassent des fonctionnalités existantes sans être détectées.
Absence de traçabilité : Difficulté à comprendre l’historique des changements et leur impact.

L’objectif

J’avais donc besoin d’un cadre capable de valider automatiquement chaque modification avant son intégration dans la branche principale, de signaler explicitement les breaking changes, de vérifier la conformité Kubernetes des manifestes générés, de tester les comportements attendus et de tracer les évolutions dans un changelog exploitable.

Mais il ne s’agissait pas seulement d’ajouter des outils. La réponse devait aussi être organisationnelle : mieux cadrer la contribution, rendre la collaboration plus lisible, et faire en sorte que la qualité du chart ne repose plus uniquement sur l’attention individuelle.

Composants

Le workflow s’articule autour de plusieurs outils et pratiques :

GitLab CI/CD : Orchestre l’ensemble du pipeline de validation et de publication.
Helm & Plugins : Gestionnaire de packages pour Kubernetes, avec ses outils natifs de validation et ses plugins.
Git Flow : Stratégie de branches et processus de Merge Request.
SemVer : Gestion des versions pour communiquer clairement les types de changements.
Keep a Changelog : Format standardisé pour documenter tous les changements.

Architecture du Pipeline

Le pipeline GitLab CI est organisé en trois stages principaux, chacun avec un objectif spécifique.

Vue d'ensemble du pipeline

Linting

Le premier niveau de validation dans le pipeline vérifie la syntaxe et la structure globale du chart via la commande helm lint native à helm. Elle permet d’avoir un retour rapide et immédiatement compréhensible, bien qu’elle ne couvre pas tous les cas, elle élimine très tôt les erreurs grossières qui ne devraient jamais atteindre les étapes suivantes et évite donc de lancer des validations plus poussées et donc de perdre du temps.

1

helm lint .

📝 Note

Ce que Helm lint vérifie :

Syntaxe YAML correcte

Structure du chart (Chart.yaml, templates/, etc.)

Problèmes de formatage

Warnings sur les bonnes pratiques

Une fois que l’on s’est assuré de la bonne structure du chart, on peut passer aux étapes de validation plus spécifiques.

Validation du templating

Pour répondre à la question : est-ce que le chart se rend réellement correctement avec les valeurs fournies ? J’ai retenu helm template qui va permettre d’effectuer le rendu des templates, c’est souvent à ce niveau que l’on découvre des variables manquantes, des conditions mal écrites, ou des erreurs dans les fonctions Go Template.

Le fonctionnement est simple : Helm interprète les templates et produit les manifestes Kubernetes finaux, sans les appliquer sur un cluster. On obtient donc une vue concrète de ce qui serait déployé, ce qui en fait une étape particulièrement utile pour détecter les erreurs de rendu au plus tôt.

1

helm template .

📝 Note

Ce que Helm template vérifie :

Rendu correct des templates Go (variables, fonctions, pipelines)

Résolution des valeurs et des helpers définis dans _helpers.tpl

Syntaxe correcte des conditions {{- if }} et des boucles {{- range }}

Absence de variables non définies ou mal référencées

Conformité des schémas

helm template garantit que le rendu fonctionne, mais pas que le résultat soit acceptable pour Kubernetes. C’est précisément pour cette raison que j’ai choisi d’utiliser Kubeconform. Cet outil a été retenu parce qu’il est rapide, simple à intégrer dans une CI, et très efficace pour valider les manifestes contre des schémas connus.

Son principe est de comparer les ressources générées aux schémas Kubernetes attendus. Il ne se contente donc pas de vérifier que le YAML est bien formé : il valide aussi la structure métier du manifeste, les champs autorisés, les types attendus et certaines incompatibilités de version. Avec l’ajout du catalogue de CRDs, il reste utile même dans des environnements Kubernetes enrichis par des opérateurs.

À l’origine, cet outil est un binaire mais un plugin helm a été fait pour pouvoir être intégré directement dans la CLI de helm.

1
2


helm plugin install https://github.com/jtyr/kubeconform-helm
helm kubeconform .

Configuration de Kubeconform (.kubeconform) :

1
2
3
4
5
6


schema-location:
 - default # Default K8s resources schema
 - https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json
summary: true
verbose: true
ignore-missing-schemas: true # Don't fail on resources where schema is not found.

📝 Note

Ce que kubeconform vérifie :

Champs invalides ou dépréciés

Types de données incorrects

Valeurs manquantes pour les champs requis

Problèmes de compatibilité avec la version Kubernetes ciblée

Exemple de sortie :

1
2
3
4
5
6
7


stdin - Secret mariadb-cluster is valid
stdin - StatefulSet mariadb-cluster is valid
stdin - Cluster pg-cluster is valid
stdin - MongoDBCommunity mongodb-cluster is valid
...
...
Summary: 17 resources found parsing stdin - Valid: 17, Invalid: 0, Errors: 0, Skipped: 0

Tests unitaires

J’ai ajouté Helm Unittest parce qu’au-delà de la syntaxe et de la conformité, il fallait protéger les comportements fonctionnels du chart. C’est l’outil qui me permet de formaliser des attentes explicites : un nom doit suivre une convention, une ressource doit exister dans un cas donné, une image doit être construite avec telle valeur, etc.

Le principe est proche d’un framework de test classique, mais appliqué au rendu Helm. On décrit un jeu de valeurs d’entrée, puis on exprime des assertions sur le manifeste produit. Cette approche est particulièrement utile pour éviter les régressions silencieuses lorsqu’un chart évolue et commence à gérer plusieurs variantes de configuration.

1
2


helm plugin install https://github.com/helm-unittest/helm-unittest.git
helm unittest .

Les tests unitaires permettent de vérifier les comportements attendus du chart dans différentes configurations.

Exemple de test (tests/deployment_test.yaml) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


suite: test deployment
templates:
 - deployment.yaml
tests:
 - it: should create a valid deployment
 set:
 image.tag: latest
 asserts:
 - isKind:
 of: Deployment
 - matchRegex:
 path: metadata.name
 pattern: -my-chart$
 - equal:
 path: spec.template.spec.containers[0].image
 value: nginx:latest

📝 Note

Ces tests vérifient :

Les valeurs par défaut produisent des manifestes valides

Les différentes configurations fonctionnent correctement

Les comportements critiques sont préservés (non-régression)

Release Management

La publication n’est déclenchée que lors de la création d’un tag Git sur la branche main. Ce processus garantit que seules les versions taggées sont publiées, permettant d’accumuler plusieurs modifications avant de créer une release.

Point crucial : Le CHANGELOG

Chaque Merge Request doit inclure une mise à jour du CHANGELOG.md. Ce fichier suit le format Keep a Changelog et utilise le Semantic Versioning.

1
2
3
4
5
6
7
8
9


## [1.1.0] - 2026-01-26

### Added
- Resource limits and requests for all containers

### Changed
- Updated default memory limit to 512Mi

[1.1.0]: https://gitlab.com/project/compare/1.0.9...1.1.0

Catégories disponibles :

Added : Nouvelles fonctionnalités
Changed : Modifications dans les fonctionnalités existantes
Fixed : Corrections de bugs
Removed : Fonctionnalités supprimées

📌 Important

Si une modification introduit un breaking change, cela doit être :

Clairement indiqué dans le CHANGELOG

Expliqué dans la description de la Merge Request

Accompagné d’un guide de migration si nécessaire

Semantic Versioning

Nous suivons strictement le Semantic Versioning (MAJOR.MINOR.PATCH) :

MAJOR : Breaking changes (incompatibilité avec les versions précédentes)
MINOR : Nouvelles fonctionnalités rétrocompatibles
PATCH : Corrections de bugs rétrocompatibles

Exemple :

1.0.9 → 1.1.0 : Ajout de resource limits (rétrocompatible) → MINOR
1.1.0 → 2.0.0 : Changement de structure du values.yaml (breaking) → MAJOR

Bénéfices Observés

Depuis la mise en place de ce workflow, on a pu constater :

Qualité

Zéro breaking change non documenté depuis 6 mois
Réduction de 90% des erreurs de déploiement liées aux charts
Détection précoce des problèmes (avant la revue de code)

Collaboration

Processus clair pour tous les contributeurs (juniors et seniors)
Revues de code plus efficaces (focus sur la logique, pas la syntaxe)
Traçabilité complète des changements via le CHANGELOG

Confiance

Les équipes de développement ont confiance dans la stabilité des charts
Les updates sont moins redoutées car le processus est transparent
Les rollbacks sont facilités par le versioning clair

Productivité

Réduction du temps de validation manuelle
Automatisation de tâches répétitives
Focus sur la valeur ajoutée plutôt que sur la vérification de syntaxe

Diagramme de Séquence

Diagramme de séquence complet

Points d’Attention

Quelques leçons apprises lors de la mise en place :

Tests Unitaires Complets

Ne testez pas uniquement les cas nominaux. Incluez :

Les configurations par défaut
Les cas limites
Les différentes combinaisons de valeurs
Les scénarios de mise à jour

Documentation du CHANGELOG

Le CHANGELOG est le contrat avec les utilisateurs. Il doit être :

Complet : Tous les changements doivent être documentés
Clair : Langage compréhensible, pas de jargon technique inutile
Actionnable : Pour les breaking changes, indiquer quoi faire

Protection de la Branche Main

La protection de main doit être stricte :

Pas de commit direct
Pipeline obligatoire
Approbation obligatoire
Le CHANGELOG doit être à jour avant le merge

Tags Protégés

Restreindre la création de tags aux Maintainers pour éviter les publications accidentelles.

Communication

Lors d’un breaking change, même bien documenté :

Notifier les équipes en avance
Fournir un guide de migration
Offrir du support pendant la transition

Améliorations Futures

Nous envisageons d’ajouter :

Tests de non-régression : Comparer les manifestes générés entre versions avec helm diff
Security scanning : Intégrer des outils comme Trivy pour détecter les vulnérabilités
Policy enforcement : Utiliser des outils comme OPA ou Kyverno pour valider les policies de sécurité
Monitoring des déploiements : Suivre l’adoption des nouvelles versions

Conclusion

La mise en place d’un pipeline de validation rigoureux pour nos Helm charts a transformé notre manière de travailler. L’incident qui nous a poussés à implémenter ce workflow est désormais impossible grâce aux multiples niveaux de validation.

Ce processus garantit non seulement la qualité technique des charts, mais établit également un contrat clair avec les équipes de développement : elles peuvent faire confiance aux charts que nous fournissons, et lorsqu’un breaking change est nécessaire, il est clairement documenté et communiqué.

Pour une équipe SRE, fournir une plateforme fiable est primordial. Ce workflow nous permet de tenir cette promesse tout en gardant la capacité d’évoluer et d’améliorer continuellement nos charts.

Si vous gérez des Helm charts pour une plateforme Kubernetes, je vous encourage vivement à mettre en place un processus similaire. L’investissement initial est rapidement rentabilisé par la réduction des incidents et l’amélioration de la collaboration.

Ressources utiles :

Déployer un cluster Kubernetes avec Ansible

Mon, 24 Nov 2025 10:20:38 +0000

Introduction

Dans mon homelab, j’ai souhaité aller plus loin dans l’automatisation en déployant un cluster Kubernetes complet sur Proxmox, en m’appuyant sur des outils d’infrastructure as code et d’automatisation comme Ansible. L’objectif était de pouvoir provisionner rapidement un cluster k8s reproductible, prêt à accueillir des workloads, tout en gardant la maîtrise de chaque étape du déploiement via du code. Ce processus d’évolution m’a naturellement conduit vers Kubespray.

Contexte

Après avoir initialement installé un cluster Kubernetes de façon manuelle avec kubeadm, j’ai constaté que le processus était particulièrement fastidieux. Cette expérience m’a convaincu de la nécessité d’automatiser et de standardiser le déploiement, afin de gagner en reproductibilité et en efficacité.

C’est là que Kubespray intervient, ce projet open source propose des playbooks Ansible prêts à l’emploi pour installer, configurer et maintenir un cluster Kubernetes avec une approche 100% as code. Contrairement à kubeadm, il offre un contrôle fin sur les composants du cluster (CRI, CNI, DNS, etc.) tout en restant automatisé et reproductible. Dans cet article, je détaille la démarche suivie, les choix techniques réalisés, et les outils utilisés pour atteindre cet objectif.

Logo Kubespray

Prérequis

Avant de commencer le déploiement, il est nécessaire de disposer des ressources suivantes :

Infrastructure :

Au moins 24 GB de RAM disponible sur l’hyperviseur Proxmox
150 GB de stockage libre
Accès réseau avec attribution d’IP statiques
Clé SSH pour l’accès aux VMs

Composants

Proxmox 8.X+ : Fournit l’infrastructure pour exécuter et gérer des machines virtuelles.
Ansible 2.16+ : Outil d’automatisation utilisé par Kubespray pour déployer et configurer Kubernetes.
Terraform 1.10+ & Packer 1.12+ : Pour automatiser la création et la configuration des VMs.

Architecture cible du cluster

Le cluster sera composé de trois nœuds avec le dimensionnement suivant :

Rôle	Hostname	vCPU	RAM	Stockage
Control Plane	k8s-master-01	4	8 GB	50 GB
Worker Node	k8s-worker-01	4	8 GB	50 GB
Worker Node	k8s-worker-02	4	8 GB	50 GB

Architecture cible

Création des VMs

Pour mon homelab, j’ai opté pour une architecture simple composée de trois VMs : un control plane et deux worker nodes.

Ce choix s’explique par plusieurs raisons :

Simplicité pour l’apprentissage : Avec trois nœuds, le cluster reste simple à gérer tout en permettant d’expérimenter la plupart des fonctionnalités Kubernetes (répartition de charge, affinité des pods, tolérance aux pannes, etc.).
Tolérance aux pannes des workers : Deux workers offrent la possibilité de tester des scénarios de panne d’un nœud et d’observer le comportement de Kubernetes lors du rescheduling des pods.
Maîtrise des ressources : Ce dimensionnement reste raisonnable en termes de ressources consommées (4 vCPU, 8 Go RAM, 50 Go stockage par VM), ce qui est important dans un contexte de homelab.

📝 Note

Haute disponibilité : Cette architecture comprend un seul control plane. Pour une véritable haute disponibilité en production, il serait nécessaire de déployer au minimum 3 control planes (nombre impair pour le quorum etcd) avec un load balancer devant les API servers ou bien d’avoir des instances dédiées pour etcd hors du cluster. Dans le cadre de ce homelab, un seul control plane suffit pour les besoins d’apprentissage et d’expérimentation.

Une fois le dimensionnement défini, passons à la création des VMs. Pour cela, j’ai utilisé Terraform et Packer, ce qui me permet de déployer rapidement mon infrastructure de manière totalement automatisée. J’explique en détail cette approche, notamment la création de templates Proxmox avec Packer et leur déploiement avec Terraform, dans mon article sur les templates Proxmox avec Packer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


############################
# VMs for Kubernetes Cluster
############################
resource "proxmox_virtual_environment_vm" "k8s_cluster" {
 for_each = {
 k8s-master = {
 description = "K8S Control Plane"
 vm_id = 110
 ip_address = "192.168.1.110/24"
 tags = ["k8s_cluster", "kube_control_plane", "etcd"]
 }
 k8s-node1 = {
 description = "K8S Worker Node 1"
 vm_id = 111
 ip_address = "192.168.1.111/24"
 tags = ["k8s_cluster", "kube_node"]
 }
 k8s-node2 = {
 description = "K8S Worker Node 2"
 vm_id = 112
 ip_address = "192.168.1.112/24"
 tags = ["k8s_cluster", "kube_node"]
 }
 }

 name = each.key
 description = each.value.description
 tags = concat(["debian12", "terraform"], each.value.tags)
 node_name = "pve"
 vm_id = each.value.vm_id
 pool_id = "PROD"
 reboot_after_update = false

 ...

 clone {
 vm_id = 1101
 datastore_id = "local-lvm"
 full = true
 node_name = "pve"
 }
}

Après l’application du code Terraform, les trois machines virtuelles sont déployées sur Proxmox. Chaque VM est associée à un ou plusieurs tags parmi : (k8s_cluster, kube_control_plane, etcd, kube_node). Ces tags faciliteront la génération de l’inventaire pour Kubespray que je détaille plus bas dans l’article.

VMs dans Proxmox

Configuration réseau et accès SSH

Grâce à l’utilisation de Cloud-Init lors du processus de la création des VMs (via le template Packer et l’argument initialization dans la ressource proxmox_virtual_environment_vm du provider Terraform), la configuration réseau et l’accès SSH sont automatisés :

Adresse IP statique : Chaque VM reçoit directement son IP statique lors du déploiement, définie dans la section ip_config de Terraform. Cela évite toute configuration manuelle post-déploiement.
Clé SSH : La clé publique SSH est injectée automatiquement dans chaque VM via Cloud-Init, ce qui permet une connexion immédiate sans avoir à copier la clé manuellement.

Ce processus permet de gérer toutes les VMs via Ansible dès leur création, sans intervention manuelle supplémentaire. Dans mon cas, je peux donc directement utiliser les playbooks Kubespray.

⚠️ Avertissement

Dans un environnement de production, il est recommandé de gérer les secrets (tokens API Proxmox, clés SSH, etc.) avec des outils dédiés comme Ansible Vault ou des gestionnaires de secrets externes.

Les ressources sont désormais prêtes et configurées, nous pouvons maintenant passer à la mise en place du cluster Kubernetes avec Kubespray.

Mise en place de Kubespray

Cloner et configurer le dépôt Kubespray

J’ai intégré Kubespray dans mon projet en tant que submodule git. Ceci permet d’inclure un autre repository tout en gardant son historique séparé. Cela facilite la gestion des dépendances et permet de suivre une version précise de Kubespray, la mettre à jour facilement, et avoir les évolutions du projet sans mélanger les codes sources.

1

git submodule add https://github.com/kubernetes-sigs/kubespray.git kubespray

Afin de fixer la version du submodule sur un tag ou un commit spécifique, il faut se rendre dans le répertoire du submodule et checkout sur le commit ou tag désiré dans le projet. Ensuite, il faut retourner dans le répertoire principal du projet, commit les changements et pousser les modifications.

1
2
3
4


cd kubespray/
git checkout v2.27.0 # Version utilisée pour ce déploiement
cd ../
git commit -m "Pinned submodule to v2.27.0"

Il est important de fixer la version de Kubespray afin de garantir la reproductibilité des déploiements et d’éviter toute instabilité liée à des changements non maîtrisés dans le projet en amont.

Une fois le projet Kubespray intégré et configuré dans le dépôt Ansible, on peut passer à la génération de l’inventaire pour Kubespray.

Création de l’inventaire Kubespray

Pour la partie inventaire ansible pour Kubespray, j’ai choisi la solution de l’inventaire dynamique avec Proxmox. Ceci permet d’avoir un inventaire qui est constamment à jour, car il est chargé sur chaque lancement de playbook, ce qui évite une maintenance manuelle du fichier d’inventaire.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


plugin: community.general.proxmox
url: https://<proxmox_host>:8006
user: "<user>"
token_id: "<token_id>"
token_secret: "<token_secret>"
validate_certs: false # Uniquement dans le cadre d'un homelab
want_facts: true
keyed_groups:
 - key: proxmox_tags_parsed
 separator: ""
compose:
 ansible_host: proxmox_agent_interfaces[1]["ip-addresses"][0].split('/')[0]

L’inventaire ci-dessus permet de récupérer toutes les VMs dans Proxmox et de les regrouper par tags proxmox_tags_parsed et de configurer la variable ansible_host de chaque entrée dans l’inventaire avec l’IP associée à chaque VM.

Dans le cas de Kubespray, il faut respecter la nomenclature des tags comme c’est écrit dans la documentation, car c’est ce qui va servir à lancer les playbooks sur les bons hôtes.

Pour générer l’inventaire, j’utilise la commande ci-dessous, où l’option --graph va permettre de rendre la sortie de la commande un peu plus visuelle afin de bien distinguer les groupes et les hôtes de l’inventaire ansible.

1

ansible-inventory -i inventories/proxmox.yml --graph

Et dans mon cas ça donne le résultat suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


@all:
 ...
 ...
 |--@debian12:
 | |--k8s-node1
 | |--k8s-master
 | |--k8s-node2
 |--@k8s_cluster:
 | |--k8s-node1
 | |--k8s-master
 | |--k8s-node2
 |--@kube_node:
 | |--k8s-node1
 | |--k8s-node2
 |--@terraform:
 | |--k8s-node1
 | |--k8s-master
 | |--k8s-node2
 |--@etcd:
 | |--k8s-master
 |--@kube_control_plane:
 | |--k8s-master
 ...
 ...

Une fois l’inventaire en place, je peux tester la connectivité des VMs via la commande ad hoc ci-dessous qui utilise le module ansible ping :

1

ansible -i inventories/proxmox.yml k8s_cluster -m ping -u <username>

Ce qui donne le résultat suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


k8s-node1 | SUCCESS => {
 "changed": false,
 "ping": "pong"
}
k8s-master | SUCCESS => {
 "changed": false,
 "ping": "pong"
}
k8s-node2 | SUCCESS => {
 "changed": false,
 "ping": "pong"
}

Maintenant que je dispose de l’inventaire dynamique pour Proxmox et de machines virtuelles accessibles, je vais pouvoir passer à la partie customisation de mon cluster K8s.

Personnalisation des variables

Afin de pouvoir customiser le cluster Kubernetes, il va falloir passer par les group_vars ansible. Grâce à ces variables, nous allons pouvoir configurer différents aspects du cluster tels que :

Paramétrage Kubernetes (version de kube, réseau interne, DNS,…)
Container Runtime Interface (CRI)
Container Network Interface (CNI)
Container Storage Interface (CSI)
Configuration ETCD
Addons et composants optionnels (ArgoCD, Helm, cert-manager, MetalLB, …)
Et bien d’autres choses…

Ces variables sont organisées dans différents fichiers de l’inventaire pour une meilleure structuration de la configuration :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


inventories/group_vars/
├── etcd
│ ├── all.yml
│ └── etcd.yml
└── k8s_cluster
 ├── addons.yml
 ├── all.yml
 ├── cri-o.yml
 ├── k8s-cluster.yml
 └── k8s-net-flannel.yml

Pour plus d’informations à propos de la configuration possible du cluster Kubernetes et des composants disponibles, il faut se référer à la documentation de Kubespray.

📝 Note

Dans le cadre de cet article, j’utilise principalement les configurations par défaut proposées par Kubespray. L’objectif est de montrer le processus de déploiement plutôt que de justifier des choix techniques spécifiques pour chaque composant (CNI, CRI, etc.). Ces choix peuvent être adaptés en fonction des besoins spécifiques de chaque projet.

La configuration cible du cluster Kubernetes a été définie, la prochaine étape va être le déploiement !

Déploiement du cluster Kubernetes

Avant de lancer le déploiement avec ansible, j’ai besoin de configurer mon environnement, pour ce faire, je passe par un venv python afin de fixer la version d’ansible ainsi que de mes dépendances dans le but d’isoler le tout pour éviter les potentiels conflits avec d’autres projets. Le venv va également permettre d’avoir un environnement reproductible ce qui est crucial pour exécuter les déploiements de manière identique.

1
2
3


python3 -m venv venv
source venv/bin/activate
pip install -r kubespray/requirements.txt

Une fois l’environnement prêt, il est enfin temps de passer au déploiement du cluster, en lançant le playbook cluster.yml et en utilisant l’inventaire dynamique ansible pour Proxmox configuré au préalable.

1

ansible-playbook -i inventories/proxmox.yml -b -u <username> kubespray/cluster.yml

Une fois le playbook terminé, le cluster Kubernetes est prêt à l’emploi avec la configuration définie plus haut.

1
2
3
4


PLAY RECAP *************************************************************************
k8s-master: ok=599 changed=39 unreachable=0 failed=0 skipped=965 rescued=0 ignored=1
k8s-node1 : ok=421 changed=25 unreachable=0 failed=0 skipped=618 rescued=0 ignored=1
k8s-node2 : ok=443 changed=28 unreachable=0 failed=0 skipped=681 rescued=0 ignored=1

Vérification du cluster

Une fois le déploiement terminé, il est essentiel de vérifier que le cluster Kubernetes est opérationnel et que tous les composants fonctionnent correctement. Pour cela, plusieurs commandes kubectl permettent de valider l’état des nœuds et des pods.

Pour valider l’état des nœuds du cluster :

1

kubectl get nodes

Résultat obtenu :

1
2
3
4


NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane 1d v1.31.4
k8s-node1 Ready worker 1d v1.31.4
k8s-node2 Ready worker 1d v1.31.4

Tous les nœuds doivent être dans l’état Ready, ce qui indique qu’ils sont prêts à exécuter des workloads.

Pour s’assurer que tous les pods sont en état de fonctionnement, il faut passer par la commande :

1

kubectl get pods -A

Résultat obtenu :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


NAMESPACE NAME READY STATUS RESTARTS AGE
external-dns external-dns-754bcb687f-cqncz 1/1 Running 0 24h
ingress-nginx ingress-nginx-controller-6d7ff9f49f-2b9dq 1/1 Running 0 24h
kube-system coredns-d665d669-7h6nf 1/1 Running 0 24h
kube-system coredns-d665d669-fklwz 1/1 Running 0 24h
kube-system dns-autoscaler-5cb4578f5f-zkr67 1/1 Running 0 24h
kube-system kube-apiserver-k8s-master 1/1 Running 0 24h
kube-system kube-controller-manager-k8s-master 1/1 Running 0 24h
kube-system kube-flannel-9n6zs 1/1 Running 0 24h
kube-system kube-flannel-m5xtr 1/1 Running 0 24h
kube-system kube-flannel-qchzm 1/1 Running 0 24h
kube-system kube-proxy-54k4k 1/1 Running 0 24h
kube-system kube-proxy-qpb4m 1/1 Running 0 24h
kube-system kube-proxy-zq7ww 1/1 Running 0 24h
kube-system kube-scheduler-k8s-master 1/1 Running 0 24h
kube-system nginx-proxy-k8s-node1 1/1 Running 0 24h
kube-system nginx-proxy-k8s-node2 1/1 Running 0 24h
kube-system nodelocaldns-l2nc4 1/1 Running 0 24h
kube-system nodelocaldns-pp8ng 1/1 Running 0 24h
kube-system nodelocaldns-x522v 1/1 Running 0 24h
kubernetes-dashboard kubernetes-dashboard-8984b9757-2pcmz 1/1 Running 0 24h
kubernetes-dashboard kubernetes-metrics-scraper-6d4c5d99f9-z6g6b 1/1 Running 0 24h
metallb-system controller-7f649565d4-6dcd8 1/1 Running 0 24h
metallb-system speaker-6pj99 1/1 Running 0 24h
metallb-system speaker-v44zd 1/1 Running 0 24h
metallb-system speaker-w8wzp 1/1 Running 0 24h

Tous les pods doivent être dans l’état Running. Cela garantit que les composants du cluster sont correctement déployés et fonctionnels.

Ces vérifications permettent de valider que le cluster Kubernetes est prêt à accueillir des workloads et que les services essentiels sont opérationnels.

Résultat

Cluster Kubernetes post déploiement

Opérations post-déploiement

Gestion du cycle de vie

Kubespray ne se limite pas au déploiement initial, il propose également des playbooks pour gérer le cycle de vie complet du cluster :

Ajout de nœuds :

1
2


# Pour ajouter un nouveau worker node au cluster
ansible-playbook -i inventories/proxmox.yml -b -u <username> kubespray/scale.yml

Mise à jour du cluster :

1
2


# Pour mettre à jour la version de Kubernetes ou des composants
ansible-playbook -i inventories/proxmox.yml -b -u <username> kubespray/upgrade-cluster.yml

Réinitialisation complète :

1
2


# Pour supprimer complètement le cluster
ansible-playbook -i inventories/proxmox.yml -b -u <username> kubespray/reset.yml

Conclusion

L’automatisation du déploiement d’un cluster Kubernetes avec ansible via le projet Kubespray permet de gagner en fiabilité, en rapidité et en reproductibilité, ce qui est essentiel pour moi dans mon contexte de homelab.

Grâce à l’inventaire dynamique et aux variables ansible, il est simple d’adapter la configuration du cluster en fonction de mes besoins, tout en gardant la maîtrise sur chaque composant. Cette approche permet également de faciliter la maintenance et l’évolution du cluster k8s, car tout est fait as code et que kubespray prévoit également des playbooks pour ajouter un nœud dans le cluster (scale.yml) ou même remettre le cluster à zéro (reset.yml).

Workflow

Résumé du workflow

Liens utiles

Template pour VM dans Proxmox

Fri, 28 Feb 2025 10:20:38 +0000

Introduction

Dans mon homelab, j’ai récemment travaillé sur un projet qui m’a permis de créer des templates de machines virtuelles (VM) sur Proxmox en utilisant une combinaison d’outils tels que Packer, Cloud-Init et Terraform. L’objectif était de pouvoir créer des VMs de manière automatisée et répétable, tout en minimisant les interventions manuelles.

Contexte

Gérer les VMs et leurs configurations manuellement peut vite devenir une tâche fastidieuse, surtout lorsqu’il s’agit de déployer plusieurs instances avec des configurations quasiment identiques à chaque fois. J’avais donc besoin d’une solution pour standardiser tout ce processus et ainsi avoir un template de VM prêt à l’emploi afin de l’utiliser comme base dans toutes mes VMs.

Je vais expliquer dans la suite de cet article comment j’ai atteint mon objectif grâce à différents outils dans le but d’optimiser les déploiements sur mon homelab.

Composants

Proxmox : Fournit l’infrastructure pour exécuter et gérer des machines virtuelles.
Packer : Automatise l’installation et la configuration de l’OS pour produire une image ou un template standardisé.
Terraform : Permet de définir, provisionner et gérer des infrastructures via du code déclaratif.
Cloud-Init : Permet la configuration dynamique des machines au premier démarrage.

Packer

Packer est un outil communautaire permettant de créer des images de machines identiques pour plusieurs plateformes à partir d’une configuration source unique. Pour ce faire, Packer va utiliser ce qui s’appelle des builders qui sont des composants de Packer capables de créer un template/ une image de machine virtuelle sur une plateforme spécifique.

Logo Packer

Dans mon cas, je vais simplement utiliser Packer sur mon environnement Proxmox grâce à son builder dédié.

1
2
3
4
5
6
7
8
9


#packer.pkr.hcl
packer {
 required_plugins {
 name = {
 version = "1.2.2"
 source = "github.com/hashicorp/Proxmox"
 }
 }
}

Configuration du template

Ce builder permet de soit cloner une machine virtuelle pour en faire un template (Proxmox-clone) ou bien de créer un template de machine virtuelle depuis un ISO source (Proxmox-iso). Afin de répondre à mon besoin initial, je vais utiliser le builder Proxmox-iso. Pour ce qui est de la configuration, j’ai utilisé la documentation du builder.

Exemple de fichier packer.pkr.hcl :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


#packer.pkr.hcl
source "Proxmox-iso" "debian12" {
 # Proxmox server
 Proxmox_url = "proxmox_api_url"
 node = "pve"
 username = "<Proxmox_token_id>"
 token = "<Proxmox_token>"
 insecure_skip_tls_verify = true

 # VM Info
 template_name = "pckr-debian-12"
 vm_name = "pckr-debian-12"
 template_description = "Debian 12.9.0, generated on ${timestamp()}"
 tags = "template;debian12"
 vm_id = 1101
 pool = "TEMPLATE"
 os = "l26"
 machine = "q35"

 # Boot
 boot_iso {
 type = "scsi"
 iso_file = "local:iso/debian-12.9.0-amd64-netinst.iso"
 unmount = true
 iso_checksum = "none"
 }
 boot_command = ["<esc><wait>auto console-keymaps-at/keymap=fr console-setup/ask_detect=false debconf/frontend=noninteractive fb=false url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg<enter>"]
 boot_wait 	 = "10s"
 http_directory = "http"

 # Disks
 disks {
 type = "scsi"
 storage_pool = "local-lvm"
 disk_size = "30G"
 format = "raw"
 }

 # Networks
 network_adapters {
 bridge = "vmbr0"
 model = "virtio"
 }

 # Spec
 bios = "seabios"
 qemu_agent = true
 scsi_controller = "virtio-scsi-pci"
 cpu_type = "x86-64-v2-AES"
 sockets = 1
 cores = 1
 memory = 1024
 ballooning_minimum = 1024

 # Communication
 communicator = "ssh"
 ssh_handshake_attempts = 5
 ssh_pty = true
 ssh_timeout = "10m"
 ssh_username = <username>
 ssh_password = <password>

 # Cloud-init
 cloud_init = "true"
 cloud_init_storage_pool = "local-lvm"
}

Dans ce fichier packer.pkr.hcl, je donne au builder les informations à propos de la machine cible ainsi que les spécifications de celle-ci pour Proxmox, mais également les informations à propos du boot (chemin du fichier ISO, commande lors du boot, etc).

Fichier preseed

La partie boot va permettre de donner à la machine virtuelle, futur template, le chemin du fichier preseed.cfg auto-hébergé sur un serveur web lancé par Packer lors du processus. Ce fichier permet de répondre aux questions posées au cours du processus d’installation de l’OS, sans avoir à saisir manuellement les réponses pendant l’installation, cela permet d’automatiser entièrement l’installation. Un exemple de ce fichier est disponible sur la documentation debian.

Création du template

Une fois la configuration prête, il faut lancer la construction du template via la CLI de Packer avec les commandes ci-dessous :

1
2
3
4
5
6
7
8


# Initialisation du dépôt pour récupérer les dépendances
packer init packer.pkr.hcl

# Validation de la syntaxe et configuration
packer validate packer.pkr.hcl

# Construction de l'image, en remplaçant le template si déjà existant
packer build -on-error=ask -force packer.pkr.hcl

Le template est désormais bien présent dans Proxmox avec toutes les caractéristiques que j’ai indiquées dans le fichier packer.pkr.hcl et il est désormais prêt à être utilisé pour de futurs déploiements de machine virtuelle.

Template dans Proxmox

Maintenant passons à l’étape suivante : la configuration dynamique avec Cloud-Init !

Cloud-init

Cloud-Init est un outil open-source permettant d’automatiser la configuration initiale des machines virtuelles lors de leur premier démarrage. En utilisant des fichiers de configuration (user-data et meta-data), Cloud-Init peut effectuer diverses tâches comme la création d’utilisateurs, l’injection de clés SSH, la configuration réseau ou encore l’installation de paquets. Cet outil est compatible avec de nombreuses plateformes cloud et environnements de virtualisation, offrant ainsi une méthode agnostique pour personnaliser dynamiquement les instances sans intervention manuelle.

Logo Cloud-Init

Exemple de fichier user-data :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


#user-data.yml
#cloud-config
ssh_pwauth: false
disable_root: true
users:
 - name: user
 gecos: user
 groups: users, sudo
 shell: /bin/bash
 ssh_authorized_keys:
 - ssh-ed25519 AAAA.......
 sudo: ALL=(ALL) NOPASSWD:ALL
 lock_passwd: true
package_update: true
package_upgrade: true

Dans mon cas, j’ai choisi d’utiliser cloud-init pour me permettre de :

Désactiver l’authentification par mot de passe via SSH et également le compte root.
Créer un utilisateur avec une clé SSH autorisée, un accès sudo sans mot de passe et un mot de passe verrouillé.
Effectuer automatiquement les mises à jour et les montées de version des paquets.

Une fois appliqué au premier démarrage de la machine, celle-ci est prête à l’emploi, et aussi prête à recevoir du provisionnement via un outil comme Ansible. C’était l’objectif recherché de mon côté, car je souhaitais pouvoir lancer mes playbooks Ansible via une connexion par clé SSH une fois la machine virtuelle déployée sans avoir à copier manuellement ma clé ou bien devoir me connecter une première fois via un mot de passe.

Terraform

Afin de pouvoir déployer ma machine virtuelle grâce à mon template et au fichier cloud-init, j’ai fait le choix d’utiliser terraform. Terraform est un outil d’infrastructure as code, c’est-à-dire un outil qui permet de définir son infrastructure via des fichiers de configuration déclaratifs au format HCL (Hashicorp Configuration Language). Pour réaliser ceci, Terraform se repose sur des providers qui vont permettre la communication avec l’infrastructure sous-jacente. Cette méthode permet de gérer l’infrastructure comme du code, ce qui simplifie la gestion des versions et la reproductibilité des déploiements.

Ces plugins mettent à disposition des types de ressources (créer/modifier des ressources) et des sources de données (lecture d’informations existantes) qui permettent à Terraform de manager l’infrastructure derrière ce plugin. Les providers passent par le SDK ou bien l’API du fournisseur afin de réaliser toutes les actions indiquées par la configuration Terraform.

Logo Terraform

Dans le cas de mon homelab, j’ai fait le choix d’utiliser le provider bpg, qui est un provider réalisé par un membre de la communauté et qui permet de gérer tout son environnement Proxmox (resource pool, users, VM, ISO).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#providers.tf
provider "proxmox" {
 endpoint = var.endpoint
 api_token = var.api_token
 insecure = true
 ssh {
 agent = false
 username = "root"
 private_key = var.private_key
 }
}

Pour le déploiement de la machine virtuelle en utilisant le template et cloud-init pour le provisionnement, j’ai utilisé la ressource proxmox_virtual_environment_vm, qui permet de créer/gérer une machine virtuelle en lui passant toutes les caractéristiques nécessaires.

Exemple de ressource terraform pour une machine virtuelle dans Proxmox :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


#virtual_machine.tf
resource "proxmox_virtual_environment_vm" "example_vm" {
 name = "example"
 description = "example VM"
 tags = ["debian12", "terraform"]
 node_name = "pve"
 vm_id = 101
 pool_id = "example"
 reboot_after_update = false
 
 agent {
 enabled = true
 }
 
 cpu {
 cores = 2
 sockets = 1
 type = "x86-64-v2-AES"
 }
 
 memory {
 dedicated = 4096
 floating = 4096
 }

 initialization {
 user_data_file_id = proxmox_virtual_environment_file.user_data_cloud_config.id
 dns {
 servers = ["9.9.9.9", "1.1.1.1"]
 }
 ip_config {
 ipv4 {
 address = "192.168.1.101/24"
 gateway = "192.168.1.1"
 }
 }
 }

 clone {
 vm_id = 1101
 datastore_id = "local-lvm"
 full = true
 node_name = "pve"
 }
}

Mais dans mon cas les paramètres qui m’intéressent sont :

initialization : Configuration pour cloud-init où je spécifie la configuration DNS, l’adresse IP de ma machine et je donne l’ID de mon fichier cloud-init également managé via terraform via la ressource proxmox_virtual_environment_file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


initialization {
 user_data_file_id = proxmox_virtual_environment_file.user_data_cloud_config.id
 dns {
 servers = ["9.9.9.9", "1.1.1.1"]
 }
 ip_config {
 ipv4 {
 address = "192.168.1.101/24"
 gateway = "192.168.1.1"
 }
 }
}

clone : Configuration du clonage où je donne les informations à propos de mon template présent dans Proxmox.

1
2
3
4
5
6


clone {
 vm_id = 1101
 datastore_id = "local-lvm"
 full = true
 node_name = "pve"
}

Je peux déclencher mon projet qui contient mon Infrastructure as Code, en y ajoutant la nouvelle ressource. Et terraform va s’occuper de cloner le template et de lui fournir la configuration cloud-init afin de provisionner la machine virtuelle.

J’ai donc comme résultat une VM avec une configuration standard que j’ai définie pour correspondre à mon besoin et qui est prête à recevoir du provisionnement avec un outil comme Ansible.

Diagramme de séquence

Conclusion

En conclusion, la mise en place d’un processus automatisé pour la création et le déploiement de machines virtuelles sur Proxmox via Packer, Cloud-Init et Terraform m’a permis de gagner en efficacité, en reproductibilité et en flexibilité dans mon homelab.

Ce workflow garantit une standardisation des environnements, réduit le risque d’erreurs manuelles et facilite le provisionnement des machines avec Ansible ou d’autres outils d’automatisation. Grâce à cette solution, je peux désormais déployer rapidement des machines virtuelles prêtes à l’emploi, tout en adaptant leur configuration selon mes besoins.

Secret Kubernetes depuis Azure Key Vault

Sat, 23 Nov 2024 10:20:38 +0000

Introduction

La gestion sécurisée des secrets dans Kubernetes est cruciale pour maintenir la sécurité dans nos applications. Dans cet article, je vais donc présenter la gestion des secrets dans Kubernetes en utilisant External Secrets Operator et Azure Key Vault via une authentification par workload identity. Ceci dans le but d’avoir une solution robuste et sécurisée.

Contexte

J’ai mis en place cette solution dans le cadre d’un projet d’une semaine durant mon master. Le but était le déploiement d’une stack applicative dans le cloud via un workflow GitOps. Le projet est disponible sur le groupe GitLab projet-cicd-m2-do.

Dans ce projet, un cluster Azure Kubernetes Service (AKS) était déployé via terraform avec la configuration suivante requise pour mettre en place la solution :

1

oidc_issuer_enabled = true

⬆️ Permet d’activer l’émetteur OIDC (OpenID Connect) du cluster AKS. Cela signifie que le cluster AKS génère une URL d’émission de token OIDC, essentielle pour la relation de confiance que je vous présente plus tard dans cet article.

📝 Note

L’OIDC est un protocole d’authentification moderne qui repose sur le standard OAuth 2.0. Il permet à des applications de vérifier l’identité d’un utilisateur en s’appuyant sur un fournisseur d’identité et de récupérer des informations sur cet utilisateur de manière sécurisée.

1

workload_identity_enabled = true

⬆️ Active la fonctionnalité Azure Workload Identity, pour permettre aux pods Kubernetes d’accéder aux ressources Azure en utilisant les identités managées.

Composants

External Secret Operator (ESO) : Opérateur Kubernetes qui permet d’intégrer un système de gestion des secrets externes.
Azure Key Vault : Service cloud Azure permettant de stocker les secrets et d’y accéder en toute sécurité.
Workload Identity : Méthode pour s’authentifier à une ressource Azure sans explicitement configurer des identifiants

Azure Key Vault

Dès que le cluster AKS est opérationnel, il faut déployer la ressource Azure Key Vault. Pour ce faire, j’ai utilisé terraform afin de pouvoir faire de l’IaC pour fiabiliser et automatiser mon déploiement. Pour le vault ainsi que les autres ressources Azure, j’ai utilisé le provider terraform azurerm.

Le code suivant va permettre la création du vault dans le resource group et la location définis, avec le RBAC (Role Based Access Control) activé pour manager les accès et le SKU (Stock Keeping Unit) sur standard. D’autres arguments sont disponibles, mais j’ai préféré simplifier au vu de la durée du projet afin d’avoir un POC rapidement.

1
2
3
4
5
6
7
8
9


resource "azurerm_key_vault" "vault" {
 name = join("-", [var.prj, var.org, "vault"])
 location = var.location
 resource_group_name = azurerm_resource_group.aks.name
 tenant_id = data.azurerm_client_config.current.tenant_id

 sku_name = "standard"
 enable_rbac_authorization = true
}

Une fois le vault déployé, on peut mettre ses secrets dedans via l’UI ou la CLI d’azure.

Azure Vault UI

Managed Identity

Une fois le vault déployé, il va falloir associer le rôle à la bonne identité afin de pouvoir accéder à nos secrets au travers de celle-ci.

Kubelet Identity

Lors de la création d’un cluster AKS, une managed identity de type user assigned va être créée dans le resource group, celui-ci est géré automatiquement par Azure et permet de stocker les ressources infrastructures réelles nécessaires au fonctionnement du cluster AKS. Cette identité managée se nomme kubelet_identity et elle va permettre au kubelet présent sur les nœuds du cluster d’accéder à d’autres ressources Azure. C’est au travers de cette identité que je vais pouvoir accéder au vault.

Interaction entre Kubelet Identity et les ressources Azure

J’ai assigné à cette identité les droits de lecture sur les secrets présents dans le vault grâce au rôle Key Vault Secrets User :

1
2
3
4
5


resource "azurerm_role_assignment" "keyvault_secrets_user" {
 scope = azurerm_key_vault.vault.id
 role_definition_name = "Key Vault Secrets User"
 principal_id = azurerm_kubernetes_cluster.aks.kubelet_identity[0].object_id
}

Fédération d’identité

Lorsque les bons droits sont assignés, il va falloir lier cette identité à un service account dans Kubernetes afin de pouvoir accéder aux données de mon vault dans Azure.

Pour ce faire, il faut utiliser une federated identity credential qui va permettre de déléguer l’authentification à un fournisseur d’identité externe dans mon cas le cluster AKS et ainsi créer une relation de confiance entre AKS et l’identité managée dans Microsoft Entra ID.

1
2
3
4
5
6
7
8


resource "azurerm_federated_identity_credential" "identity" {
 name = "kub-federated-identity"
 resource_group_name = azurerm_kubernetes_cluster.aks.node_resource_group
 audience = ["api://AzureADTokenExchange"]
 issuer = azurerm_kubernetes_cluster.aks.oidc_issuer_url
 parent_id = azurerm_kubernetes_cluster.aks.kubelet_identity[0].user_assigned_identity_id
 subject = "system:serviceaccount:default:workload-identity-sa"
}

Ici l’audience représente le destinataire prévu du jeton émis par l’émetteur de l’OIDC, le subject correspond à l’identité de l’entité (le service account dans mon cas) à laquelle l’identité fédérée est associée et issuer est l’URL d’émetteur OIDC du cluster AKS.

Diagramme de séquence

Voici un diagramme un peu plus précis sur le mécanisme de connexion au Vault via identité managée et fédération :

Diagramme de séquence pour la connexion au Vault

External Secrets Operator

Désormais, il faut mettre en place l’opérateur Kubernetes, External Secrets Operator (ESO) afin de pouvoir effectuer la connexion au vault via le provider Azure Key Vault fourni par ESO. Pour ce faire, des Custom Resource Definitions (CRD) existent et permettent de définir comment accéder au vault (Secret Store) et quelles sont les données à récupérer (External Secret).

Secret Store

Dans cette ressource, il faut spécifier l’URL du vault, l’id du tenant Azure, le type d’authentification et le service account associé. C’est avec le secret store que je vais pouvoir me connecter à Azure Key Vault.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
 name: azure-secret-store
spec:
 provider:
 azurekv:
 authType: WorkloadIdentity
 vaultUrl: ${azurerm_key_vault.vault.vault_uri}
 tenantId: ${azurerm_key_vault.vault.tenant_id}
 serviceAccountRef:
 name: workload-identity-sa

External Secret

Cette ressource va permettre de définir quel secret j’ai besoin de synchroniser entre le vault et le secret Kubernetes. Il faut définir le secret store à utiliser, notre secret cible dans Kubernetes et les secrets à récupérer depuis le vault Azure.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
 name: my-secret
spec:
 refreshInterval: 30s
 secretStoreRef:
 name: azure-secret-store
 kind: SecretStore
 target:
 name: ocf-secret
 data:
 - secretKey: pgadmin-password
 remoteRef:
 key: pgadmin-password

Service Account

Il faut également créer le service account en lui ajoutant l’annotation suivante afin de l’associer à l’ID de l’identité : Kubelet Identity.

1
2
3
4
5
6
7


apiVersion: v1
kind: ServiceAccount
metadata:
 annotations:
 azure.workload.identity/client-id: "${azurerm_kubernetes_cluster.aks.kubelet_identity[0].client_id}"
 name: workload-identity-sa
 namespace: default

Déploiement

Pour la partie déploiement, je suis aussi passé par du terraform en utilisant le provider helm et kubectl. Ceci permet d’avoir une infrastructure unifiée et automatisée de bout en bout.

Déploiement avec terraform

ESO

Pour ESO, une chart helm est fournie dans la documentation, celle-ci est déployée dans le namespace external-secrets. Cette ressource terraform attend la fin du déploiement du cluster AKS pour être créée grâce au depends_on = [azurerm_kubernetes_cluster.aks].

1
2
3
4
5
6
7
8
9


resource "helm_release" "eso" {
 depends_on = [azurerm_kubernetes_cluster.aks]
 name = "external-secrets"
 namespace = "external-secrets"
 repository = "https://charts.external-secrets.io"
 chart = "external-secrets"
 create_namespace = true
 version = "0.10.5"
}

Déploiement des pods ESO

Une fois ESO déployé, il faut créer nos CRD afin de configurer la connexion au vault et les secrets à récupérer mais également le service account. Tout ceci à l’aide de manifests Kubernetes qui permettent de déclarer les ressources en yaml.

CRD et Service Account

Pour les manifests, l’utilisation du provider terraform kubectl va me permettre d’utiliser des variables des ressources terraform directement dans les manifests pour avoir quelque chose de dynamique, comme on peut voir dans ce manifest. Ceci évite alors de mettre des informations sensibles en dur dans les manifests.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


resource "kubectl_manifest" "sa" {
 depends_on = [helm_release.eso]
 yaml_body = <<YAML
apiVersion: v1
kind: ServiceAccount
.....
YAML
}

resource "kubectl_manifest" "secretstore" {
 depends_on = [kubectl_manifest.sa]
 yaml_body = <<YAML
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
.....
YAML
}

resource "kubectl_manifest" "externalsecret" {
 depends_on = [kubectl_manifest.secretstore]
 yaml_body = <<YAML
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
.....
YAML
}

Les 3 ressources terraform sont déclarées, elles correspondent aux 3 manifests / ressources Kubernetes qu’il faut créer dans le cluster pour configurer et utiliser ESO.

Résultat

La connexion à Azure Key Vault est validée. Ceci grâce à la ressource secret-store.

Connexion à Azure Key Vault avec le secret store

Une fois connecté au vault, la synchronisation des secrets va s’effectuer. On peut le voir sur la ressource external-secret qui est dans l’état SecretSynced. Ceci va donc récupérer les secrets du vault et les mettre dans un secret Kubernetes.

Synchronisation des secrets entre le vault et Kubernetes

Le secret a bien été créé et il est bien présent dans Kubernetes comme on peut le voir. Pour cette démonstration les passwords sont tous les mêmes, ce qui est bien sûr à ne pas faire dans un environnement de production.

Secret Kubernetes

Conclusion

La mise en place de cette solution sur un temps restreint a été un réel challenge pour moi, car je n’avais jamais réalisé ceci auparavant. J’ai pu travailler et approfondir mes compétences sur Azure et plus spécifiquement les rôles et identités de ce cloud provider.

L’objectif a été atteint, et la complexité de la solution m’a motivé à rédiger cet article, premièrement afin d’avoir une trace de cette réalisation en faisant un retour d’expérience, mais également dans le but de pouvoir aider les personnes qui tomberont tôt ou tard dessus.

Veille Technologique

Fri, 01 Nov 2024 22:56:48 +0000

L’importance de la veille technologique

En tant que DevOps, la veille technologique est une pratique cruciale, elle va permettre de se maintenir à jour et de surveiller de manière constante l’apparition de nouveaux outils dans un domaine qui est en constante évolution.

Ceci pour différentes raisons, premièrement en tant que DevOps, il faut constamment trouver des solutions permettant d’améliorer les pipelines CI/CD et les différents process en place en entreprise, la recherche de nouveaux outils, nouvelles versions ou nouvelles technologies est donc primordiale.

Ensuite, dans mon cas, cette veille va me permettre d’être force de proposition et de devenir un élément moteur dans mon environnement en apportant ma connaissance sur des sujets récents.

Outils pour la veille technologique

Les outils utilisés pour la veille sont le nerf de la guerre, ce sont eux qui permettent une gestion rapide et efficace de cette veille. Il faut donc réévaluer périodiquement ces outils afin qu’ils ne deviennent pas obsolètes et qu’ils conviennent toujours au besoin.

Il est de ce fait nécessaire de faire une veille sur ses outils de veille !

Feeder

Après avoir passé quelque temps à utiliser feedly quotidiennement, je n’étais pas convaincu par l’application, j’avais besoin d’un outil plus simple et plus épuré.

Suite à des recherches, je suis tombé sur Feeder, un lecteur/agrégateur de flux RSS open source disponible sur Android. L’application ne nécessite pas de connexion via un compte et elle tourne localement ce qui permet d’avoir de la confidentialité sur mes données.

Niveau design l’application est très simpliste et épuré et ceci se confirme aussi dans sa configuration qui possède les mêmes atouts. Feeder permet également de sauvegarder des articles, les ajouter en favoris ou même d’effectuer des backups de sa configuration. Ce sont des fonctionnalités très pratiques et nécessaires à un outil de ce type.

Interface Feeder

Feeder me permet donc de récupérer les articles de mes principaux sites d’IT cités dans la partie suivante et de pouvoir les rendre accessibles depuis l’application. Je peux profiter par exemple des temps de transport afin de quotidiennement effectuer ma veille.

Je répartis les flux RSS dans différentes catégories en fonction de leur domaine :

DevOps
Linux
IT Global
Cybersécurité

Wiki

Après avoir récolté des informations via mes différentes sources, je dois les trier dans le but de garder exclusivement celles que je trouve intéressantes et/ou utiles. Une fois le tri effectué, je mets en forme les différents éléments que j’ai conservés afin de les mettre dans mon wiki. (J’ai justement écrit un article sur la création de ce wiki.)

Ceci permet donc d’avoir un rendu propre et condensé afin de pouvoir retrouver les éléments qui m’intéressent en un rien de temps ce qui est tout le but de la veille pour moi.

Sources d’information

Pour ce qui est des sources d’informations, j’en utilise plusieurs mais je trouve que le format article / post est le meilleur, celui qui me correspond le plus. Ceci, car souvent les contenus écrits vont droit au but, ce qui n’est pas toujours le cas dans une vidéo ou un podcast, ce format permet donc d’être efficace et concis.

Sites web

Blog
- Stéphane Robert : DevOps
- Une tasse de café - Quentin Joly : DevOps
- IT Connect : Admin Sys / IT Global
- Korben : IT Global
- 🇬🇧 It’s foss : Linux
Agrégateur RSS
- Journal du hacker : IT Global
- 🇬🇧 Hacker News : IT Global

Chaînes YouTube

Xavki : DevOps
Yves Rougy : Linux
Underscore : IT Global / Cybersécurité
Devoxx : DevOps / Linux
🇬🇧 NetworkChuck : Cybersécurité

Communauté

Les flux communautaires présents ci-dessous sont principalement une communauté anglo-saxonne, il faut donc pouvoir maîtriser la langue de Shakespeare afin de ne pas passer à côté de toutes ces informations !

Medium

Conclusion

Pour conclure, je trouve que la veille me permet d’apprendre quelque chose chaque jour dans un domaine de l’IT, ceci est en quelque sorte un processus d’amélioration continue à échelle humaine et me permet de ne pas stagner, mais d’évoluer dans mes compétences.

Personnellement, j’apprécie également mettre en pratique mes différentes découvertes au travers d’un POC dans mon homelab afin de me faire rapidement un avis sur le sujet.

Création d'un wiki personnel

Sun, 06 Oct 2024 22:56:48 +0000

Introduction

Avec le nombre d’informations qui arrivent vers moi chaque jour dans de nombreux domaines, des pages de notes manuscrites éparpillées un peu partout et jamais réutilisées, et toujours le souci de régler un problème pour la énième fois sans se souvenir de la solution comme toutes les fois précédentes. 😆

Il me manquait donc un outil pour me servir de second cerveau 🧠 afin d’avoir toutes ces pages de notes ou ces erreurs déjà résolues rassemblées au même endroit.

L’expression du besoin était de ce fait présente, avec des conditions obligatoires qui se sont dessinées au fil des différents tests :

Rapidité d’accessibilité
Rédaction des pages en Markdown
Outil léger
Hébergement local

Qu’est-ce que MkDocs ?

MkDocs est un générateur de site statique rapide et simple, destiné à la création de documentation. Les fichiers de la documentation sont écrits en Markdown et configurés à l’aide d’un seul fichier de configuration YAML.

Cette définition présente sur le site de MkDocs m’a directement inspiré une fois que je suis tombé dessus, car ceci répondait à mes 4 besoins exprimés ci-dessus, et j’ai donc décidé de me lancer dans le test de cet outil.

Site Mkdocs

La première version de mon wiki utilisait cet outil. J’ai utilisé un Dockerfile afin de pouvoir conteneuriser l’outil et de pouvoir l’utiliser en local sans besoin d’installer le paquet python mkdocs.

Le seul bémol de cet outil est que l’interface utilisateur pique un peu les yeux. C’est ceci qui m’a motivé à trouver un thème !

Material

Material est un framework qui s’utilise par-dessus MkDocs et va ainsi permettre de générer un site statique personnalisable via une multitude d’options, mais également la possibilité d’ajouter des plugins.

Ceci va permettre d’avoir un rendu très propre tout en minimisant la partie configuration, car bon nombre de fonctionnalités sont déjà intégrées dans le framework et une simple ligne dans le fichier de configuration permet de les ajouter.

Exemple MkDocs avec Material

Mise en place du wiki

Pour mettre en place cet outil, la documentation de Material explique le déploiement via l’utilitaire mkdocs ou via conteneur docker. Pour ma part, je suis parti sur l’option docker afin de pouvoir utiliser ce conteneur dans mes différents environnements sans besoin d’avoir l’utilitaire présent sur toutes mes machines.

Pour commencer, il faut initialiser le projet dans le but de créer le squelette de notre wiki. Pour ceci, on passe la commande new . au conteneur docker possédant déjà l’utilitaire mkdocs en entrypoint.

1

docker run --rm -it -v ${PWD}:/docs squidfunk/mkdocs-material new .

Une fois le projet initialisé, on se retrouve avec l’arborescence suivante :

1
2
3
4


.
├─ docs/
│ └─ index.md
└─ mkdocs.yml

docs : Représente l’arborescence de notre wiki
mkdocs.yaml : Fichier de configuration du wiki

Configuration

Pour la configuration du wiki, celle-ci s’effectue via le fichier mkdocs.yaml à la racine du projet. On va pouvoir y configurer le thème ainsi que les features que l’on souhaite, listées dans la documentation de configuration de Material. Mais également les extensions Python que l’on souhaite utiliser.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


# Configuration du site
site_name: My site
site_url: https://mydomain.org/mysite

# Configuration du thème material
theme:
 name: material
 icon:
 repo: fontawesome/brands/gitlab
 logo: assets/logo.png
 # Ajout de features
 features:
 - content.code.copy
 - navigation.instant
 - navigation.tabs
 - navigation.tabs.sticky
 - navigation.sections
 - navigation.path
 - navigation.top
 # Automatic light & dark mode
 palette:
 # Palette toggle for automatic mode
 - media: "(prefers-color-scheme)"
 toggle:
 icon: material/brightness-auto
 name: Switch to light mode

 # Palette toggle for light mode
 - media: "(prefers-color-scheme: light)"
 scheme: default
 toggle:
 icon: material/brightness-7
 name: Switch to dark mode

 # Palette toggle for dark mode
 - media: "(prefers-color-scheme: dark)"
 scheme: slate
 toggle:
 icon: material/brightness-4
 name: Switch to system preference
# Déclaration des plugins du thème material
plugins:
 - search

# Extension python pour le markdown
markdown_extensions:
 - pymdownx.superfences:
 custom_fences:
 - name: mermaid
 class: mermaid
 format: !!python/name:pymdownx.superfences.fence_code_format
 - admonition
 - pymdownx.details
 - pymdownx.superfences
 - attr_list
 - pymdownx.emoji:
 emoji_index: !!python/name:material.extensions.emoji.twemoji
 emoji_generator: !!python/name:material.extensions.emoji.to_svg

Dans mon cas, j’ai ajouté différentes features permettant par exemple de copier les blocs de code, d’avoir des onglets par nom de sections ou bien le choix entre light & dark mode. J’ai ajouté le plugin search afin d’avoir une barre de recherche dans mon wiki.

J’ai ajouté des extensions Python permettant de mettre des émojis, des schémas mermaid ou bien d’ajouter des classes HTML/CSS à mes blocs de markdown.

Ajout de contenu

Pour ce qui va être du contenu, il se situera sous le répertoire docs/, chaque dossier représentera une section et chaque fichier représentera une page.

Il est possible de créer une architecture très modulable en ayant N sections avec N sous-sections et N fichiers par sous-section. Ou bien créer uniquement des fichiers. Le fonctionnement laisse un libre recours à l’imagination.

Le nom de dossier représentera le nom de la section / sous-section et pour les pages, le titre sera le nom du fichier ou le header (# Titre1) en markdown s’il y en a un.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


docs/
├── assets
│ └── logo.png
├── Plantes
│ ├── ficus.jpg
│ └── Ficus.md
└── Tech
 ├── Git
 │ └── config.md
 └── Golang
 └── issues.md

Déploiement

Pour la partie déploiement, je lance ce projet en local dans un conteneur docker via le fichier docker-compose.yml, car je n’ai pas d’intérêt à l’héberger sur le web actuellement.

1
2
3
4
5
6
7
8
9


services:
 mkdocs-material:
 restart: "always"
 ports:
 - "8000:8000"
 container_name: "wiki"
 volumes:
 - "/path/to/wiki:/docs"
 image: "squidfunk/mkdocs-material"

Conclusion

Je pense que l’ajout de ce wiki dans ma boîte à outils va me servir de plus en plus avec le temps. Toutes les connaissances acquises vont être regroupées au même endroit et triées par domaine. Ceci va me permettre une facilité et rapidité d’accès à l’information, augmentant donc ma productivité et amenant par la même occasion une réduction de ma perte de temps.

Golang CLI

Wed, 10 Apr 2024 22:56:48 +0000

Ce projet a été réalisé dans le cadre de ma première année de Master à Sup De Vinci lors d’un module sur le langage Golang.

Introduction

Le cahier des charges fourni par l’intervenant faisait la demande de réaliser une CLI en Golang pour une des solutions d’authentification imposées parmi les trois suivantes :

Une documentation devait être fournie afin d’avoir un projet clé en main utilisable par n’importe qui.

Choix des solutions

Backend

Après avoir comparé les 3 solutions d’authentification, j’ai remarqué qu’Authentik et Casdoor sont très complets, de ce fait, il faut un certain temps pour les prendre en main. Mais au vu de la deadline du projet ainsi que ses besoins, je suis parti sur l’outil PocketBase. C’est un outil simple à déployer et à utiliser, il remplit pile les besoins requis pour le projet.

PocketBase UI

Framework Golang

Pour le framework Go, j’ai vu qu’il existait 2 frameworks qui font l’unanimité dans ce domaine : Cobra 🐍 et Kong 🦍.

En suivant des tutoriels sur YouTube qui utilisaient le framework Cobra, la simplicité d’utilisation m’a permis de rapidement mettre en place un POC de ma CLI avec une gestion des flags très intuitive et une documentation automatisée. J’ai donc continué sur ce framework. Il y a énormément de projets qui utilisent Cobra comme on peut le voir dans cette liste.

J’ai aussi ajouté le package Viper dans le projet qui va permettre la gestion de la configuration dans le projet Golang dans le but de manipuler le fichier conf.json.

Et pour finir, l’ajout du package promptUI va permettre d’améliorer l’UX grâce notamment aux prompts interactifs.

Architecture

CLI

Au niveau de l’architecture de la CLI, j’ai choisi de me baser sur celle de Docker que je trouve personnellement très intuitive et pratique à utiliser, et qui est également réalisée via Cobra. Je suis donc parti sur le même modèle command [ressource] [action] [flags].

Architecture de la CLI

La CLI va donc pouvoir permettre de se connecter et déconnecter de PocketBase et aussi de réaliser les actions de CRUD (Create, Read, Update, Delete) sur les utilisateurs présents dans le backend. Ce qui répond donc à la demande exprimée dans le cahier des charges.

Une fois l’architecture de ma CLI schématisée, ceci marque la fin de la phase de conception et je peux donc me lancer dans la phase de programmation de cette CLI afin de passer dans le concret.

Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


├── cmd
│ ├── auth
│ │ ├── login.go
│ │ └── logout.go
│ ├── root.go
│ ├── user
│ │ ├── create.go
│ │ ├── delete.go
│ │ ├── inspect.go
│ │ ├── update.go
│ │ └── user.go
│ └── version
│ └── version.go
├── common
│ └── common.go
├── go.mod
├── go.sum
├── go-cli
└── main.go

main.go : Permet d’initialiser le programme grâce à la fonction main(), qui va être le point d’entrée de notre programme.
cmd/ : Ce dossier regroupe l’ensemble des commandes disponibles dans la CLI. Les fichiers sont organisés en fonction de l’architecture de la CLI.
common/ : Module qui regroupe les fonctions qui sont utilisées dans plusieurs modules du projet.

Déploiement

Pour le déploiement du projet, celui-ci se résume à un simple fichier docker-compose.yaml afin de créer le conteneur PocketBase qui contient la base de données SQLite. On monte également le fichier pb_data afin d’avoir une base de données déjà fournie au niveau des utilisateurs.

1
2
3
4
5
6
7
8


services:
 pocketbase:
 build: .
 container_name: pocketbase
 ports:
 - 8090:8080
 volumes:
 - ./pb_data:/pb/pb_data

La CLI fonctionne quant à elle via un binaire récupérable depuis les releases GitLab ou bien en compilant le code directement en local.

Démonstration

Conclusion

Ce projet a été assez challengeant, car il est intervenu après le module de cours d’une semaine sur le Golang. Il fallait donc encore approfondir ce langage pour bien appréhender ce projet. Ayant fait du C dans un passé pas si lointain que ça ce projet m’a rappelé quelques bons souvenirs. 😄

J’ai également pris de l’expérience sur le fait de choisir les bons outils pour répondre aux attentes du projet, mais également pour gagner du temps sur le développement.

Pour un peu plus de détails sur ce projet, le code est disponible sur le dépôt GitLab go-cli !