What this integration enables
- Pod inspection — agents read pod status, restart counts, resource utilization, and readiness state for affected services
- Deployment state — agents check current replica counts, rollout status, and recent rollout history
- Cluster events — agents query Kubernetes events correlated with incident timing to surface scheduling failures, OOM kills, and node pressure
- Container logs — agents retrieve container logs from affected pods for the incident time window
- Remediation actions — with explicit HITL approval, the resolution specialist can restart deployments, adjust replica counts, or patch a workload’s spec. These are gated by Human-in-the-Loop by default. The only carve-outs that gate a batch unconditionally, regardless of control mode or org settings, are a P1/P2-severity incident and a recommendation that opens a GitOps fix PR — a remediation action doesn’t carry a separate “always gates” rule of its own. If your org has enabled auto-approve in Self-Driving mode, remediation on a P3/P4 incident can be approved and executed automatically with no additional risk check. See HITL Gates for the full rule set.
Prerequisites
- An environment selected in the top-right context switcher — Settings → Environment → Integrations is scoped to that environment and stays disabled until one is selected
- A Kubernetes cluster
- The
k8s-mcpserver running inside your cluster or accessible from sureops with an appropriate kubeconfig or service account token
Integration connections are per-environment. Connecting Kubernetes here only applies to the environment that was selected in the context switcher at the time — it does not carry over to your other environments. Repeat this connect flow for each environment that needs Kubernetes.
Setup
1
Stand up k8s-mcp
Deploy
k8s-mcp inside your cluster (recommended) or on infrastructure with access to your cluster’s API server. If you’re using the sureops demo environment, k8s-mcp is already provisioned in-cluster — you can skip this step.For your own cluster, sureops runs kubernetes-mcp-server — deploy it as a Kubernetes Deployment with a scoped ServiceAccount bound to a Role (see Scoping k8s-mcp permissions below), and expose it inside your cluster or wherever sureops can reach it. The service account needs read access to pods, deployments, events, and logs, plus update/patch on Deployments/ReplicaSets/StatefulSets/DaemonSets, and the scale subresource specifically for Deployments and StatefulSets, for remediation — never delete on pods or exec.2
Connect in sureops
In sureops, go to Settings → Environment → Integrations and click Connect next to Kubernetes.Fill in:
- MCP Server Endpoint — the URL of your running
k8s-mcpserver (e.g.https://k8s-mcp.internal.company.com/mcp) - Authentication Method — Bearer Token, API Key, or Basic Auth, matching how your
k8s-mcpdeployment expects inbound requests to be authenticated - Token — labeled Bearer Token, API Key, or Password depending on the method you selected above
Required credentials
Scoping k8s-mcp permissions
The level of access you grantk8s-mcp determines what sureops agents can do. Every real remediation mutates a pod spec through its owning controller (Deployment, StatefulSet, etc.) — never a pod directly:
Grant only the permissions you want sureops to have. The read-only rows (the first five) are sufficient for diagnosis-only use; resolution actions need the
update/patch rows as well. Also grant read access (get/list/watch on configmaps) to any ConfigMaps your services need for diagnosis — scope this to the specific names your workloads use rather than a blanket grant.
Deliberately never granted, at any tier: create/delete on any workload resource, and pods/exec. Granting these would make shell-access-equivalent or delete-live actions possible with no review gate — sureops’ remediation model works entirely through patching an existing controller’s spec, so these verbs are never required and are excluded by design, not by oversight.