Projet Infrastructure

Cluster K3S automatisé

Un cluster Kubernetes K3S sur machine virtuelle Libvirt où déposer un fichier YAML suffit à publier une application en HTTPS sur son propre sous-domaine — conteneurs, proxy et certificat compris.

Conception, réalisation et documentation Août 2026 13 août 2026 14 vues
Cluster Kubernetes K3S mono-nœud, hébergé sur une machine virtuelle Libvirt/KVM, dont la vocation est de rendre la publication d'une application aussi simple que la copie d'un fichier. Déposer une déclaration YAML de quelques lignes dans un répertoire surveillé suffit : conteneurs, service, volume persistant, reverse-proxy et certificat TLS sont créés automatiquement, et l'application répond en HTTPS sur https://<nom>.k3s.ev1.fr. De l'installation du système d'exploitation jusqu'à la mise en ligne, aucune étape manuelle ne subsiste.

Publier une application en une seule action

Copier un fichier de configuration dans /srv/k3s-apps/enabled/ doit suffire à créer et exposer l'application. Aucune commande kubectl, aucun manifeste Kubernetes à écrire à la main.

Une URL prévisible, sans intervention DNS

Le nom du fichier de configuration détermine l'URL : wiki-guillaume devient https://wiki-guillaume.k3s.ev1.fr. Un enregistrement DNS wildcard couvre toutes les applications présentes et à venir.

HTTPS systématique, sans démarche par application

Un certificat wildcard auto-signé, émis par une autorité locale, sert toutes les applications. Le HTTP est redirigé en 301 vers HTTPS ; aucune application ne peut être publiée en clair.

Reproductibilité intégrale

L'ensemble — création de la VM, installation d'Ubuntu, provisionnement de K3S, PKI, moteur de déploiement — est rejouable par trois scripts idempotents et documenté en dix chapitres.

Contexte & Problématique

Le besoin initial est celui d'un laboratoire personnel devenu sérieux : héberger plusieurs services web (wiki, supervision, outils internes) sur une seule machine, sans y consacrer un temps d'exploitation disproportionné, et sans reproduire à chaque fois les mêmes étapes fastidieuses de création de conteneur, de proxy et de certificat.

Répétitivité des mises en ligne

Chaque nouveau service imposait le même rituel : écrire un docker-compose, configurer un reverse-proxy, générer un certificat, ouvrir un sous-domaine. Un travail identique à 90 %, refait à chaque fois, et source d'oublis.

Le TLS, point de friction permanent

Sur un réseau interne sans exposition Internet, obtenir un certificat par application est laborieux. La réponse retenue : une autorité de certification locale et un unique certificat wildcard, valables dix ans.

Une ressource matérielle unique

Un seul hôte physique sous Libvirt/KVM, déjà occupé par d'autres machines virtuelles. La plateforme devait tenir dans 4 vCPU, 6 Gio de RAM et 40 Gio de disque, tout en restant extensible à plusieurs nœuds.

Transmissibilité

Une infrastructure que l'on est seul à savoir exploiter est une dette. La documentation et une fiche opératoire faisaient donc partie du livrable, au même titre que le code.

Réalisation

Le projet se déroule en six étapes, entièrement scriptées. L'ensemble part d'une ISO Ubuntu Server et aboutit à une plateforme en production, sans jamais toucher un écran d'installation.
  1. 1. Installation autonome d'Ubuntu Server

    Une ISO « seed » au format cloud-init NoCloud (label CIDATA) est générée avec xorriso puis présentée à l'installateur en second CD-ROM. Associée à l'argument noyau autoinstall, elle supprime toute question : partitionnement, compte sudoer evadmin1, IP statique 192.168.122.50, paquets et clé SSH sont appliqués sans intervention.

  2. 2. Contournement d'un bug noyau de l'ISO

    La source d'installation par défaut empile plusieurs images squashfs via overlayfs, ce qui déclenche un oops noyau (ovl_iterate_merged) : rsync se fige en état D et l'installation ne progresse plus. Le diagnostic, mené par capture d'écran de la console et analyse des processus bloqués, a conduit à forcer la source ubuntu-server-minimal, à image unique — installation fiable et empreinte réduite.

  3. 3. Déploiement de K3S

    K3S est installé en serveur mono-nœud avec Traefik comme contrôleur d'entrée, local-path pour les volumes persistants et les SAN nécessaires au pilotage distant de l'API. Traefik est configuré de façon durable via les manifestes auto-appliqués de K3S : redirection HTTP vers HTTPS et certificat par défaut.

  4. 4. Chaîne de confiance interne

    Une autorité de certification locale est générée, puis signe un certificat wildcard *.k3s.ev1.fr (SAN incluant le domaine nu et l'adresse IP). Il est publié comme certificat par défaut de Traefik et recopié dans chaque espace de noms applicatif. L'import unique de l'autorité sur un poste rend valides tous les sous-domaines, présents et futurs.

  5. 5. Moteur de déploiement automatique

    Un service Python surveille /srv/k3s-apps/enabled/ via une unité systemd .path, doublée d'un timer de réconciliation. À chaque dépôt il traduit la déclaration en manifestes Kubernetes complets — Namespace, Secret TLS, PersistentVolumeClaim, Deployment, Service, Ingress — les applique, et supprime les applications dont le fichier a disparu.

  6. 6. Recette et documentation

    Un script de recette valide la chaîne complète : dépôt du fichier, attente de disponibilité, réponse HTTPS, certificat présenté, redirection 301, puis suppression et nettoyage. La documentation est livrée en dix chapitres Markdown, un PDF de 33 pages et une fiche opératoire destinée à l'exploitation.

Stack technique

Virtualisation

Libvirt QEMU/KVM virt-install cloud-init (NoCloud) xorriso qcow2

Système

Ubuntu Server 26.04 LTS autoinstall/subiquity netplan systemd (path timer service)

Orchestration

K3S v1.36 containerd Traefik 3 CoreDNS local-path-provisioner Helm (HelmChartConfig)

Sécurité & PKI

OpenSSL (CA locale + wildcard) TLSStore Traefik secrets Kubernetes authentification SSH par clé

Outillage développé

Python 3 (moteur de synchronisation) Bash (CLI k3s-app scripts hôte) YAML déclaratif

Résultats & Impact

La plateforme est en service et validée de bout en bout : une application Wiki.js a été déployée par simple copie de fichier, servie en HTTPS avec le certificat wildcard, et remise en ligne automatiquement après redémarrage complet de la machine virtuelle.
1
fichier à copier pour publier une application
~50 s
entre la copie du fichier et l'URL en ligne
0
enregistrement DNS ou certificat par application
10
chapitres de documentation (PDF de 33 pages)

Installation sans interaction

De l'ISO à un système joignable en SSH avec IP fixe et compte d'administration : aucune saisie, un seul script.

Publication réellement automatique

Copie du template Wiki.js sous le nom wiki-guillaume, puis réponse HTTP 200 sur https://wiki-guillaume.k3s.ev1.fr, certificat validé par l'autorité locale, redirection 301 depuis HTTP — vérifiés.

Cycle de vie complet

Modifier le fichier met l'application à jour, le supprimer retire toutes les ressources associées ; une réconciliation périodique corrige toute dérive.

Résilience vérifiée

Après redémarrage complet de la machine virtuelle, le cluster et les applications déclarées remontent seuls en une minute environ.

Retour au portfolio