Nach vielen technischen Details in den vorherigen Blogposts möchte ich diesen Beitrag nutzen, um ein paar konkrete Anwendungen in meinem Kubernetes-Cluster vorzustellen. Dabei setze ich auf FluxCD und Helm Charts, um Deployments reproduzierbar und wartbar zu halten.
Paperless
Paperless-ngx ist eine Anwendung zur Verwaltung digitaler Dokumente. In meinem Setup habe ich es mit mehreren zusätzlichen Komponenten kombiniert:
- PostgreSQL: Die Datenbank wird mit dem cloudnative-pg-Operator verwaltet.
- Redis: Wird direkt mit dem Helm Chart von Paperless mitinstalliert.
- Gotenberg: Zum Konvertieren von Dokumenten in PDFs.
- Tika: Zur Texterkennung und -analyse von Dokumenten.
Das Setup läuft insgesamt stabil, allerdings habe ich festgestellt, dass der Einsatz von LLMs zur automatischen Dokumentenanalyse nicht praktikabel ist (siehe unten).
KitchenOwl
KitchenOwl ist eine Open-Source-Anwendung zur Verwaltung von Rezepten und Einkaufslisten. Auch hier setze ich auf eine PostgreSQL-Datenbank, die über den cloudnative-pg-Operator bereitgestellt wird.
Home Assistant
Für die Heimautomatisierung setze ich inzwischen auf Home Assistant. Der Betrieb in Kubernetes funktioniert stabil, wenn man ein paar Besonderheiten berücksichtigt:
- Netzwerk: Für bestimmte Discovery-Funktionen ist
hostNetwork: truesinnvoll. - Ingress: Der externe Zugriff läuft über Traefik inkl. TLS.
- Storage: Persistente Daten liegen auf Kubernetes-Volumes.
- Backup: Konfigurationsdaten werden regelmäßig über den bestehenden Backup-Workflow gesichert.
Im Vergleich zu meinem früheren Setup mit OpenHab ist der Betrieb dadurch einfacher geworden. Home Assistant benötigt deutlich weniger Resources, ist einfacher einzurichten und deutlich benutzerfreundlicher.
Immich
Für Fotos und Videos nutze ich Immich. Die Anwendung besteht aus mehreren Komponenten (App, Datenbank, Cache, Storage), was in Kubernetes gut abbildbar ist.
Wichtige Punkte aus meinem Setup:
- Persistenz: Die Medienbibliothek liegt auf einem dedizierten Persistent Volume.
- Datenbank: Läuft getrennt und wird unabhängig von der App verwaltet.
- Ingress + TLS: Öffentliche Erreichbarkeit über die gleiche zentrale Ingress- und Zertifikatsstrategie wie die anderen Dienste.
- Betrieb: Updates und Rollbacks lassen sich sauber über Git nachvollziehen.
Gerade bei speicherintensiven Anwendungen zeigt sich der Vorteil eines strukturierten Storage- und Backup-Konzepts.
Mit Machine Learning kann man in Immich Fotos klassifizieren, Gesichter erkennen und Metadaten anreichern. Für Machine Learning ist mein Cluster zu schwach. Da diese Container nicht dauerhaft laufen müssen, starte ich dann entsprechende Container von Zeit zu Zeit auf einem separaten Rechner in meinem Netzwerk.
Dawarich
Dawarich nutze ich zur eigenen Location-History. Die Anwendung bringt ein paar interessante Anforderungen mit, die gut zu einem Kubernetes-Setup passen:
- OIDC: Anmeldung über OpenID Connect.
- Persistente Daten: Uploads und App-Daten liegen auf Persistent Volumes.
- Datenbank: PostgreSQL läuft separat als eigener Baustein.
- Betriebssicherheit: Konfiguration und Secrets sind in den bestehenden GitOps-/Secret-Workflow eingebunden.
Damit ist Dawarich ein gutes Beispiel für eine moderne Webanwendung mit Authentifizierung, Datenhaltung und sauberem Deployment-Prozess.
Was nicht funktioniert hat: Ollama für Paperless
Ich habe versucht, Ollama mit Paperless zu kombinieren, um Dokumente automatisiert zu analysieren und zusammenzufassen. Leider ist die Hardware meines Clusters zu schwach für die Nutzung von LLMs. Selbst einfache Anfragen haben 15 Minuten für eine Antwort benötigt, weshalb ich dieses Experiment abgebrochen habe.
Stattdessen starte ich ähnlich wie bei Immich von Zeit zu Zeit Ollama auf einem separaten Rechner um Dokumente zu erkennen, sinnvolle Titel zu setzen, Tags zu bestimmen und die Korrespondenten zu ermitteln.
Mit diesen Anwendungen habe ich mein Kubernetes-Setup auf ein für mich produktives Niveau gebracht. Falls du Fragen zu einzelnen Deployments hast oder selbst eine ähnliche Umgebung aufbauen möchtest, hinterlasse gerne einen Kommentar!
Zukünftige Pläne
Mein Kubernetes-Setup ist noch nicht abgeschlossen. In nächster Zeit plane ich, weitere Webanwendungen in Kubernetes zu migrieren. Dazu gehören:
- Davical: Eine CalDAV-Server-Software. Bevor ich es deployen kann, muss ich jedoch erst ein passendes Helm Chart erstellen.
- Icinga2: Mein Monitoring-System, das ich bereits für verschiedene Server und Projekte (z. B. Freifunk) nutze. Ich möchte es vollständig in Kubernetes überführen.
- Telegraf: Zur Erfassung von Systemmetriken und deren Weiterleitung an mein Monitoring-Setup.
Ich werde weiter darüber berichten, sobald ich Fortschritte mache!
Changelog
Letzte Aktualisierung: April 2026
- OpenHAB-Abschnitt entfernt.
- Anwendungen aktualisiert: Home Assistant, Immich und Dawarich ergänzt.
- Einleitung und Praxisbeispiele auf den aktuellen Betriebsstand angepasst.
Weitere Blogposts aus der k3s-Reihe
- Einführung in meinen Kubernetes-Heimcluster: Warum und Wie?
- Der Aufbau meines Kubernetes-Heimclusters: Die Wahl der Hardware
- Initialisierung meines Heim-Kubernetes-Clusters: k3s mit Ansible
- GitOps mit FluxCD für meinen Heim-Kubernetes-Cluster
- Sichere Verwaltung von Kubernetes Secrets mit Sealed Secrets
- Automatisierte DNS- und SSL-Zertifikatsverwaltung in Kubernetes
- Ingress und Load Balancer in Kubernetes: Traefik und MetalLB
- Storage, Backup und Restore in meinem Kubernetes-Cluster
- Authentifizierung und Autorisierung in k3s
- K3s: Automatisierte Updates mit Renovate
- Wenn automatische Updates fehlschlagen
