Auf der DevOpsCon Berlin (15. bis 19. Juni 2026) steht erstmals der Workshop "Souveräne IT mit Kubernetes" (Sovereign IT with Kubernetes) auf dem Programm. Er entsteht aus einer Kooperation zwischen der trion GmbH und dem unabhängigen Trainer Erkan Yanar und wird von Thomas Kruse und Erkan Yanar gemeinsam geleitet.

Digitale Souveränität rückt angesichts zunehmender Cyberbedrohungen und der geopolitischen Lage stärker in den Fokus. Wer die Kontrolle über die eigenen Daten und Dienste behalten oder zurückgewinnen will, braucht dafür nicht nur Richtlinien, sondern technische Kontrolle. Der Workshop zeigt, wie sich souveräne IT mit einem hohen Grad an Automatisierung praktisch und sicher auf Basis von Kubernetes umsetzen lässt.

Ab und zu kommen Wünsche, die sich extrem einfach mit Kubernetes umsetzen lassen würde, aber …​
Kubernetes ist viel zu komplex!
Wir haben kein Kubernetes!
Es ist doch nur ein Server (aber Ausfallsicherheit brauchen wir schon) …​

Wie könnte also ein unterbrechungsfreies Deployment aussehen, wenn lediglich Docker und Docker Compose zur Wahl stehen, und was sind die Tradeoffs, die damit einher gehen?
Schauen wir es uns an einem praktischen Beispiel an.

GitLab hat mit GitLab CI eine angenehme Integration von Builds in die Repositoryverwaltung. Damit lassen sich Pipelines umsetzen, die schnelles Feedback liefern und damit helfen, die Software- und Systemqualität zu verbessern.
Die GitLab CI Runner helfen dabei, den Build zu skalieren, damit es auch hier nicht zu unnötigen Verzögerungen kommt.

Doch was, wenn der Wunsch besteht, dass genau das passiert? Es soll bis zu einem gewissen Zeitpunkt verzögert werden, da die bisherige Anwendung noch Session-basiert ist, und zu einem Zeitpunkt mit der geringsten Wahrscheinlichkeit für Störungen das Deployment erfolgen soll.

etcd spielt in Kubernetes Clustern typischerweise eine essentielle Rolle, denn hier wird der gesamte Zustand des Clusters gehalten. Die einzelnen Kubernetes API Server Instanzen selbst sind zustandslos.

etcd ist ein verteilter Key-Value-Store, der mit Multi-Version-Concurrency-Control arbeitet und darüber Change-Notification and Zugriff auf ältere Versionen ermöglicht.

Die Implementierung verwendet dazu einen Revisions-Zähler. Werden Daten gelöscht, hinzugefügt oder überschrieben, so werden diese Operationen stets zu einer neuen Revision assoziiert. Die vorheigen Zustände bleiben zunächst gespeichert, auch wenn sie überholt sind.

Damit diese quasi unendliche Geschichte nicht dazu führt, dass die Festplatte volläuft, müssen regelmäßig Wartungsaufgaben erfüllt werden.

Kubernetes speichert sämtliche Konfigurationsdaten des Clusters in einer Datenbank, typischerweise etcd.

etcd ist ein verteilter Key-Value-Store, durch mehrere Instanzen kann die Verfügbarkeit und Datensicherheit gewährleistet werden. Damit keine Daten verloren gehen, signalisiert etcd dem Betriebssystem per fsync()-Aufruf, dass ein sofortiges Schreiben auf Festplatte erfolgen soll.

Doch etcd kann auch zum Flaschenhals werden: Wenn keine Schreiboperationen möglich sind, ist auch die Clusteradministration blockiert. Ein weiterer Aspekt ist, dass selbst in einem relativ stabilen Cluster kontinuierliche Aktualisierungen diverser Kubernetes-Objekte erfolgen, wie z.B. zur Leader-Election.
Das führt zu recht hoher I/O-Last und kann bei günstigen SSDs/NVMe Speichern zu schneller Alterung führen.

Die Kubernetes Lernkurve fängt typischerweise mit einem Cluster an.
Das kann ein Minikube, mikrok8s, k3s, der Docker Desktop Kubernetes Cluster oder auch ein Cluster in der Cloud sein.

Ein Kubernetes Cluster kommt jedoch selten allein: Zumindest für Entwicklung und den produktiven Betrieb ist es sinnvoll, mit getrennten Clustern zu arbeiten.

Im Rahmen eines Integrationsprojekts von Kubernetes und Vault (bzw. OpenBao ) sollten Secrets aus Vault in Kubernetes bereitgestellt werden. Dabei sollten die verschiedenen direkten Vault Integrationen durch Infrastruktur in Kubernetes abgelöst werden, und die Vault Secrets als Kubernetes Secrets im Cluster verfügbar gemacht werden, um diese dann als Volume oder Umgebungsvariablen bereitzustellen. Damit soll zum einen das Token-Zero-Problem addressiert werden, also wenn Vault zur Verwaltung von Geheimnissen dient, wie werden die Anwendungen mit einem Geheimnis zur Authentifizierung am Vault versorgt, als auch die individuelle Vault Anbindung der verschiedenen Programmiersprachen und Frameworks.

Vault bietet mit dem Vault Secrets Operator auch direkt eine Integration an, die auf unterschiedliche Weise die Authentifizierung gegenüber Vault umsetzt, als auch für das Mapping der Vault Secrets. Ziel war jedoch nicht nur, ein entsprechendes Setup zu implementieren, sondern eine automatisierte Testbarkeit herzustellen. Dazu wird ein stabiles, reproduzierbares Setup benötigt, um die Kubernetes-Vault-Integration jederzeit in der CI Umgebung frisch herzustellen.

In dem Zuge wurde ein Verfahren benötigt, JWK (JSON Web Keys) im PEM Format bereitzustellen - und das am besten automatisiert durch ein einfaches Shell Script z.B. mit der Bash. Eine Umsetzung auf Basis von Kubernetes OIDC JWKS in PEM formatiertes Material zu erhalten wird im folgenden beschrieben.

Gerade für Experimente und zur Entwicklung bietet sich ein lokaler Kubernetes Cluster an. Zur einfachen Umsetzung gibt es diverse Optionen wie Minikube, KinD oder auch k3s. Auch wir setzen in unseren Kubernetes Schulungen gerne auf ein Cluster Setup, dass durch die Teilnehmer mit geringem Aufwand auf dem eigenen System verwendet werden kann, um auch nach der Schulung eigenständig weiter zu lernen und Übungen nachzuvollziehen.

Wie geht man jedoch bei so einem Setup mit dem Thema TLS Zertifikaten um?
Umgehen ist nicht immer ein praktikabler Weg: Manche Browser APIs, wie zum Beispiel der Zugriff auf die Webcam erfordern schlicht den Einsatz von TLS.

Speziell für diesen Anwendungsfall bietet traefik.me eine Domain, Wildcard-DNS Service und ein durch Let’s Encrypt validiertes Zertifikat an. Dieser Beitrag zeigt die Verwendung von traefik.me in Kombination mit Kubernetes.

Die Absicherung von HTTP Zugriffen mittels TLS (früher SSL) ist spätestens seit den Enthüllungen von Edward Snowden auch für Anwendungen außerhalb von Banken und Medizin zum Standard geworden. Vor allem Dank des kostenlos nutzbaren Let’s Encrypt sind auch die - früher teils horrenden - Kosten kein Grund mehr, auf TLS zu verzichten.
Die meisten Zertifikatanbieter, die das durch Let’s Encrypt eingeführte ACME Protokoll unterstützen, bieten bei Verwendung der DNS Challenge auch Wildcard Zertifikate an. Wird für einen Kubernetes Cluster primär mit Hostnamen in einer Domain oder Subdomain gearbeitet, so bietet sich ein Wildcard Zertifikat entsprechend an. Damit kann unter Umständen sogar der Einsatz des häufig zusätzlich zur Ingress Implementierung betriebenen Cert Manager entfallen: Dazu würde das Wildcard-Zertifikat als Default TLS Zertifikat im Ingress Controller konfiguriert werden/

Wie das funktioniert, wird im folgenden Beitrag beschrieben.

Kubernetes eignet sich hervorragend auch für kleine Setups, z.B. in einem Homelab, und auch bei begrenzten Hardwareressourcen. Dafür gibt es beispielsweise besonders schlanke Distributionen wie k3s.
Der immense Vorteil von Kubernetes liegt in den bereitgestellten APIs und der sehr einfachen Möglichkeit, alle Konfigurationen deklarativ zu verwalten.

Um Kubernetes als gute Plattform auch für Homelab Anwendungen zu demonstrieren geht es in diesem Beitrag darum, wie der Werbeblocker Pi-Hole auf Kubernetes betrieben werden könnte.