Status meines k3s-Homelab (Stand 10/2021)

Im Februar diesen Jahres habe ich einen ersten Beitrag zu meinem kleinen Kubernetes Homelab geschrieben. Seit dem ist echt viel passiert und vieles hat sich verändert und ist hinzu gekommen. Direkt von Anfang an gilt ein großer dank der k8s-at-home Community!

Hardware

Fangen wir wieder mit der Hardware an. Damals primär nur Raspberry Pis ist es jetzt ein Architekturmix geworden. Als Master laufen drei Raspberry Pi 4 mit 4 GB RAM. Da etcd die SD-Karten zum Frühstück fressen würde, bin ich hier auf 128 GB SSDs gewechselt die mittels eines USB zu SATA Adapters angeschlossen sind.

Als Worker habe ich mir in den letzten Monaten gebrauchte Lenovo Thin Clients gekauft. Zwei davon sind mit 4-Kern Intel i5-6500T, 8 GB RAM, einer 128er SSD für das OS und einer 512 GB NMVe für ceph ausgestattet. Die zwei anderen mit einem Intel i3-6100T, 8 GB RAM und einer 128 GB SSD für das OS.

Software

Diese hat sich kaum geändert. Damals Ubuntu 20.04 LTS, heute Ubuntu 21.04 (non-LTS). Die Raspberry Pis haben natürlich die jeweilige 64bit Variante für ARM installiert bekommen.

Cluster-Ressourcen

CSI – Cluster Storage Interface

Longhorn habe ich den Rücken gekehrt. Für kleine Cluster ziemlich brauchbar. Sobald der aber etwas größer wird, bzw. viele Dateien verändert werden kam die Replikation nicht mehr hinterher. Entsprechend vielen häufiger Volumes aus und mussten aus dem sehr gut funktionierenden Backup wiederhergestellt werden.

Als CSI nutze ich mittlerweile rook-ceph. Ceph als unterliegendes verteiltes Dateisystem und rook als Tool um darauf zugreifen zu können. Einige in der Community verwenden auch einen externen Ceph Cluster, z. B. via Proxmox. Rook-ceph ist schön leichtgewichtig, schnell und zuverlässig!

Derzeit ist der Cluster leider „degraded“, weil meine virtuelle Node auf meinem Proxmox Host fehlt.

rook-ceph Dashboard

CNI – Cluster Network Interface

Als CNI benutze ich das default Netzwerk von k3s: flannel. Allerdings lege ich ein LoadBalancer noch oben drüber.

Damals gar nichts dazu geschrieben. Ich gehe mal davon aus das ich auch zu diesem Zeitpunkt bereits MetalLB verwendet habe. MetalLB stellt mir IP-Adressen zur Verfügung damit externe Geräte auf bestimmte Dienste direkt zugreifen können, ohne Reverse Proxy.

Ingress Controller

Auch hier gab es einen Wechsel. Damals noch ingress-nginx werden heute sämtliche HTTPS Seiten mittels Traefik publiziert. Traefik liefert mit allerdings nicht die Zertifikate, dies wird weiterhin vom cert-manager übernommen. Natürlich via Let’s encrypt.

Traefik Dashboard

Monitoring

Im Bereich Monitoring hat sich am Cluster nichts geändert. Weiterhin wird er kube-prometheus-stack verwendet. Auch wenn der etwas Ressourcenfressend ist, gibt es kaum eine andere Lösung. Prometheus selbst hält die Daten allerdings nur noch sechs Stunden vor. Anschließend werden sie in Thanos bereit gestellt. Grafana greift entsprechend direkt auf Thanos als auf Prometheus zu.

Screenshot aus Grafana; Daten via Node-Exporter und Prometheus

Benachrichtigt werde ich via Alert Manager in einem separaten Discord-Server. Dieser schickt mittels Webhook entsprechende Informationen über Fehler und deren Behebungsstatus.

Was läuft hier?

Eigentlich alles was ich im Homelab immer so laufen hatte. NAS und Firewall sind weiterhin separiert. Alles andere läuft als Container im Cluster. Ein paar Beispiele

Deployment

Im Februar wollte ich noch nichts zum Deployment der Anwendungen und Container schreiben. Mittlerweile finde ich das Thema sehr interessant und wollte es ganz kurz vorstellen.

Ich verfolge mit dem k3s-homelab einen GitOps Ansatz. Heißt meine komplette Konfiguration aller Container und Dienste befindet sich in einem GitHub Repository. Allerdings nicht als einzelne Kind-Defintionen sondern als Helm Datei. Sobald ich ein neuen commit im Main-Branch mache wird dies durch FluxCD von meinem Cluster gepullt und die Änderungen übernommen.

Ein Webhook benachrichtigt mich dann via Discord über entsprechende Änderungen oder Fehler.

Webhook Mitteilungen von FluxCD zu Discord

Bei Fragen und Anregungen versuche ich dir natürlich gern zu helfen.

Traefik TroubLeshooting Guide

Traefik Architecture

In allen meiner Tutorials verwende ich Traefik als Reverse Proxy für Docker Container, so natürlich auch auf meinem YouTube Kanal. Im Laufe der Zeit fragen immer wieder Leser und Zuschauer ob ich ihnen bei ihrem Problem helfen kann. Dies mache ich natürlich gerne. Für ein gewisse Selbsthilfe möchte ich dir allerdings diesen Traefik Troubleshooting Guide an die Hand geben.

Vorbereitende Maßnahmen

Um mit einem guten Troubeshooting zu beginnen möchte ich zwei Maßnahmen vorweg greifen. Diese helfen dir ein paar Dinge auszuschließen bzw. eventuell schnell selbst auf eine Lösung zu kommen.

Container richtig neu starten

Wenn ihr Änderungen am Container von Traefik oder gar an den Konfigurationsdateien vornimmt, muss Traefik komplett neu gestartet werden. Ein stoppen des jeweiligen ist nicht ausreichend. Bei meinen Compose Dateien verwende also bitte nach dem stoppen noch ein

docker-compose rm

um diesen komplett zu löschen. Anschließend kannst du den Container wieder starten und eine neue Konfiguration ist übernommen.

Erhöhen des Log Levels

Zum Traefik Troubleshooting gehört auf jeden Fall auch das betrachten der Log Dateien. In meiner Vorlage steht das Logging auf einer sehr kleinen Stufe um nicht unnötig Speicherplatz zu benötigen. Wenn du mit Traefik startest empfehle ich dir, dieses auf debug zu stellen.

Hierzu einfach die traefik.toml Datei anpassen:

[log]
  level = "DEBUG"
Traefik Architecture

Fehlerlösungen

Die Webseite wird als nicht sicher angezeigt

Dieser Fehler entsteht zumeist wenn Traefik kein Let’s Encrypt Zertifikat abrufen konnte. Leider kann das mehrere Ursachen haben:

Zu häufiges Abrufen von Zertifikaten

Im Log steht hier meist, dass die Anzahl der Möglichen Erstellversuche von Zertifikaten erreicht ist. LE lässt es nur zu 10 Versuche binnen 24 Stunden auf ein SSL-Zertifikat zu erstellen. Wenn du eine eigene Domain hast, versuche es mit einer anderen Subdomain erneut. Andernfalls hilft nur warten.

Ein anderer Container hört auf Port 80

Let’s Encrypt nutzt bei der ersten Kommunikation zwischen Server und Client auch HTTP (Port 80). Wenn dieser Port also noch durch einen anderen Container geblockt ist kann keine Verbindung aufgebaut werden. Ebenso könnte es sein, dass dein NAT in deinem Router Port 80 noch nicht weiter leitet.

Eine 404-Seite wird angezeigt

Jetzt wird es spannend. Sobald eine 404-Seite angezeigt wird, gibts nämlich ein Problem mit dem Routing zu den Containern. Folgende Dinge kannst du hier prüfen:

  • Wird der korrekte Port weiter geleitet?
  • Stimmen alle Middlewere-Configs überein?

Warum ein Tesla? Der Grund hinter unserer Entscheidung

Als wir vor mehr als drei Jahren ein Auto brauchten, wollten wir eigentlich schon auf ein Plug-In Hybrid Fahrzeug wechseln. Damals stand der Audi A3 e-tron hoch im Kurs. Auf Grund sehr langer Lieferzeiten, mussten wir uns anderes entscheiden. Warum Tesla werden wir sicherlich auch noch häufiger in diesem Blog erläutern.

Ich bin weiterhin ein großer Audi-Fan. Ich mag die Designsprache, die Anmutung des Interieuer und das Fahrverhalten der Autos sehr. Entsprechend war die Begeisterung groß, als Audi ein rein elektrisch betriebenes KfZ vorstellte: Der Audi e-Tron

Weiterlesen

Homelab Monitoring – Wie siehts bei mir aus?

Viele meiner Leser wissen es bereits: Ich nutze sehr gerne ICINGA2 als meine Monitoring Software. Vor vielen Jahren bin ich von Nagios damals zu ICINGA 1 gewechselt und sehr zeitnah zu Version 2. Entsprechend ist klar, dass mein Homelab Monitoring primär von ICINGA2 durchgeführt wird.

Wie sieht für mich Monitoring aus?

Bevor ich dir mein Homelab Monitoring zeige, möchte ich erst mal auf die Frage eingehen, wie das ganze überhaupt für mich aussehen soll, bzw. was für mich der Sinn und Zweck eines Monitoring ist.

Privat als auch im beruflichen Leben weiß ich gern vor meinen Kunden (Partnerin, Kollegen, externe Kunden) ob etwas nicht funktioniert. Realistisch betrachtet gibt es Dinge die man nicht vor anderen wissen kann: zum Beispiel ob das Internet noch funktioniert. 🤷‍♂️

Entsprechend versuche ich viele Dinge zu überwachen und mit sauberen Schwellwerten zu versehen um möglichst frühzeitig ein Problem zu sehen oder gar vor einem Problem eingreifen zu können.

Was monitore ich im Homelab?

Nun kommen wir zur spannenden Frage was ich denn im Homelab überwache. Wie oben bereits geschrieben gibt es für mich kein Grund die Verfügbarkeit der Internetleitung zu überwachen. Es ist immer jemand im Haus der das vor mir erkennen würde. Zudem müsste ich für eine entsprechende Benachrichtigung eine zweite Internetleitung bereit stellen oder ein SMS Gateway anschaffen. Beides für daheim zu großer overhead.

Ansonsten versuche ich alle Infrastrukturdienste zu überwachen, sofern sie durch die jeweilige Software überwachbar sind. Mein DHCP Server ist z. B. in der Unifi USG integriert, hier kann ich den Dienst nicht sauber überwachen, da die Firmware ein geschlossenes System ist.

Anders sieht es z. B. beim Thema Smart Home aus. Hier überwache ich sämtliche Dienste (Home Assistant, zwave to mqtt, zigbee to mqtt, etc) auf deren Ausführung.

Dazu kommen natürlich noch alle anderen Bereitstellungen wie DMS, Netzwerkspeicher und so weiter. Überall werden, sofern es Sinn macht, natürlich auch Metriken wie CPU oder RAM Auslastung mit protokolliert und grafisch dargestellt.

Homelab Monitoring mit ICINGA2

Homelab Monitoring – Die Software

Wie bereits geschrieben nutze ich ICINGA2 als Software. Diese setzt zum Betrieb eine SQL Datenbank voraus. Ich für meinen Teil nutze wo immer es auch geht MariaDB, einfach als persönliche Präferenz.

Alle Metriken bzw. Performancedaten werden in eine InfluxDB Datenbank gespeichert. Die Grafen in ICINGA Web 2 sowohl als auch eigenständige Dashboard werden mittels Grafana realisiert. Dieses greift auf die Influx Datenbank zu und stellt nach meinen Wünschen die Werte grafisch dar.

Homelab Monitoring mit Grafana

In dem Screenshot wird Beispielhaft die Auslastung meines kleinen Kubernetes Clusters dargestellt. Dieser läuft auf diversen Raspberry Pis mit k3s.

WordPress Docker Performance

Das mein Blog mit der Software WordPress läuft, sollte eigentlich klar sein. Die ganze Zeit kämpfte ich mit massiven Performance Problemen die eigentlich nicht am Hostsystem liegen können. Andere Softwareprodukte laufen auf meinem NetCup VPS nämlich schnell und zuverlässig. Die Wordress Docker Performance leider ein wenig.

Im Internet gibt es nicht wirklich viele Informationen zu dem Problem. Meist wird behauptet, dass es am Hostsystem liegen soll. Da ich das bereits ausschließen konnte wurden viele Beiträge obsolet.

Weiterlesen

Neue Möglichkeiten mich zu unterstützen

Dinge die ich ins Internet stelle tue ich freiwillig und ohne irgendein finanzielles Interesse. Schließlich habe ich eine Festanstellung in einem Vollzeitjob.

Nichts desto trotz gibt es einige die sich gerne für meine Arbeit bedanken wollen. Regelmäßig erhalte ich Spenden via PayPal. An alle die gespendet haben, sei noch mal ein herzliches Dankeschön!

Seit kurzem bin ich bei YouTube für die Kanalmitgliedschaften qualifiziert. Dort kannst du für 99 Cent im Monat mich Unterstützen. Hier erhältst du als Gegenleistung Einblicke hinter die Kulissen. Bei einer größeren Menge an Unterstützer werde ich sicherlich auch exklusiven Content produzieren oder weitere Vorteile erstellen.

Heute Abend kam dann zudem noch die Bestätigung von GitHub, dass ich jetzt auch für das GitHub Sponsors Programm freigeschaltet bin. Dies war zwar auch ein aktiver Vorgang von mir, dennoch wird dort nicht immer jeder angenommen. Auch hier kannst du mich für 99 Cent im Monat unterstützen.

Das ist natürlich immer alles freiwillig. Ich werde meine Arbeit für die Community auch weiterhin kostenfrei machen, zumindest solange ich in einer Festanstellung bin. 🙂