# Kubernetes Architecture Prover MCP for AI Agents AI Agent Connect

> Kubernetes Architecture Prover audits your Kubernetes manifests to ensure they meet production-grade standards. It stops your AI agent from deploying lazy configurations that lack resource limits, security hardening, or proper network policies. Instead of just checking if a YAML file is valid, it verifies if the architecture is actually reliable and secure enough for a live environment.

## Overview
- **Category:** infrastructure
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_5R8kMC05RFsYvzrADI0onwKUjFTA7YO6YqsJzlol/ai-agent-connect
- **Tags:** kubernetes, k8s, container-orchestration, resource-limits, pod-security, network-policies, observability, sre, platform-engineering

## Description

Imagine your AI agent builds a payment service. It looks perfect on paper, but it is running as root and has no memory limits. It works in staging, but at 3 AM, a logging sidecar eats all the node memory and crashes your production app. That is the problem this Connector solves. It acts as a gatekeeper for your infrastructure. When your agent generates a manifest, this tool forces it to think about the what ifs. What happens if a node fails? What if a container tries to scan your internal network? It does not just let the agent say the cluster handles it. It demands specific numbers for CPU requests, specific security flags like runAsNonRoot, and explicit network rules. It turns your agent from a YAML generator into a production engineer. By using the Vinkius catalog to connect this, you ensure that every deployment your agent touches is hardened against common pitfalls like OOM kills, container escapes, and flat network exposure. You get a verified architecture that actually survives the real world.

## Tools

### validate_kubernetes_architecture
Audits a manifest for resource limits, security, reliability, and networking. It provides a verdict and specific instructions to fix any architecture gaps.

## Prompt Examples

**Prompt:** 
```
I need to deploy a python worker. Just make it work.
```

**Response:** 
```
### ⚠️ RESOURCES_UNGOVERNED

'Just making it work' means no CPU or memory limits. The first noisy neighbor will OOM-kill your worker. 

**Required Fixes:**
* **Limits:** Define `memory: 512Mi` and `cpu: 500m`.
* **Governance:** Add a `LimitRange` to the namespace.
* **Reliability:** Ensure you have at least 2 replicas.
```

**Prompt:** 
```
Deploy a postgres DB. Make sure it's safe and won't go down.
```

**Response:** 
```
### ✅ ARCHITECTURE_PROVEN

Production-grade configuration validated.

**Summary of Protections:**
* **Reliability:** 3 replicas with PodDisruptionBudget and anti-affinity.
* **Security:** `runAsNonRoot=true` and `PodSecurityStandard=restricted`.
* **Networking:** Deny-all NetworkPolicy with explicit ingress/egress rules.
* **Observability:** Liveness and readiness probes included.
```

**Prompt:** 
```
Write a manifest for my frontend. It needs to be accessible from the internet.
```

**Response:** 
```
### ⚠️ NETWORKING_EXPOSED

Your current plan allows any pod to reach the frontend. A compromised pod could scan your internal network.

**Required Fixes:**
* **NetworkPolicy:** Implement a default deny-all policy.
* **Ingress:** Use a dedicated ingress controller with TLS termination.
* **Egress:** Whitelist only the specific external APIs your frontend needs to call.
```

## Capabilities

### Enforce CPU and memory limits
The tool ensures every container has specific requests and limits to prevent noisy neighbors from crashing your app.

### Lock down container security
It checks for root access, dropped capabilities, and read only filesystems to harden your workloads.

### Design high-availability replicas
The tool requires multiple replicas and anti-affinity rules to ensure your service stays up during node drains.

### Set up liveness and readiness probes
It forces the agent to include health checks so Kubernetes can actually detect and manage deadlocked pods.

### Create network isolation rules
It validates that you have a deny-all default NetworkPolicy to stop lateral movement by attackers.

### Detect architectural contradictions
The tool identifies and rejects hand-wavy logic like the cluster handles it or flat network is simpler.

## Use Cases

### Preventing Noisy Neighbors
An engineer asks to deploy a new microservice. The agent tries a manifest without limits. The tool catches it as RESOURCES_UNGOVERNED and forces the engineer to define specific CPU and memory ceilings.

### Hardening Public APIs
A developer wants to expose a web front end. The tool identifies NETWORKING_EXPOSED because there is no NetworkPolicy and forces the agent to create a deny-all rule with specific ingress allows.

### Ensuring Zero-Downtime Deploys
The agent proposes a single-replica deployment. The tool flags this as RELIABILITY_UNDESIGNED and requires at least two replicas with a PodDisruptionBudget.

### Securing Internal Workloads
A user asks to run a legacy app. The tool catches the SECURITY_UNHARDENED status because it is running as root and forces the agent to drop all capabilities.

## Benefits

- Stop OOM kills by forcing resource limits via validate_kubernetes_architecture.
- Prevent container escapes by enforcing runAsNonRoot and PodSecurityStandard checks.
- Eliminate single points of failure with reliabilityDesigned replica and anti-affinity requirements.
- Fix blind deployments by requiring liveness, readiness, and startup probes.
- Block lateral movement by enforcing networkingRestricted deny-all NetworkPolicies.
- Get immediate coaching on lazy logic instead of actual configurations.

## How It Works

The bottom line is you get production-ready Kubernetes manifests that won't crash your cluster.

1. Provide your AI agent with a draft Kubernetes manifest or a deployment plan.
2. Invoke the validation tool to audit the manifest against production standards.
3. Receive a verdict and specific coaching to fix architecture gaps.

## Frequently Asked Questions

**Can Kubernetes Architecture Prover catch OOM kills?**
Yes, it forces resource limits on every container. It ensures that your workloads have defined memory ceilings so they won't crash the node.

**Does it work for any Kubernetes cluster?**
Yes, it validates the manifest logic. It works regardless of whether you are on GKE, EKS, AKS, or a self-managed cluster.

**Will it stop my AI from making mistakes?**
It acts as a gatekeeper. It catches common AI hallucinations where the agent might skip security or reliability steps to keep the YAML simple.

**Does it handle network security?**
Yes, it specifically looks for NetworkPolicies. It ensures you aren't running a flat network where every pod can talk to every other pod.

**Is this for production use?**
Yes, it is specifically designed for production-grade architecture. It focuses on the guardrails that prevent outages and security breaches.

**What happens if my manifest is rejected?**
The tool provides a specific verdict and coaching. It tells your agent exactly which part of the architecture is failing and how to fix it.

**Does it generate Kubernetes manifests?**
No. It validates that your architecture addresses the five production-critical pillars — resource governance, security hardening, reliability design, observability instrumentation, and network restriction. It does not generate YAML. It forces you to prove your YAML is production-ready.

**What counts as proper resource governance?**
Every container must have CPU and memory requests AND limits. Every namespace must have a LimitRange (defaults for containers that don't specify) and a ResourceQuota (ceiling for the namespace). 'The cluster handles it' is not governance — it is the absence of governance.

**Is it useful for managed Kubernetes (EKS, GKE, AKS)?**
Yes. Managed Kubernetes handles the control plane — it does NOT handle your workload architecture. Resource limits, security context, PDBs, probes, and NetworkPolicies are YOUR responsibility on every provider. The cloud provider manages etcd. You manage everything that runs on the nodes.