Eine KI, die deinen Cluster richtig dimensioniert – und eine Plattform, die nicht zulässt, dass sie die Produktion kaputt macht

Das Problem: „Einer KI Zugriff auf unsere Infrastruktur zu geben“ ist ein großartiger Weg, ein selbstbewusstes Modell dazu zu bringen, die Produktion um 3 Uhr morgens auf eine einzige Replik zu skalieren. Die interessante technische Arbeit bei agentischer Operations liegt nicht im Modell – sondern in den Schutzmechanismen. Die Lösung: Gib der KI eine typisierte, begrenzte Schnittstelle zu deinem Cluster über MCP, und lege die Sicherheitslogik serverseitig ab, wo das Modell sie nicht umgehen kann. Die KI entscheidet, was geändert wird; die Plattform entscheidet, was sie darf – und verweigert den Rest, selbst wenn direkt darum gebeten wird.

Ein Model Context Protocol (MCP)-Server stellt fünf FinOps-Tools über einem laufenden Kubernetes-Cluster bereit. Claude (oder ein beliebiger MCP-Client – Claude Desktop usw.) nutzt sie, um überdimensionierte Workloads zu finden und eine korrekte Dimensionierung vorzuschlagen. Jeder mutierende Aufruf wird bevor irgendetwas passiert gegen eine Richtlinie geprüft und standardmäßig als Dry-Run ausgeführt; unsichere Änderungen – ein geschützter prod-Namespace, eine Ressourcenuntergrenze, ein zu aggressiver Schnitt – werden vom Server verweigert und in einem Audit-Log festgehalten.

Läuft vollständig auf einem Laptop: ein kind-Cluster, der mit absichtlich verschwenderischen Workloads bestückt ist, ein ~120-zeiliger MCP-Server und ein Copilot-Treiber, der standardmäßig offline läuft (ein deterministischer Mock, funktioniert also ohne API-Schlüssel und in CI) oder mit echtem Claude, wenn ANTHROPIC_API_KEY gesetzt ist.

Was es macht

   Claude / MCP client
          │  calls typed tools
          ▼
   ┌─────────────── MCP server (finops-copilot) ───────────────┐
   │  list_namespaces  list_workloads  estimate_cost           │
   │  recommend_rightsizing        get_audit_log               │
   │                                                           │
   │  apply_rightsizing(…, dry_run=True)                       │
   │        │                                                  │
   │        ▼   ┌─────────── policy.py (guardrails) ────────┐  │
   │     every  │ protected namespaces? resource floors?    │  │
   │     apply ─┤ max single-step cut?  → REFUSE + audit    │  │
   │            └───────────────────────────────────────────┘  │
   └────────────────────────┬──────────────────────────────────┘
                            │ kubectl (read specs / patch)
                            ▼
                  kind cluster: staging (waste) · prod (protected)

Ausführen

make up            # kind cluster seeded with waste + Python env (MCP deps)
make demo          # the copilot finds & cuts waste — OFFLINE, no API key needed
make demo-claude   # real Claude drives the same MCP tools (needs ANTHROPIC_API_KEY)
make test          # unit-test the guardrail policy (no cluster needed)
make down          # delete the cluster

make demo führt einen deterministischen Mock-Copilot über dem echten MCP-Server aus – gleiche Tools, gleiche Schutzmechanismen wie beim Claude-Pfad –, funktioniert also ohne Schlüssel und in CI. make demo-claude tauscht den Mock gegen Claude aus, der die Tools agentisch steuert (offizielles Anthropic SDK + dessen MCP-Tool-Runner).

Was die Demo beweist (echte Ausgabe)

Gegenüber einem staging-Namespace, der mit vier Workloads bestückt ist (drei massiv überdimensioniert, einer gesund) und einem geschützten prod:

1. Findet die Verschwendung. staging kostet bei aktuellen Requests ~$138/Monat; das Tool markiert die drei Workloads mit 1–4 % CPU-Auslastung und schlägt CPU- und Replica-Kürzungen vor – ~$102/Monat (73 %) prognostizierte Ersparnis.

2. Zuerst Dry-Run. Jede Änderung ist ein Dry-Run, der den genauen Diff und die monatliche Ersparnis zeigt. Nichts wird angewendet ohne einen expliziten Nicht-Dry-Run-Aufruf.

3. Die Plattform verweigert prod. Auch gebeten, prod zu verschlanken, verweigert der Server – namespace 'prod' is protected. Die KI hat gefragt; die Schutzmechanismen haben Nein gesagt. Keine Änderung, nicht einmal ein Dry-Run.

4. Die Plattform verweigert einen zu aggressiven Schnitt. Gebeten, einen CPU-Request auf 10m zu reduzieren, verweigert der Server – unter der Untergrenze und ein einstufiger Schnitt von >90 %.

5. Jede Aktion wird protokolliert. Der Audit-Trail zeigt alle fünf Versuche – drei Dry-Runs, zwei Verweigerungen – mit Gründen.

Die KI hat die Verschwendung gefunden und die Kürzungen vorgeschlagen. Die Plattform hat entschieden, was erlaubt war. Diese Arbeitsteilung ist der eigentliche Punkt.

Von Claude Desktop aus verwenden (echtes MCP)

Das ist ein echter MCP-Server – du kannst jeden MCP-Client darauf ausrichten. Für Claude Desktop füge zu claude_desktop_config.json hinzu:

{
  "mcpServers": {
    "finops": {
      "command": "/path/to/mcp-finops-copilot/.venv/bin/python",
      "args": ["-m", "finops.server"],
      "env": { "FINOPS_CTX": "kind-mcp-finops" }
    }
  }
}

Dann frag Claude: „Was kostet mein Staging-Namespace und was kann ich sicher neu dimensionieren?“

Wie es auf die Produktion übertragen wird

Aufbau

finops/policy.py     the guardrail layer — pure, unit-tested (make test)
finops/cost.py       cost model + right-sizing heuristic
finops/kube.py       kubectl read/patch helpers
finops/server.py     the MCP server: 5 tools, dry-run-by-default, audited
copilot/mock_agent.py   deterministic offline copilot (CI-safe)
copilot/llm_agent.py    real Claude via the Anthropic SDK's MCP tool-runner
copilot/driver.py       picks mock vs Claude by ANTHROPIC_API_KEY
k8s/                 staging (seeded waste) + prod (protected)

MIT-lizenziert. Eine kleine, auf dem Laptop ausführbare, NDA-sichere Demo, die eine klare Idee beweist: Agentische Ops ist ein Problem der Schutzmechanismen. Gib der KI echte Aktionen, aber mach die Plattform zu der Instanz, die Nein sagt.