MCP Servers auf Kubernetes: AI-gestützter Betrieb für Plattform-Teams

Das Model Context Protocol (MCP) verändert, wie Entwickler mit Infrastruktur interagieren. Statt zwischen Grafana, Loki, kubectl und GitLab zu wechseln, um ein Problem zu debuggen, fragt ein AI-Assistent alle in Sekunden ab und gibt eine korrelierte Antwort.

Die meisten Teams betreiben MCP Servers lokal, als Dev-Tools auf einzelnen Rechnern. Das funktioniert für Prototyping. Aber wenn Sie 10 Teams auf einer gemeinsamen Managed-Kubernetes-Plattform haben, die alle Zugriff auf Metriken, Logs und Cluster State brauchen, skalieren lokale MCP Servers nicht. Sie brauchen Credentials, Netzwerkzugriff und Konfiguration, die pro Cluster und pro Team variiert.

Wir betreiben MCP Servers als produktive Kubernetes-Services. Sie werden via FluxCD deployed, als Teil der Plattform gemanagt und auf die Namespaces und Berechtigungen jedes Teams beschränkt. Dieser Beitrag erklärt die Architektur, die MCP Servers, die wir deployen, und wie das in das Self-Service-Modell passt, das wir aufgebaut haben.

Die Architektur

MCP Servers laufen als Kubernetes Deployments im Cluster, neben den Platform Services, mit denen sie sich verbinden. Jeder MCP Server ist eine dünne API-Schicht, die MCP-Protokoll-Anfragen in Queries gegen den darunterliegenden Service übersetzt (PromQL für Prometheus, LogQL für Loki, Kubernetes-API-Calls für Cluster State).

Der AI-Client (Claude Code, Cursor oder ein Custom Agent) verbindet sich über das MCP-Protokoll mit den MCP Servers. Die Verbindung ist authentifiziert und scoped: Ein Entwickler im Team-Data kann nur Metriken und Logs aus Namespaces abfragen, auf die er Zugriff hat. Das gleiche RBAC-Modell, das den kubectl-Zugriff und ArgoCD-Projekte regelt, regelt den MCP-Zugriff.

Die MCP Servers, die wir deployen

Prometheus MCP ist am sofort nützlichsten. Ein Entwickler fragt "Was ist die Error Rate meiner API?" und der AI-Agent übersetzt das in eine PromQL-Query, führt sie gegen das Prometheus des Clusters aus und liefert das Ergebnis mit Kontext. Kein Suchen nach dem richtigen Grafana-Dashboard oder Erinnern an PromQL-Syntax mehr. Das funktioniert für jede Metrik, die wir sammeln: Request-Latenz, Pod-Ressourcennutzung, GPU-Auslastung, Custom Application Metrics.

Loki MCP gibt AI-Assistenten Zugang zur Log-Suche. "Zeige mir Errors von api-service der letzten 30 Minuten" wird zu einer LogQL-Query, die gegen die Loki-Instanz des Clusters ausgeführt wird. Die AI kann Log-Muster mit Metrik-Anomalien korrelieren, ohne dass der Entwickler einen einzigen Browser-Tab öffnet.

Kubernetes MCP exponiert Cluster State: Pods, Events, Deployments, Resource Quotas. Wenn ein Entwickler fragt "Warum hängt mein Pod?", prüft die AI Pod-Status, Node-Ressourcen, Events und Scheduling-Constraints in einer Abfrage. Sie macht die gleiche mehrstufige kubectl-Untersuchung, die ein Mensch 5 Minuten brauchen würde, in 5 Sekunden.

Grafana MCP liefert Dashboard-Links und Annotation-Kontext. Wenn die AI eine Anomalie in Metriken findet, kann sie zum relevanten Grafana-Dashboard mit dem korrekten Zeitbereich und Namespace-Filter verlinken. Der Entwickler bekommt einen klickbaren Link, keine Wand aus JSON.

GitLab MCP verbindet sich mit den Git-Repositories und CI-Pipelines des Kunden. "Was hat sich beim letzten Deploy geändert?" wird beantwortet, indem der letzte Merge Request und sein Pipeline-Status angeschaut werden. Das schliesst die Schleife zwischen "etwas ist kaputt" und "was hat es verursacht".

Alertmanager MCP exponiert aktive Alerts und Silences. Die AI kann prüfen, ob bereits ein Alert für das Problem feuert, das der Entwickler untersucht, oder ob das Problem kürzlich gesilenced wurde (was bedeutet, dass jemand bereits daran arbeitet).

Wie das für einen Entwickler aussieht

Hier ist ein realer Troubleshooting-Flow:

Der Entwickler tippt einen Satz. Der AI-Agent fragt drei Platform Services ab, korreliert die Daten, identifiziert die Root Cause und schlägt einen Fix vor. Der Entwickler aktualisiert eine Zeile in seinen Helm Values, pusht zu Git, und ArgoCD synct die Änderung.

Vergleichen Sie das mit dem traditionellen Workflow:

Der Unterschied ist nicht nur Geschwindigkeit. Es ist Zugänglichkeit. Ein Junior-Entwickler, der weder PromQL, LogQL noch kubectl-Debug-Befehle kennt, kann jetzt Production-Issues mit der gleichen Effektivität troubleshooten wie ein Senior Platform Engineer. Der AI-Agent kennt die Query-Sprachen. Der Entwickler kennt den Kontext.

GitOps macht das möglich

MCP Servers sind mächtig zum Lesen von Platform State. Aber der Fix muss weiterhin durch Git. Hier wird unsere GitOps-Architektur kritisch.

Wenn der AI-Agent vorschlägt "Memory Limit auf 512Mi erhöhen", macht der Entwickler kein SSH auf einen Node und führt kein kubectl edit aus. Er aktualisiert values.yaml in seinem Git Repository, pusht, und ArgoCD reconciled. Die Änderung ist auditiert, reviewed und reproduzierbar.

Das strukturierte Datenmodell von GitOps (Helm Values, Kustomize Overlays, plain YAML Manifests) ist das, was AI-gestützten Betrieb praktikabel macht. Die AI kann den aktuellen State via MCP lesen, eine Änderung im Deployment-Manifest vorschlagen, und der Entwickler appliziert sie über den gleichen Git-Workflow, den er für jede andere Änderung nutzt. Kein spezielles Tooling, keine ad-hoc kubectl-Befehle, kein Configuration Drift.

Das ist das Schwungrad: MCP Servers lesen Platform State, AI korreliert und schlägt vor, GitOps appliziert den Fix, und die Plattform reconciled. Jeder Schritt ist auditierbar, reversibel und team-scoped.

Self-Service-Schichten

MCP ist die neueste Schicht in unserem Self-Service-Modell. Jede Schicht bedient ein anderes Bedürfnis:

Die Schichten bauen aufeinander auf. Grafana-Dashboards geben Teams Sichtbarkeit. ArgoCD gibt Teams Deployment-Autonomie. MCP gibt Teams Troubleshooting-Autonomie. Und wenn das Problem übersteigt, was Self-Service lösen kann, komplexe Netzwerk-Probleme, Cross-Namespace-Interaktionen, Plattform-Level-Failures, springt unser 3rd-Level-Support-Team ein, mit der Erfahrung aus dem Betrieb über unsere gesamte Flotte.

Wie wir MCP Servers managen

MCP Servers sind Plattform-Komponenten. Sie werden gleich deployed, überwacht und upgradet wie jeder andere Platform Service:

• Deployed via FluxCD aus unserem internen Plattform-Repository. Kunden verwalten den MCP-Server-Lifecycle nicht.
• Überwacht durch Prometheus mit Dashboards in Grafana. Wir tracken Query-Latenz, Error Rates und Connection Counts pro Team.
• Gesichert via RBAC, das die bestehenden Team-Berechtigungen spiegelt. Wenn ein Team Lesezugriff auf einen Namespace hat, scoped der MCP Server Queries auf diesen Namespace.
• Kontinuierlich aktualisiert, wenn sich das MCP-Ökosystem weiterentwickelt. Neue MCP Servers, Protokoll-Updates und Security Patches werden über die Flotte ausgerollt.

Das ist die gleiche langfristige Wartungsgeschichte wie bei jeder anderen Plattform-Komponente. Wir verfolgen das Ökosystem, evaluieren neue Tools und betreiben sie, damit Ihre Teams sie nutzen können.

Loslegen

MCP Servers sind als Add-on auf unserer Managed-Kubernetes-Plattform verfügbar. Wenn Ihre Teams bereits AI-Coding-Assistenten nutzen (Claude Code, Cursor, GitHub Copilot), ist die Verbindung mit Ihren tatsächlichen Plattform-Daten über MCP Servers der nächste Schritt.

Vereinbaren Sie einen Termin, um zu besprechen, welche MCP Servers für Ihr Setup sinnvoll sind. Wir schauen uns Ihren Observability-Stack, Ihre Team-Struktur und Ihr RBAC-Modell an und deployen die richtigen MCP Servers, scoped auf jedes Team.