Kubernetes
backend_type: kubernetes. Connection: Kubernetes. Status: production — carries live fleets today, including agent pools.
Each execution is a Pod in a namespace you name. The cluster can be EKS, AKS, GKE, Magalu, or your own. The Kubernetes connection is cloud-agnostic; this kind does not care who owns the control plane.
When to choose it
- You already run a cluster and want runners as pods, not extra VMs.
- Agent sessions that should share cluster identity, NetworkPolicy, and resource quotas with the rest of your workloads.
- Multi-cloud orgs that want one runner kind everywhere a kubeconfig works.
Connection
A Kubernetes connection (service account / kubeconfig). Namespace-scoped RBAC is enough if the group's namespace is the only place pods land. cluster-admin is almost never required.
Required config
| Key | Type | Meaning |
|---|---|---|
namespace | string | Namespace runner pods land in (e.g. ltinteg-runners). |
Optional knobs
service_account (defaults to default), container_image (platform default when omitted). Size the pod requests so a small cluster cannot pending-storm.
Execution control
Suffixed workflows: runner.execution-{stop,sync,logs-sync}-kubernetes. There is no restart. The pod is replaced, not restarted. Launch variants include runner.execution-launch-kubernetes and runner.execution-launch-kubernetes-agent.
eks is not a second kind
backend_type=eks is a reserved / legacy database label. New groups use kubernetes even when the cluster is EKS. Point the Kubernetes connection at that cluster (or pair with aws.eks.* for control-plane lifecycle). Do not create new eks groups.
Purposes
Production agent fleets run on this kind with purpose=agent. CI groups use GitHub/GitLab integration as on any other backend. See Purposes.