Skip to content

Dimensionnement des VMs

Ce document détaille l'allocation des ressources pour chaque VM du homelab.

Capacité mémoire par nœud

Les trois nœuds ne sont pas symétriques en RAM — pve01 est volontairement moins doté :

Nœud RAM physique Rôle Budget VMs Réserve Proxmox
pve01 16 Go Control Plane 12 Go 4 Go (25 %)
pve02 32 Go Data / Security / Observability 16 Go 16 Go (50 %)
pve03 32 Go Kubernetes Platform 16 Go 16 Go (50 %)
Total 80 Go 44 Go 36 Go (45 %)

La réserve importante sur pve02 et pve03 (50 %) permet d'absorber les pics mémoire sans swap et de provisionner des VMs supplémentaires pour les expérimentations.

pve01 — Control Plane (16 Go RAM)

ID VM vCPU RAM Stockage IP
101 traefik 1 2 Go 20 Go 192.168.1.20
102 gitlab 4 8 Go 200 Go 192.168.1.21
103 vault 1 2 Go 20 Go 192.168.1.22
Alloué 6/16 12 Go 240 Go / 1 To

Justification : GitLab CE avec runners a besoin de 8 Go pour être stable. Traefik et Vault tiennent dans 2 Go chacun. 12 Go alloués sur 16, il reste 4 Go pour Proxmox — suffisant.

Stockage : 200 Go pour GitLab incluent les artefacts de pipeline, le registry container intégré et les logs. 20 Go pour Traefik et Vault sont confortables (OS + logs).

pve02 — Data / Security / Observability (32 Go RAM)

ID VM vCPU RAM Stockage IP
201 harbor 2 4 Go 80 Go 192.168.1.30
202 monitoring 2 4 Go 100 Go 192.168.1.31
203 keycloak 2 4 Go 40 Go 192.168.1.32
204 defectdojo 2 4 Go 50 Go 192.168.1.33
Alloué 8/16 16 Go 270 Go / 1 To

Justification : Avec 32 Go de RAM physique, chaque VM peut avoir 4 Go sans contrainte. Harbor héberge PostgreSQL + Redis, Monitoring cumule Prometheus/Grafana/Loki, Keycloak fait tourner une JVM, DefectDojo empile Django + Celery + PostgreSQL + Redis. 4 Go par VM est le minimum confortable pour l'ensemble.

Stockage : Harbor 80 Go (quelques images Python suffisent), Monitoring 100 Go (métriques 30 jours + logs 2 jours), Keycloak 40 Go (base utilisateurs légère), DefectDojo 50 Go (rapports SAST/DAST).

pve03 — Kubernetes Platform (32 Go RAM)

ID VM vCPU RAM Stockage IP
301 k3s-master 2 4 Go 40 Go 192.168.1.40
302 k3s-worker01 3 6 Go 100 Go 192.168.1.41
303 k3s-worker02 3 6 Go 100 Go 192.168.1.42
Alloué 8/16 16 Go 240 Go / 1 To

Justification : Le master k3s avec SQLite tient dans 4 Go (le surdimensionnement volontaire permet d'ajouter etcd si besoin d'évoluer). Les workers à 6 Go absorbent les builds Docker du GitLab Runner (worker01) et les applications Python avec leurs dépendances (worker02).

Stockage : 100 Go par worker pour images Docker, caches de build et données applicatives. Le master n'a besoin que de ses manifests et logs (40 Go).

Ratios d'overcommit

Ressource Ratio Calcul
vCPU ~1:1 22 vCPU alloués pour 48 threads physiques. Aucune contention.
RAM 1:1 Pas d'overcommit. La réserve de 36 Go est là pour les pics.
Stockage — Thin provisioning (allocation croissante). L'espace réel consommé sera très inférieur au provisionné.

Swap

Désactivé sur toutes les VMs. Une VM en swap devient inutilisable (I/O bloquée sur le SSD). Le OOM killer est préférable — il tue le processus problématique, et Prometheus + alerting prévient l'administrateur.

Provisionnement

Les VMs sont créées par OpenTofu (provider telmate/proxmox) avec : - Stockage en thin provisioning (fichier .qcow2) - Configuration réseau et clé SSH injectées via cloud-init - Template Debian 13 préconfiguré (créé une fois via Packer ou manuellement)