Status meines k3s-Homelab (Stand 10/2021)

Status meines k3s-Homelab (Stand 10/2021)
Screenshot Traefik Dashboard

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!

Status meines k3s-Homelab (Stand 02/2021) - teqqy.de
Ich dachte mir, dass ich mal ein paar Worte zu meinem mittlerweile angewachsenen Kubernetes Homelab schreibe. Nicht, dass das irgendwas weltbewegendes wäre, aber sicherlich für den einen oder anderen ein… Weiterlesen

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.

🍻 Sag Danke
Mit kleinen Gesten kannst du meine Arbeit wertschätzen. Was und wie du das tun kannst, erfährst du hier.