K8s Lern- und Test-Cluster

mit GitOps-basierter Deployment-Strategie

Dieses Projekt dient als praxisnahe Lern- und Testumgebung für Kubernetes, DevOps-Workflows und GitOps-Prinzipien.
Ich betreibe dafür einen Single-Node Kubernetes Cluster auf Bare-Metal (Thin Client, Debian 13), der bewusst möglichst nahe an unserem privaten produktiven Cluster aufgebaut ist.

Ziel des Projekts

Ziel ist es, neue Applikationen kontrolliert und reproduzierbar zu testen, bevor sie in den produktiven Cluster übernommen werden.
Dabei steht nicht „schnell deployen“, sondern Stabilität, Datenpersistenz und nachvollziehbare Entscheidungen im Fokus.

Technischer Aufbau

  • Bare-Metal Kubernetes (Single Node)
  • MetalLB für LoadBalancer-Funktionalität
  • NGINX Ingress Controller
  • TLS-Terminierung über cert-manager & Let’s Encrypt
  • Argo CD als Basis für GitOps-Deployments
  • Staging-Gedanke: Test → Bewertung → Entscheidung für oder gegen Produktion

Praxis-Use-Case: n8n 2 Versionsupgrade

Als realer Testfall wurde n8n über Helm im Cluster deployt.

Dabei wurden bewusst typische Produktionsfragen geprüft:

  • Persistenz von Daten (SQLite + Volume)
  • Verhalten bei Pod-Neustarts
  • Upgrade-Pfad auf eine neue Major-Version
  • Auswirkungen von Chart- und Applikations-Versionen

Nach Tests mit n8n Version 2 zeigte sich, dass die Persistenzanforderungen mit dem aktuellen Helm-Chart nicht zuverlässig erfüllt werden.
Aus diesem Grund wurde bewusst auf ein Deployment im produktiven Cluster verzichtet.

Warum diese Entscheidung wichtig ist

Ein zentrales Lernziel dieses Projekts war es, nicht jedes technisch mögliche Update auch produktiv auszurollen, sondern fundierte Entscheidungen zu treffen.

Ein Deployment gilt für mich erst dann als erfolgreich, wenn ein Pod-Neustart keine fachlichen Daten verliert.“

Was ich aus dem Projekt mitgenommen habe

  • Aufbau und Betrieb eines Bare-Metal Kubernetes Clusters
  • Ingress-, TLS- und Zertifikats-Handling in Kubernetes
  • GitOps-Denken mit Argo CD
  • Bewertung von Helm-Charts im Hinblick auf Produktionsreife
  • Systematisches Testen von Persistenz und Upgrade-Szenarien
  • Bewusste Abwägung zwischen „es läuft“ und „es ist produktionsreif“