Kubernetes, AI und die Zukunft der Infrastruktur: Eine Einladung zum Diskurs

“Man gewinnt keine Zeit damit…” - Diesen Einwand höre ich oft, wenn es um Kubernetes geht. Doch in den letzten Monaten hat sich etwas Grundlegendes verändert. Die Kombination von Kubernetes und AI-Tools eröffnet Workflows, die vor einem Jahr noch undenkbar waren. Gleichzeitig wirft diese Entwicklung Fragen auf, über die wir als Community sprechen sollten.

Was gerade passiert: Beobachtungen aus der Praxis

Stell dir vor, du könntest einfach fragen: “Have a look at the ‘b4mad-agent-registry-prod’ namespace in Kubernetes, propose good practice and secure network policies” - und erhältst innerhalb von Sekunden durchdachte, auf deine spezifische Infrastruktur zugeschnittene Vorschläge.

Das ist keine Zukunftsmusik. In meinem eigenen Setup nutze ich Claude Code mit dem Kubernetes MCP Server, um genau das zu tun. Der Workflow sieht so aus:

Phase 1 - Analyse: Claude inspiziert den Namespace live, analysiert Deployments, HPA-Konfigurationen und den PostgreSQL-Cluster. Dabei berücksichtigt es nicht nur den aktuellen Zustand, sondern auch Skalierungsziele.

Phase 2 - Design: Basierend auf den Live-Daten werden ResourceQuotas berechnet - nicht für die aktuelle Replica-Anzahl, sondern für den HPA-Maximum-Scale plus Puffer. Oder: Network Policies werden nach dem Principle of Least Privilege entworfen, mit Default-Deny als Baseline und expliziten Regeln für jeden Traffic-Flow.

Phase 3 - Implementation: Claude generiert produktionsreife YAML-Manifeste, komplett mit SPDX-Headers und präzisen Label-Selektoren.

Phase 4 - Validation: Gemeinsam entwickeln wir Test-Strategien, um sicherzustellen, dass die Policies funktionieren und nichts Unerwartetes blockiert wird.

Was früher Stunden an Dokumentationsrecherche, Trial-and-Error und mehrere Review-Zyklen erforderte, ist jetzt in Minuten erledigt. Die AI hat Zugriff auf den aktuellen Cluster-Zustand, versteht Zusammenhänge zwischen Komponenten und kann Best Practices direkt anwenden.

Interessanterweise beobachten wir parallel eine andere Entwicklung: Fly.io berichtet, dass ihre am stärksten wachsende Kundengruppe nicht mehr menschliche Entwickler sind, sondern AI-Agents selbst - “vibe coders”, die iterativ Code generieren und Infrastruktur aufbauen. Die Anforderungen dieser AI-Systeme unterscheiden sich fundamental von dem, was wir bisher als Best Practices kannten.

Warum Kubernetes sich als Grundlage eignet

Der deklarative Ansatz

Kubernetes funktioniert fundamental anders als traditionelle imperative Systeme. Statt Schritt für Schritt Anweisungen zu geben, beschreibst du den gewünschten Zielzustand. Kubernetes kümmert sich um den Rest.

Dieser deklarative Ansatz hat sich als besonders wertvoll für AI-gestützte Workflows erwiesen. YAML-Manifeste sind strukturiert und maschinenlesbar - AI-Modelle können sie analysieren, verstehen und generieren. Die klare Trennung zwischen Soll-Zustand und Ist-Zustand ermöglicht präzise Analysen und Vorschläge.

Aber hier beginnt es interessant zu werden: Während wir als Entwickler AI nutzen, um bessere Kubernetes-Manifeste zu erstellen, bauen AI-Agents selbst Applikationen, die oft ganz andere Muster nutzen - stateful iteration statt immutable containers, schnelles Start/Stop statt long-running processes. Fly.io musste feststellen, dass Features, die sie für Menschen gebaut haben, für AI-Agents weniger relevant sind, während andere Features (wie ultra-schnelles Machine-Start/Stop) plötzlich kritisch wurden.

Der Reconciliation Loop

Das Herzstück von Kubernetes ist der Reconciliation Loop - der kontinuierliche Prozess, bei dem der Ist-Zustand mit dem Soll-Zustand abgeglichen wird. Dieser Loop ist selbstheilend, transparent und nachvollziehbar.

Für AI-gestützte Workflows bedeutet das: Die AI kann jederzeit den aktuellen Zustand analysieren, mit Best Practices abgleichen und konkrete Verbesserungsvorschläge machen. In meinem Beispiel analysiert Claude nicht nur die aktuellen Deployments, sondern auch die HPA-Konfiguration, um ResourceQuotas zu berechnen, die auch bei maximaler Skalierung funktionieren.

Der Reconciliation Loop garantiert dabei Konsistenz, selbst wenn Änderungen vorgenommen werden. Das ist besonders wichtig, wenn AI-Agents iterativ arbeiten und Konfigurationen schrittweise anpassen.

Standardisierte Interfaces

Kubernetes bietet eine Fülle von APIs und Interfaces - von kubectl über Custom Resource Definitions bis hin zu Operator-Patterns. Diese Interfaces sind standardisiert, dokumentiert und maschinenlesbar.

Das Model Context Protocol (MCP) macht diese Interfaces für AI-Systeme nutzbar. Der Kubernetes MCP Server ermöglicht es AI-Tools, direkt mit dem Cluster zu interagieren:

• resources_list für einen Überblick über alle Ressourcen
• resources_get für detaillierte Informationen zu spezifischen Objekten
• pods_list für Pod-Level-Analysen

Das ermöglicht AI-Systemen direkten Zugriff auf den “Maschinenraum” - nicht basierend auf möglicherweise veralteter Dokumentation, sondern auf Live-Daten aus dem Cluster.

Offene Fragen und Herausforderungen

Die Integration von AI und Kubernetes wirft spannende Fragen auf:

Sicherheit und Secrets: Wie gehen wir damit um, wenn AI-Agents Zugriff auf Infrastruktur-APIs benötigen? In meinem Setup hat der MCP Server vollen Cluster-Zugriff über meine KUBECONFIG. Das ist praktisch für die Entwicklung, aber für Produktionsumgebungen brauchen wir granularere Zugriffskontrolle. Fly.io experimentiert mit “tokenized OAuth tokens” - temporäre Zugriffsrechte statt permanenter Credentials. Wie könnte so etwas in Kubernetes aussehen? RBAC-Policies für AI-Agents? Temporäre ServiceAccounts mit kurzen TTLs?

Stateful vs. Immutable: AI-Agents arbeiten oft iterativ und stateful - genau das Gegenteil dessen, was wir als Container-Best-Practice gelernt haben. Fly.io beobachtet, dass AI-Agents Machines inkrementell aufbauen, Packages nachinstallieren und Code in laufenden Containern editieren. Müssen wir unsere Patterns überdenken? Oder gibt es einen Mittelweg - vielleicht separate Namespaces für AI-generierte “Experimental Workloads” mit anderen Policies als für Production-Deployments?

Verification und Trust: Wenn eine AI NetworkPolicies vorschlägt, die einen Default-Deny-Ansatz mit expliziten Egress-Rules für S3-Backups kombiniert - woher weiß ich, dass das korrekt ist? Meine Erfahrung zeigt: Die besten Ergebnisse entstehen im Dialog. Die AI schlägt vor, ich validiere, wir iterieren. Aber was, wenn AI-Agents autonom Infrastruktur deployen? Wie stellen wir sicher, dass das System nicht in eine Richtung optimiert, die wir nicht wollen?

Developer Experience vs. Robot Experience: Wir haben Jahre damit verbracht, Tools wie flyctl launch zu bauen, die für Menschen intuitiv sind. Aber AI-Agents nutzen diese Features kaum - sie interagieren direkt mit APIs. Brauchen wir andere Abstractions? Das MCP ist ein Schritt in diese Richtung, aber es gibt noch viele offene Fragen zur richtigen Balance zwischen menschlicher und maschineller Nutzung.

Von der Theorie zur Praxis - konkrete Ergebnisse

In meinem Setup habe ich diesen Workflow bereits mehrfach durchlaufen. Einige Erkenntnisse:

ResourceQuotas sind komplex: Die Kalkulation muss HPA max scale berücksichtigen, alle Komponenten einbeziehen (App, Database, Connection Pooler) und Puffer für Wachstum einrechnen. Claude hat mir geholfen, das systematisch durchzurechnen - von 2 Replicas aktuell zu 8 Replicas bei HPA max, multipliziert mit den Container-Requests, plus PostgreSQL, plus 20% Puffer. Das Ergebnis: präzise Quotas, die weder zu knapp noch verschwenderisch sind.

Network Policies brauchen Kontext: Eine Policy pro Komponente (Application, PostgreSQL, PGBouncer) mit expliziten Ingress- und Egress-Rules. Die AI versteht den Traffic-Flow: Ingress Controller zu App, App zu PGBouncer, PGBouncer zu PostgreSQL, PostgreSQL zu S3 für Backups. Sie generiert nicht nur die Policies, sondern auch Test-Strategien, um Connectivity zu validieren.

Der Dialog ist entscheidend: Die besten Ergebnisse entstehen nicht, wenn ich die AI einfach machen lasse. Sie entstehen, wenn ich Fragen stelle, Vorschläge hinterfrage und verstehe, warum eine bestimmte Konfiguration empfohlen wird. Die AI ist ein Werkzeug, das meine Fähigkeiten erweitert, nicht ersetzt.

Ein Aufruf zur Zusammenarbeit

Wir stehen am Anfang einer Entwicklung, deren Tragweite wir noch nicht vollständig überblicken. Die Kombination von deklarativer Infrastruktur und AI-Unterstützung verändert, wie wir Systeme bauen und betreiben.

Ich glaube, wir sollten darüber als Community sprechen:

• Welche Erfahrungen macht ihr mit AI-gestützten Kubernetes-Workflows?
• Wie löst ihr die Security-Herausforderungen? Welche RBAC-Patterns funktionieren?
• Seht ihr ähnliche Muster wie fly.io - AI-Agents als “Nutzer” eurer Infrastruktur?
• Welche Best Practices müssen wir überdenken? Welche bleiben relevant?
• Wie testet und validiert ihr AI-generierte Manifeste?

Der deklarative Ansatz von Kubernetes, der Reconciliation Loop und die standardisierten Interfaces schaffen eine solide Grundlage. Aber wie wir diese Grundlage nutzen - das sollten wir gemeinsam herausfinden.

Ressourcen und Weiterführendes

• Kubernetes MCP DevOps Guide - Vollständiger Praxis-Leitfaden mit konkreten Beispielen
• Fly.io: Our Best Customers Are Now Robots - Perspektive eines Cloud-Providers auf AI-Agents als Nutzer
• Kubernetes MCP Server - MCP Server für Kubernetes-Integration
• Model Context Protocol - Standard für AI-Agent-Interaktionen

Was sind eure Gedanken dazu? Lasst uns diskutieren - in den Kommentaren, auf Mastodon, in Slack-Channels. Diese Entwicklung betrifft uns alle, und gemeinsam können wir herausfinden, wie wir sie am besten gestalten.