Kubernetes integration
Sensitive work runs where you decide, on your own cluster.
The Kubernetes runner is an in-cluster service that registers with the dispatcher like any other runner and advertises its runtime. Each assigned run gets its own agent pod, each pipeline step gets its own step pod, and placement is a scope decision rather than an accident of where the process happened to start.
What it does
Kubernetes inside a governed run.
How Kubernetes participates once it is connected — and what the platform does with what it returns.
An agent pod per run
Each run is assigned an agent pod that owns the run workspace volume, mounted at a known path. Runs do not share a long-lived process, and workspace state belongs to the run rather than the host.
A step pod per step image
The agent creates one pod per pipeline step image, mounts the same workspace volume at the pipeline working directory, binds pipeline-declared volumes by name, and executes actions through the Kubernetes API.
One runner per namespace
Each runner has its own identity, scope list and capacity. A namespace runner can be dedicated to production, a region, a team or a workload class, and routing decisions stay in the dispatcher.
Logs follow the pod
The runner follows the agent pod log stream and forwards batches to the dispatcher, reattaching from the last observed timestamp if the stream closes early and performing a final read once the pod is terminal.
How it stays governed
The controls that make it safe to leave connected.
An integration is easy to add and hard to bound. These are the parts that decide whether it stays reviewable six months later.
Placement is selected, not assumed
Eligible runners are chosen by scope, affinity, capacity and state. Work that must not leave a boundary is routed to runners inside it, and the routing map is GitOps-owned configuration.
Runner identity is owned by the installation
Generated resource names carry a runner identity plus a stable platform ownership ID. Reusing a runner name from a different platform creates separate resources instead of patching a runner another platform owns.
Registration is revocable
Removing a runner clears its registration and disconnects live streams while leaving the ID reusable. IDs that must stay revoked are ejected explicitly, and revocations can be cleared deliberately before reinstalling.
RBAC is explicit
Generated manifests include the log permissions the runner needs. Custom manifests that drop them will complete runs but deliver incomplete logs — which is exactly the kind of quiet evidence gap worth knowing about in advance.
In context
Workflows where Kubernetes shows up.
The same integration, seen from the workflow rather than from the connection.
A customer-reported bug needs to ship as a hotfix
The fix is small, but no single durable trail connects the complaint, the code change, the test result and the emergency approval.
Production incident at 2 a.m.
At 2 a.m. the hard part is finding what changed and deciding whether rollback is safe — fast, without losing the evidence trail.
A security vulnerability scan flags an issue
One vulnerability can span many repos and teams. Manual discovery is slow, incomplete and easy to miss under SLA pressure.
Common questions
What teams ask about Kubernetes.
Does our data leave the cluster?
The platform is self-hosted, and the Kubernetes runner executes inside your namespace on your infrastructure. What leaves depends entirely on which model providers and external tools you approve — which is itself governed configuration rather than an implicit default.
Can we run Docker runners and Kubernetes runners together?
Yes. Both register with the same dispatcher and the same pipeline, step, secret, variable, model, tool and log flows apply. Scope routing decides which runs land where.
How do we isolate production work?
Run a dedicated runner in the production namespace with its own scope list, and route production-scoped work to it. Because placement is a dispatch decision rather than a pipeline detail, the isolation holds without every pipeline author having to remember it.
Related
Other integrations
Map your Kubernetes workflow end to end.
Bring one real workflow. We will map its trigger, tools, approvals, runtime boundary and evidence requirements with you.