> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Whiteboarding MCP Design

> Designing a Managed Control Plane connecting an LLM to Kubernetes to enable secure tool calls and API-driven cluster operations

Hello and welcome back.

In this lesson we revisit the architectural diagram we've been building and focus on the right-hand region: the MCP (Managed Control Plane) layer. The left side of the architecture (services, cluster components) is essentially fixed; our work concentrates on how the MCP connects to Kubernetes and, ultimately, to an LLM that will accept user prompts and perform Kubernetes queries.

## What we built so far

* An MCP layer running Supergateway that authenticates using a local `kubeconfig` for testing.
* The MCP is packaged and executed via `Docker`.
* Basic connectivity validated: the MCP can reach the Kubernetes API and return data (we used `curl` as a quick verification method).

## Current interaction pattern

* Today, the MCP communicates directly with Kubernetes using raw HTTP calls (e.g., `curl`) to query cluster resources.
* This pattern is suitable for smoke tests, but it is not the final user-facing workflow.

Example curl-based verification (used during testing):

```bash theme={null}
# Example: query the Kubernetes API server for pods in the default namespace
curl --cacert /path/to/ca.crt \
  --header "Authorization: Bearer $(cat /path/to/token)" \
  https://<KUBERNETES_API_SERVER>/api/v1/namespaces/default/pods
```

## Planned (target) interaction and end-to-end flow

We will introduce an LLM layer that receives user prompts and orchestrates Kubernetes operations via an MCP client. The target flow:

1. A user sends a natural language prompt to the LLM.
2. The LLM decides to call an external tool — the MCP client — to perform specific Kubernetes API calls (for example, read labels, list pods, or inspect resources).
3. The MCP client performs the API requests against the Kubernetes cluster and returns structured results.
4. The LLM consumes the results, formats a final response, and returns it to the user.

A simplified pseudocode example of the LLM-to-MCP tool call:

```python theme={null}
# Pseudocode illustrating the LLM invoking an MCP tool
tool_response = mcp_client.call(
    action="read_labels",
    namespace="default",
    resource="pods",
    name="my-app-pod"
)
# LLM processes `tool_response` and generates user-facing text
```

## Diagram notes

* The prompt flow goes: User → LLM → MCP → Kubernetes API.
* Responses travel back along the same path: Kubernetes → MCP → LLM → User.
* Arrows between LLM and MCP, and between MCP and Kubernetes, are bidirectional in the diagram to emphasize request/response semantics.
* MCP-specific arrows are visually distinguished to clarify which communication paths are handled by the MCP layer versus standard Kubernetes traffic.

![A screenshots of a diagrams.net/draw.io workspace showing a system architecture diagram with a Kubernetes icon and service boxes (payment, search, kube-system) connected by arrows to components labeled MCP - K8, LLM, and Prompt. The editor's shape palette and style/options panels are visible along the left and right.](https://mintcdn.com/kodekloud-c4ac6d9a/rjGeTDj8cr6D5YbW/images/Building-Kubernetes-FinOps-AI-Agent/MCP-Gateway-for-Kubernetes/Demo-Whiteboarding-MCP-Design/drawio-k8-architecture-llm-prompt-services.jpg?fit=max\&auto=format\&n=rjGeTDj8cr6D5YbW\&q=85\&s=a064858c1e2dc353394f0228bdcf97a3)

## Components at a glance

| Component | Role | Example / Notes |
| - | -: | - |
| MCP (Managed Control Plane) | Mediates LLM tool calls to Kubernetes | Runs Supergateway in Docker; currently uses local `kubeconfig` for tests |
| LLM | Receives user prompts, issues tool calls | Should call MCP as an external tool for privileged ops |
| Kubernetes API | Source of truth for cluster resources | Accessed by MCP client via authenticated API calls |
| Test tooling | Smoke-test connectivity | `curl` used during early verification |

## Next steps (high level)

* Implement the LLM-to-MCP tool interface so prompts can trigger Kubernetes operations via the MCP client.
* Replace brittle `kubeconfig`-based local testing with secure credential handling (short-lived tokens, service accounts, or a secrets manager).
* Replace `curl`-based tests with full LLM-driven flows and end-to-end integration tests.

Note: For production, avoid storing or distributing plain `kubeconfig` files. Use secure secret management, least-privilege service accounts, and short-lived credentials for the MCP to access the Kubernetes API.

That’s it for this lesson — see you in the next one.

## Links and references

* [Kubernetes Basics](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
* [Kubernetes Authentication and Authorization](https://kubernetes.io/docs/reference/access-authn-authz/)
* Consider LLM tool-call patterns (e.g., OpenAI tool calling / custom tool integration approaches) when designing the MCP-to-LLM interface.

> **[Watch Video](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/195615db-9bd2-4d1d-b899-9bd378d97521/lesson/da35f334-59bd-4e73-a88a-c338f012884e)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.