Kubernetes Node-Architektur
Alle Nodes sind mit einem 1G Interface angebunden:
- 2x Externe HA Proxy Instanzen mit VIP
- 3x Controlplane Nodes (Control-plane + Etc)
- 3-5x Worker Nodes mit 2 Loadbalancer VIP´s (1x LB für interne Applikationen und 1x LB für externe Applikationen)
- 3x Externe MariaDB Galera Cluster Nodes
API-Access:
Den Zugang zur Kube-API wird durch ein HA Proxy Cluster aus zwei Nodes ermöglicht.
Ingress-Access:
Applikationen werden über den Ingressgateway Controller Traefik im Zusammenspiel mit Metallb erreichbar gemacht. Zudem stehen zwei verschiedene virtuelle Loadbalancer bereit, um internen und externen Traffic unterschieden und besser absichern zu können.
Rancher
Für die Verwaltung meines Kubernetes-Clusters setze ich auf Rancher, eine leistungsstarke Plattform, die mir den Betrieb und das Management meines RKE2-Clusters erheblich erleichtert. Mit Rancher kann ich nicht nur meine bestehenden Workloads effizient verwalten, sondern auch neue Nodes problemlos zum Cluster hinzufügen oder entfernen – ganz ohne komplizierte manuelle Konfigurationen.
Ein weiterer großer Vorteil ist, dass ich mein Cluster dank Rancher stets auf dem neuesten Stand halten kann. Updates auf neue Kubernetes-Versionen lassen sich mit nur wenigen Klicks durchführen, was nicht nur die Sicherheit verbessert, sondern auch den Zugriff auf die neuesten Features ermöglicht. So bleibt mein Homelab flexibel, aktuell und bereit für neue Herausforderungen.
Storage und Persistent Volumes
Ein zentraler Bestandteil meines Homelabs ist das Storage-Management, da viele Anwendungen auf Persistent Volumes (PVs) angewiesen sind, um Daten zuverlässig zu speichern. In meinem Setup nutze ich drei unterschiedliche Storage-Typen, die jeweils für spezifische Anwendungsfälle optimiert sind.
Für den Großteil meiner Workloads setze ich auf Longhorn, ein verteiltes Block-Storage-System, das nahtlos in Kubernetes integriert ist. Longhorn bietet nicht nur hohe Verfügbarkeit und einfache Verwaltung, sondern ermöglicht auch Snapshots und Backups direkt aus der Kubernetes-Umgebung heraus.
Für Backups vertraue ich auf zwei verschiedene Lösungen, um maximale Ausfallsicherheit zu gewährleisten. Zum einen nutze ich den NFS-CSI-Treiber, um Backups auf mein Synology NAS zu schreiben. Diese Lösung ist ideal für lokale Datensicherungen, die schnell verfügbar sein müssen. Zum anderen verwende ich den AzureFile-CSI-Treiber, um zusätzliche Backups in der Azure Cloud abzulegen. Das bietet mir den Vorteil, dass kritische Daten auch außerhalb meines Homelabs sicher gespeichert sind.
Durch diese Kombination aus lokalem und Cloud-basiertem Storage kann ich sicherstellen, dass meine Daten sowohl performant als auch redundant gespeichert werden – ein wichtiger Aspekt für die Stabilität und Ausfallsicherheit meines Clusters.
Applikationsstack
- Ingress Gateway (Reverse Proxy)
- Traefik
- Monitoring
- Prometheus
- Thanos
- Grafana
- Alertmanager
- Blackbox Exporter
- FortiGate Exporter
- Shelly Exporter
- Logging
- Elasticsearch
- Kibana
- Container Registry
- Harbor
- Secret & Zertifikats Management
- Hashicorp Vault
- CertManager
- Storage
- Longhorn
- Minio (S3 Object Storage)
- Anbindung zur Synology NAS
- Anbindung zu SMB Shares in Microsoft Azure
- PostgresDB Operator
- MariaDB Operator
- Nextcloud
- Caching
- Redis
- IAM
- Keycloak
- Netzwerk
- Calico (CNI)
- MetalLB
- PowerDNS
- Unifi Controller (für Ubiquiti/Unifi AccessPoints/Switche)
- Sonstige Applikation
- PTS (Eigenentwicklung)
- 2x WordPress Website Hosting
- Gitlab-runner
- Stirling PDF
- Netbox
