Skip to main content
What you’ll get: during an incident, ewake can inspect your cluster — list pods, read their status and events, pull (and --previous) container logs, and see deployment state — to root-cause failures like CrashLoopBackOff, OOMKilled, ImagePullBackOff, and unschedulable pods. Access is read-only.

​
How it works

You run a read-only Kubernetes MCP server inside your cluster and expose it over a tunnel of your choice. ewake connects to that endpoint — with whatever headers you specify — and reads pods, events, logs, and deployments on demand. ewake never needs inbound access: the tunnel dials out, so no ports are opened into your cluster. And it only ever reads — the server runs --read-only, bound to a read-only view role.

​
Configuration

1

Run a read-only MCP server in your cluster

Deploy the open-source kubernetes-mcp-server however you prefer — Helm, plain manifests, or an existing deployment. Two things matter:
  • Read-only server — start it with --read-only (optionally --toolsets core,config).
  • Read-only ServiceAccount — bind it to the built-in view ClusterRole, which excludes Secrets and all write verbs.
Don’t grant the server a write-capable role. The view ClusterRole is what keeps ewake read-only and blocks access to Secrets.
2

Expose it through a tunnel

Put the server behind an outbound tunnel so ewake can reach it without any inbound ports — for example Cloudflare Tunnel, ngrok, or any equivalent. Protect the public endpoint with whatever your tunnel offers (a Cloudflare Access service token, an ngrok auth header, etc.).Your endpoint URL is the public tunnel hostname plus the MCP path, e.g. https://k8s-mcp.yourcompany.com/mcp.
3

Connect it in ewake

In your dashboard, go to Integrations → Infrastructure → Kubernetes → Connect, then enter:Headers depend on how you protected the endpoint:
  • Cloudflare Access service token → two headers: CF-Access-Client-Id and CF-Access-Client-Secret.
  • Bearer / ngrok → e.g. Authorization: Bearer <token>.
  • No auth → leave it empty.
Connect to Kubernetes modal in ewake
4

Test and save

Click Test connection — ewake connects through the tunnel and lists the read-only tools to confirm the URL and headers work. Then click Save.
Kubernetes is connected. ewake can now read pods, events, logs, and deployment state during incidents.

​
Connect more than one cluster

Kubernetes is a multi-instance integration: connect as many clusters as you need, one at a time. Give each cluster a Cluster name that tells them apart in the dashboard, for example prod, staging-eu. Letters, digits, - or _, starting with a letter or digit, max 64 characters. Each cluster keeps its own MCP server URL and request headers. Disconnecting one leaves the others untouched. They’re listed under Connected clusters in the integration dialog, where you can add another with Connect a cluster or remove one on its own.

​
What ewake can and can’t do

Can (read-only)

List and describe pods, deployments, nodes, and events; read current and previous container logs; inspect non-secret config.

Can't (blocked)

Create, edit, delete, scale, or exec into anything. Read Secrets. Open any inbound port into your cluster.
ewake observes your cluster on demand during an investigation — it does not continuously watch or store cluster state.