Journal de construction

Homelab Kubernetes

Pourquoi

Une plateforme Kubernetes construite sur bare metal, de l'hyperviseur jusqu'aux workloads — maîtriser chaque couche plutôt que de la déléguer à un service managé.

Chaque couche est d'abord déployée à la main, puis codifiée. L'objectif : comprendre le fonctionnement réel avant de l'automatiser.

01

Stack

déployé en cours planifié
COUCHE 01

Matériel et hyperviseur

Bi-Xeon Silver 4116, 128 Go de RAM, sous Proxmox VE. SSH par clé uniquement, pare-feu deny-by-default, TOTP sur le compte root.

DÉCISION : POURQUOI UN SSD EXTERNE

Proxmox tourne depuis un SSD externe dédié, démarré à la demande. L'installation Windows sur les disques internes reste intacte. Pas de dual boot, pas de partitionnement. Ça veut aussi dire que le lab ne tourne pas en continu : chaque session commence par un boot complet du cluster, ce qui en fait un test de reproductibilité autant qu'un lab.

DÉPLOYÉ
COUCHE 02

Cluster k3s

Trois VM Debian provisionnées depuis la CLI Proxmox avec cloud-init. Un server, deux agents, datastore SQLite.

DÉPLOYÉ
COUCHE 03

Ingress et TLS

Traefik comme ingress controller, cert-manager qui émet et renouvelle les certificats Let's Encrypt via le challenge DNS-01 sur Route 53. Le cluster reste privé, mais chaque service est joignable en HTTPS sur un vrai domaine, avec un utilisateur IAM restreint à une seule hosted zone.

DÉPLOYÉ
COUCHE 04

GitOps

Gitea déployé via Helm comme forge interne, ArgoCD qui surveille un unique dépôt comme source de vérité et réconcilie le cluster avec lui.

DÉPLOYÉ
COUCHE 05

Intégration continue

Gitea Actions activé, un Gitea Runner self-hosted enregistré au niveau de l'organisation. Il tourne en deux conteneurs — le runner et un sidecar docker:dind qui partagent le socket via un volume emptyDir — avec isolation par conteneur pour chaque job.

DÉCISION : TOPOLOGIE DU RUNNER, ET LA SUITE

Le runner s'appuie aujourd'hui sur un sidecar docker:dind privilégié — un compromis assumé et documenté, puisque le pipeline dépend déjà du socket Docker. Le runner pod-per-job serait la réponse cloud-native, mais il n'existe que dans l'édition Enterprise. L'amélioration prévue : passer à un builder daemonless et rootless (Buildah ou Kaniko) — plus de socket Docker, plus de conteneur privilégié.

DÉPLOYÉ
COUCHE 06

Sécurité de la chaîne d'approvisionnement

Hadolint et le scan de vulnérabilités Grype (--fail-on critical) sont intégrés au pipeline CI, avant le build et le push de l'image vers le registry. Restent à venir : la signature d'image (cosign) et le passage à un build rootless (Buildah / Kaniko) pour supprimer la dépendance au socket Docker.

EN COURS
COUCHE 07

Observabilité

kube-prometheus-stack (Prometheus + Grafana) déployé via Helm et réconcilié par ArgoCD, à l'intérieur du cluster.

DÉPLOYÉ
COUCHE 08

Infrastructure as Code

Terraform et Ansible, une fois le flux manuel pleinement maîtrisé.

PLANIFIÉ
02

Architecture

Comment la stack est construite, du disque sur lequel elle démarre jusqu'au cluster au sommet.

Proxmox VE 2 x Xeon Silver 4116, 128 Go RAM, 3 VM Debian, 192.168.1.200 cluster k3s datastore SQLite, sans HA k3s-server-1 .211, 4 vCPU, 8 Go k3s-agent-1 .212, 4 vCPU, 8 Go k3s-agent-2 .213, 4 vCPU, 8 Go SSD externe Racine Proxmox, démarré à la demande SSH par clé, pare-feu deny-by-default, TOTP sur root

Comment un changement atteint le cluster. La CI écrit dans Git et dans le registry, et s'arrête là.

Gitea Manifestes, source de vérité écrit le tag d'image surveille CI Aucun credential du cluster Gitea Runner DinD privilégié (2 conteneurs) Lint, build, scan Hadolint, Grype Livraison Tourne dans le cluster ArgoCD Applique ce que Git déclare Workloads Convergent vers l'état déclaré Registry Intégré à Gitea, puis Harbor pousse récupère
← Retour aux projets