Khaled ArsalaneDevOps & Platform Engineer
← Projets

homelab

Comment est construit mon homelab Kubernetes

Dix machines, un cluster Kubernetes (k3s) et une trentaine d’applications self-hosted, gérés comme je gérerais de la production. Tout, de l’installation de l’OS au déploiement de chaque application, est déclaré dans git.

Des applications jusqu’au matériel

Applications & AIOps

Une trentaine d’applications, chacune déployée depuis git et protégée par une authentification unique. L’IA tourne sur du matériel local.

AIOps

GPU à la demande
  1. Requête au LLM
  2. Proxy de réveil dans le cluster
  3. Wake-on-LAN
  4. Ollama répond

Au repos, la station se met en veille d’elle-même : de la puissance GPU pour une consommation au repos quasi nulle.

Synthèse des alertes par LLM
  1. Alertmanager
  2. Le LLM regroupe et résume
  3. chat

Les alertes liées sont regroupées et résumées avant d’arriver sur mon téléphone : un incident, un message.

Premier diagnostic par LLM
  1. Alerte ou sync Argo CD en échec
  2. Logs Loki correspondants
  3. Le LLM rédige un premier diagnostic

Alertes, syncs en échec et applications dégradées arrivent avec une première lecture de ce qui ne va pas, rédigée à partir des logs qui les entourent.

Nouvelles erreurs, chaque nuit
  1. Erreurs Loki du jour
  2. Comparées à celles de la veille
  3. Seuls les nouveaux motifs sont publiés

Les erreurs déjà présentes la veille restent silencieuses ; seuls les nouveaux motifs arrivent dans le chat.

Rapport hebdomadaire sur le bruit des alertes
  1. Une semaine d’historique d’alertes
  2. Le LLM l’analyse
  3. Règles à ajuster ou supprimer

Le modèle lit l’historique des alertes de la semaine dans VictoriaMetrics et propose les règles à ajuster ou à supprimer.

Relecture de PR par LLM

Un modèle local relit les PR de dépendances ouvertes par Renovate et les commente.

Espace de travail pour agents

Un espace de travail pour agents IA dans le cluster, avec son propre accès à Vault.

Applications self-hosted

Données personnelles
  • Immich
  • Nextcloud
  • Paperless-ngx
  • Vaultwarden
Maison
  • Home Assistant
  • Homepage
Médias
  • Servarr
Outils
  • Stirling-PDF
  • IT-Tools
  • draw.io
Développé par moi

Mon operator Kubernetes pour les bots de trading freqtrade : bots, stratégies et backtests sont des ressources personnalisées. Paper trading uniquement.

Livraison & cycle de vie

Chaque couche est déclarée dans git : modifier le cluster, c’est faire un commit.

Déclaré dans git, couche par couche

git
  1. Installation de l’OS
    Fedora CoreOS · Butane / Ignition

    Un OS immuable, installé à partir d’un fichier de configuration.

  2. Configuration des hôtes
    Ansible

    Rôles réseau et stockage, appliqués à chaque machine.

  3. Version de Kubernetes
    System Upgrade Controller

    Des plans de mise à jour : la version est écrite dans un fichier.

  4. Plateforme & applications
    Argo CD · app-of-apps

    Une trentaine d’applications, réparties en projets infrastructure et applications.

  5. Secrets
    Vault

    Seulement des références dans git ; les valeurs sont synchronisées depuis Vault.

Des mises à jour à chaque niveau

OS des nœuds
  1. Nouvelle version de CoreOS
  2. Le nœud se met à jour
  3. Attend son tour : un nœud à la fois
  4. Vidé, redémarré, remis en service
Kubernetes
  1. Version modifiée dans un plan
  2. Commit
  3. Les nœuds se mettent à jour
Applications
  1. Renovate ouvre une PR
  2. Un LLM local la relit
  3. Merge
  4. Argo CD la déploie

Deux pipelines

Applications du cluster
  1. Push
  2. Gitea Actions construit l’image
  3. Argo CD déploie depuis git

Gitea et ses runners CI, amd64 et arm64, tournent dans le cluster lui-même.

Ce site
  1. dev : lint, vérification des types, build
  2. staging : servi par Apache, smoke tests
  3. main : déployé, smoke tests à nouveau

La page que vous lisez est passée par ce pipeline, sur les runners du cluster.

Edge & sécurité

Chaque application a un seul nom. Depuis internet, il passe par Cloudflare et un pare-feu applicatif ; à la maison, le même nom mène directement à une passerelle privée. Aucun port entrant n’est ouvert.

Un nom, deux chemins

<app>.<domain>DNS split-horizon : la réponse dépend de l’endroit d’où vient la question.
Depuis internet
  1. Cloudflare DNS

    Enregistrements publics, créés depuis le manifeste de chaque application. Seules les applications publiques en ont un.

  2. Cloudflare Tunnel

    Sortant uniquement : aucun port ouvert, aucune IP domestique exposée.

  3. BunkerWeb

    Pare-feu applicatif et passerelle publique, avec des règles et des limites de débit par application.

Depuis le réseau domestique
  1. Technitium

    Répond pour la même zone à la maison, avec trois réplicas.

  2. MetalLB

    Donne à la passerelle privée son adresse sur le réseau domestique.

  3. NGINX Gateway Fabric

    La passerelle privée : le trafic de la maison ne sort jamais de la maison.

Les deux chemins arrivent au même endroit

Cluster, réseau en default-deny
  1. Authentik

    Connexion sur les deux chemins : OIDC quand l’application le permet, un proxy sinon. MFA obligatoire.

  2. Application

    Les applications uniquement privées n’ont aucun enregistrement public.

Deux instances d’external-dns écrivent les deux vues à partir des mêmes manifestes : aucun enregistrement DNS n’est modifié à la main.

Autour des chemins

Cilium

Default-deny sur tout le cluster ; chaque application n’ouvre que les flux dont elle a besoin. Depuis le réseau domestique, les nœuds ne répondent qu’au SSH, à l’API Kubernetes et au ping.

WireGuard

Le trafic entre les nœuds est chiffré, même à l’intérieur du réseau domestique.

Vault

Cluster raft de trois nœuds avec auto-unseal. Les secrets sont synchronisés vers les applications, jamais stockés dans git.

cert-manager

Certificats TLS émis et renouvelés automatiquement, wildcards compris.

Pod Security Admission

Chaque namespace a un niveau de sécurité : baseline, privileged seulement là où l’accès à l’hôte est nécessaire.

Argo CD

Le compte admin intégré est désactivé : l’accès passe par le SSO avec MFA.

Matériel, alimentation & données

Dix machines servent le cluster : sept font tourner k3s, trois le soutiennent.

Les machines

Réseau domestique
UPS

Garde le stockage, le control plane et le réseau en marche pendant les coupures. Alerte via SNMP quand il passe sur batterie.

Routeursur onduleur

Aucune redirection de port entrant.

Switchsur onduleur
Cluster k3s
4 nœuds amd64

Fedora CoreOS. Trois forment un control plane hautement disponible ; un est worker.

3 Raspberry Pi arm64

Fedora CoreOS aussi. De la capacité en plus à petit prix ; les charges lourdes tournent ailleurs.

NASsur onduleur

Garde les sauvegardes en dehors du cluster qu’elles protègent.

Station de travail GPU

Sert des LLM locaux. Se met en veille au repos, réveillée à la demande.

Hors site
VPS cloud

Provisionné et protégé par pare-feu en tant que code, relié en WireGuard.

Sauvegarde hors site

Une seconde copie des sauvegardes du NAS, hors de la maison.

Sur l’onduleur : le NAS, 1 nœud du control plane, le routeur et le switch.

Où vont les données

  1. Volumes Longhorn

    Répliqués sur plusieurs nœuds, avec un snapshot toutes les heures.

  2. Dumps de bases de données

    Quotidiens, cohérents au niveau applicatif. Les snapshots etcd sont aussi copiés hors des nœuds.

  3. NAS

    Sauvegardes nocturnes de chaque volume.

  4. Sauvegarde hors site

    Le dernier recours si c’est la maison elle-même qui pose problème.

Les restaurations sont répétées sur une base de test, pas seulement planifiées.

Tout surveiller

Métriques
VictoriaMetrics, Prometheus
Logs
Loki, Promtail
Traces
Tempo
Sondes
Blackbox exporter
Matériel
SNMP
Tableaux de bord
Grafana
Alertes
Alertmanager → chat

SNMP couvre l’onduleur et le NAS : une coupure de courant déclenche une alerte comme n’importe quelle autre panne.