Khaled ArsalaneDevOps & Platform Engineer
← Progetti

homelab

Come è costruito il mio homelab Kubernetes

Dieci macchine, un cluster Kubernetes (k3s) e una trentina di app self-hosted, gestiti come gestirei la produzione. Tutto, dall’installazione del sistema operativo al deployment di ogni app, è dichiarato in git.

Dalle app fino all’hardware

App & AIOps

Una trentina di app, ognuna distribuita da git e protetta da single sign-on. L’IA gira su hardware locale.

AIOps

GPU su richiesta
  1. Richiesta all’LLM
  2. Wake proxy nel cluster
  3. Wake-on-LAN
  4. Risponde Ollama

Quando è inattiva, la workstation si sospende da sola: potenza GPU con consumi a riposo quasi nulli.

Digest degli alert con LLM
  1. Alertmanager
  2. L’LLM raggruppa e riassume
  3. chat

Gli alert correlati vengono raggruppati e riassunti prima di arrivare sul telefono: un incidente, un messaggio.

Primo triage con LLM
  1. Alert o sync Argo CD fallito
  2. Log Loki corrispondenti
  3. L’LLM scrive un primo triage

Alert, sync falliti e app degradate arrivano con una prima lettura di cosa non va, scritta a partire dai log intorno.

Nuovi errori, ogni notte
  1. Errori Loki di oggi
  2. Confrontati con quelli di ieri
  3. Pubblicati solo i nuovi pattern

Gli errori già presenti ieri restano in silenzio; in chat arrivano solo i pattern nuovi.

Report settimanale sul rumore degli alert
  1. Una settimana di storico degli alert
  2. L’LLM lo analizza
  3. Regole da affinare o eliminare

Il modello legge lo storico settimanale degli alert da VictoriaMetrics e suggerisce quali regole affinare o eliminare.

Revisione delle PR con LLM

Un modello locale revisiona le PR di dipendenze aperte da Renovate e le commenta.

Workspace per agenti

Un workspace per agenti IA che gira nel cluster, con il proprio accesso a Vault.

App self-hosted

Dati personali
  • Immich
  • Nextcloud
  • Paperless-ngx
  • Vaultwarden
Casa
  • Home Assistant
  • Homepage
Media
  • Servarr
Strumenti
  • Stirling-PDF
  • IT-Tools
  • draw.io
Sviluppato da me

Il mio operator Kubernetes per i bot di trading freqtrade: bot, strategie e backtest sono risorse personalizzate. Solo paper trading.

Delivery & ciclo di vita

Ogni livello è dichiarato in git: cambiare il cluster significa fare un commit.

Dichiarato in git, livello per livello

git
  1. Installazione OS
    Fedora CoreOS · Butane / Ignition

    Un sistema operativo immutabile, installato da un file di configurazione.

  2. Configurazione host
    Ansible

    Ruoli di rete e storage, applicati a ogni macchina.

  3. Versione di Kubernetes
    System Upgrade Controller

    Piani di aggiornamento: la versione sta in un file.

  4. Piattaforma & app
    Argo CD · app-of-apps

    Una trentina di app, divise in progetti di infrastruttura e di applicazioni.

  5. Segreti
    Vault

    In git solo riferimenti; i valori sono sincronizzati da Vault.

Aggiornamenti a ogni livello

OS dei nodi
  1. Nuova release di CoreOS
  2. Il nodo si aggiorna da solo
  3. Aspetta il suo turno: un nodo alla volta
  4. Svuotato, riavviato, di nuovo in servizio
Kubernetes
  1. Versione aggiornata in un piano
  2. Commit
  3. I nodi si aggiornano da soli
App
  1. Renovate apre una PR
  2. Un LLM locale la revisiona
  3. Merge
  4. Argo CD la distribuisce

Due pipeline

App nel cluster
  1. Push
  2. Gitea Actions builda l’immagine
  3. Argo CD fa il deploy da git

Gitea e i suoi runner CI, amd64 e arm64, girano nel cluster stesso.

Questo sito
  1. dev: lint, type-check, build
  2. staging: servito da Apache, smoke test
  3. main: deploy, di nuovo smoke test

La pagina che stai leggendo è passata da qui, sui runner del cluster.

Edge & sicurezza

Ogni app ha un solo nome. Da internet passa per Cloudflare e un web application firewall; da casa, lo stesso nome porta direttamente a un gateway privato. Nessuna porta in ingresso è aperta.

Un nome, due percorsi

<app>.<domain>DNS split-horizon: la risposta dipende da dove arriva la domanda.
Da internet
  1. Cloudflare DNS

    Record pubblici, creati dal manifest di ogni app. Solo le app pubbliche ne hanno uno.

  2. Cloudflare Tunnel

    Solo in uscita: nessuna porta aperta e nessun IP di casa esposto.

  3. BunkerWeb

    Web application firewall e gateway pubblico, con regole e rate limit per app.

Dalla rete di casa
  1. Technitium

    Risponde per la stessa zona in casa, con tre repliche.

  2. MetalLB

    Assegna al gateway privato il suo indirizzo sulla rete di casa.

  3. NGINX Gateway Fabric

    Il gateway privato: il traffico di casa non esce mai di casa.

Entrambi i percorsi arrivano nello stesso punto

Cluster, rete default-deny
  1. Authentik

    Accesso su entrambi i percorsi: OIDC dove l’app lo supporta, un proxy dove no. MFA obbligatoria.

  2. App

    Le app solo private non hanno alcun record pubblico.

Due istanze di external-dns scrivono entrambe le viste dagli stessi manifest: nessun record DNS viene modificato a mano.

Intorno ai percorsi

Cilium

Default-deny su tutto il cluster; ogni app apre solo i flussi di cui ha bisogno. Dalla rete di casa, i nodi rispondono solo a SSH, all’API di Kubernetes e al ping.

WireGuard

Il traffico tra i nodi è cifrato, anche all’interno della rete di casa.

Vault

Cluster raft a tre nodi con auto-unseal. I segreti vengono sincronizzati nelle app, mai salvati in git.

cert-manager

Certificati TLS emessi e rinnovati automaticamente, wildcard incluse.

Pod Security Admission

Ogni namespace ha un livello di sicurezza: baseline, privileged solo dove serve l’accesso all’host.

Argo CD

L’account admin integrato è disattivato: l’accesso passa dall’SSO con MFA.

Hardware, alimentazione & dati

Dieci macchine servono il cluster: sette eseguono k3s, tre lo supportano.

Le macchine

Rete di casa
UPS

Mantiene attivi storage, control plane e rete durante i blackout. Avvisa via SNMP quando passa a batteria.

Routersu UPS

Nessun port forwarding in ingresso.

Switchsu UPS
Cluster k3s
4 nodi amd64

Fedora CoreOS. Tre formano un control plane ad alta disponibilità; uno è un worker.

3 Raspberry Pi arm64

Anche loro su Fedora CoreOS. Capacità extra a basso costo; i carichi pesanti girano altrove.

NASsu UPS

Conserva i backup fuori dal cluster che proteggono.

Workstation GPU

Serve LLM locali. Va in sospensione quando è inattiva e si risveglia su richiesta.

Off-site
VPS cloud

Provisioning e firewall come codice, collegato via WireGuard.

Backup off-site

Una seconda copia dei backup del NAS, fuori casa.

Sull’UPS: il NAS, 1 nodo del control plane, il router e lo switch.

Dove vanno i dati

  1. Volumi Longhorn

    Replicati su più nodi, con uno snapshot ogni ora.

  2. Dump dei database

    Giornalieri, coerenti a livello applicativo. Anche gli snapshot di etcd vengono copiati fuori dai nodi.

  3. NAS

    Backup notturni di ogni volume.

  4. Backup off-site

    L’ultima linea di difesa se il problema è la casa stessa.

I ripristini vengono provati su un database di prova, non solo pianificati.

Tenere tutto sotto controllo

Metriche
VictoriaMetrics, Prometheus
Log
Loki, Promtail
Tracce
Tempo
Probe
Blackbox exporter
Hardware
SNMP
Dashboard
Grafana
Alert
Alertmanager → chat

SNMP copre l’UPS e il NAS: un blackout fa scattare un allarme come qualsiasi altro guasto.