TMTom MendyEnglish
Retour aux projets

Étude de cas · Homelab Kubernetes

Un petit cluster pour apprendre les vrais problèmes d’exploitation.

Trois nœuds, un control plane, deux workers et assez de services pour rencontrer les problèmes que les tutoriels évitent souvent. Ce dépôt documente les choix, les incidents et les limites du système.

Explorer le dépôt
3nœuds Kubernetes
GitOpsavec Flux et Helm
NFSstockage partagé
CIcontrôles hors cluster

01 / 04

Architecture actuelle

Flux réconcilie les manifests depuis le Forgejo du cluster. Les charts locaux décrivent les services propres au projet. Infisical injecte les secrets à l’exécution, tandis que le NAS Synology fournit le stockage persistant partagé.

02 / 04

Décisions qui ont compté

01

Git reprend la main

Les changements passent par Git et Flux. Cette règle évite qu’une modification manuelle d’image ou de manifeste entre en conflit avec l’état déclaré.

02

Le stockage quitte les workers

Les volumes persistants locaux dépendaient d’un seul nœud. Les charges concernées utilisent maintenant des PVC NFS sur le NAS.

03

Les secrets restent hors du dépôt

Infisical fournit les identifiants à l’exécution. Les contrôles CI recherchent aussi les secrets ajoutés par erreur.

04

La CI vérifie sans cluster

Les scripts rendent les charts, vérifient les schémas Kubernetes et appliquent une politique de stockage avant qu’un changement atteigne le cluster.

03 / 04

Chemin d’un changement

  1. 01

    Commit

    Une modification de chart ou de configuration entre dans Git.

  2. 02

    Vérifier

    Gitleaks, rendu Helm, kubeconform et règles de stockage contrôlent le changement.

  3. 03

    Réconcilier

    Flux lit la source Git et applique l’état déclaré.

  4. 04

    Observer

    Prometheus, Grafana et Loki donnent les signaux nécessaires après le déploiement.

04 / 04

Ce que le système ne prétend pas être

Ce homelab n’est pas une distribution Kubernetes prête pour la production. Le control plane reste unique, le NAS est une dépendance centrale, certains services n’ont qu’un réplica et plusieurs charges dépendent du matériel disponible. Ces risques sont acceptés et documentés, pas masqués.

Le dépôt contient les manifests, les contrôles et les runbooks.

L’architecture publique et les procédures de reprise permettent de discuter des choix sur des preuves concrètes.

Voir le code et la documentation