Im Beitrag Kubernetes Ops Hilfe mit lokalem LLM hat ein handgeschriebener OpenAI-kompatibler Proxy kubectl als Tool für ein lokales Sprachmodell verfügbar gemacht. Dabei wurde Open WebUI als Chat-Oberfläche genutzt, so dass eine interaktive Diagnose möglich wurde. llama.cpp bringt inzwischen zwei Dinge von Haus aus mit, die einen alternativen Aufbau möglich machen: Eine eigene, in llama-server eingebettete Chat-Oberfläche und einen MCP-Client, der Werkzeuge über das Model Context Protocol (MCP) anspricht.
Dieser Beitrag zeigt, wie sich kubectl so über einen minimalen, selbst geschriebenen MCP-Server anbinden lässt, bewusst ohne auf ein fertiges MCP-Projekt zurückzugreifen, um die Prinzipien von MCP sichtbar zu machen. Im Ordner sample liegt dazu ein vollständiges, lauffähiges Docker-Compose-Setup. Für den produktiven Einsatz verweist der Beitrag am Ende auf etablierte Alternativen.

GraalVM Native Image übersetzt Java-Anwendungen vorab in ein natives Binary. Der Start dauert dann Millisekunden statt Sekunden, der Speicherbedarf sinkt deutlich, und zur Laufzeit wird keine JVM mehr benötigt. Für Anwendungen, die auf jedem Knoten eines Kubernetes-Clusters mitlaufen, sind das gute Argumente. Im konkreten Beispielprojekt, in dem sich ein schwer zu findender Fehler eingeschlichen hatte, ging es genau um Kubernetes Infrastruktur: Ein eigener CSI-Treiber wird als DaemonSet betrieben und belegt so Ressourcen auf jeder einzelnen Node.

Damit diese Optimierungen funktionieren, verschiebt Native Image Arbeit vom Programmstart in den Build. Dazu gehört die Klasseninitialisierung: Statische Initializer werden nicht zwangsläufig beim Start ausgeführt, sondern können bereits beim Bau des Binaries laufen. Deren Ergebnis wandert als fertiges Objektnetz in den sogenannten Image Heap. Keine Initialisierung mehr zur Laufzeit, keine Arbeit für einen Just in Time Compiler.
Das ist zum einen der Hebel für den Geschwindigkeitsgewinn aber gleichzeitig eine Fehlerquelle, die in der klassischen JVM-Welt so nicht existiert. Was ein statischer Initializer ableitet und ermittelt, wird einmalig zum Buildzeitpunt auf der Buildmaschine ausgeführt.

In Kubernetes-Clustern wird viel operatives Wissen zur Nutzung der richtigen kubectl-Befehle benötigt. Diese muss man neben den relevanten Kubernetes Grundlagen erst kennen: Welches Argument filtert Pods im CrashLoopBackOff, wie ließt man Events zu einem Deployment aus, welcher Selector gehört zu welchem Service. Ein lokal betriebenes Sprachmodell kann die Übersetzung von Fragen zum Kubernetes Cluster übernehmen: Aus einer Frage in natürlicher Sprache werden passende kubectl-Aufrufe, deren Ausgabe das Modell anschließend zusammenfasst.
Als Beispiel dient dazu ein vollständiges Docker-Compose-Setup aus llama.cpp, einem schlanken Python-Proxy und Open WebUI als Chat-Oberfläche. Dieser Beitrag stellt Konzept und Architektur des Setups vor, zeigt den Nutzen an einem konkreten Beispiel und geht auf Alternativen zu diesem Ansatz ein: Im Kleinen wie in der grundsätzlichen Architektur.

Im Beitrag Talos Kubernetes auf Hetzner Cloud einfach einrichten wurde ein Kubernetes Cluster mit Talos Linux auf einem Hetzner Cloud Server eingerichtet.
Die dort erzeugte Netzwerkkonfiguration deckte bishher lediglich das klassische IPv4 ab. Inzwischen sind IPv4 Adressen ein knappes Gut, so dass diese auch zunehmend teurer werden. Hetzner stellt jedem Cloud Server zusätzlich ein /64 IPv6-Subnetz bereit, das ohne Aufpreis genutzt werden kann.

Dieser Beitrag erweitert das Vorgehen und somit auch das Script, das den Netzwerk-Patch erzeugt, um IPv6. Anschließend werden die wesentlichen Unterschiede beschrieben, die beim Betrieb von Talos und Kubernetes im Dual-Stack, also mit IPv4 und IPv6 parallel, zu beachten sind.

Wer Container Images aus einer Registry bezieht, verlässt sich darauf, dass Inhalt und Herkunft stimmen. Signaturen machen das prüfbar: Sie binden einen Image-Digest an einen Aussteller und schützen so vor Manipulation zwischen Push und Pull.

Im OSS-Umfeld ist dafür meist Cosign aus dem Sigstore-Projekt im Einsatz, das wir in einem eigenen Beitrag behandelt haben. Cosign ist aber nicht das einzige praxisrelevante Werkzeug.
Dieser Beitrag stellt die zweite verbreitete Option vor: Notation aus dem Notary Project.

Talos Linux ist ein auf Kubernetes optimiertes Linux, dass auf die absolut wesentlichen Elemente reduziert ist. Auf typische Elemente einer Linux Distribution, wie z.B. ein Paketmanager wird dabei verzichtet. Selbst SSH ist nicht verfügbar: Sämtliche Interaktionen mit dem System werden über eine Talos System API ermöglicht.
Damit ist Talos Linux als minimales Linux aus der Perspektive der Systemsicherheit sehr attraktiv.

Die Installation erfolgt durch Images, so ähnlich, wie bei Mobiltelefonen. Ein Update besteht aus dem Download eines neuen Image und anschließendem Neustart. Als offizielle Boot Medien stehen ISO, USB-Stick und PXE zur Verfügung.
In diesem Beitrag geht es um ein etwas ungewöhnliches Installationsverfahren, das prinzipiell mit beliebigen bestehenden Linux Umgebungen kombinierbar sein sollte.
Als Beispielumgebung wird dazu die Hetzner Cloud verwendet.

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.

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.