Kubernetes

The kubernetes.* family (~80 workflows) is cloud-agnostic: it operates any conformant cluster — EKS, AKS, GKE, Magalu, or your own — covering deployments, statefulsets, jobs and cronjobs, services and ingress, configmaps and secrets, namespaces, RBAC (roles, bindings, service accounts), PVCs, nodes, pods, and raw manifests. It's the layer the deploy.k8s.* surfaces and cluster drift reconciliation build on.

What the grant is

A Kubernetes connection is a cluster credential: a service account (or kubeconfig context) in your cluster with RBAC bindings you control. Orkestia acts inside the cluster as that identity — namespace-scoped if you bind namespace roles, cluster-wide only if you grant cluster roles. Deleting the service account or its bindings severs access.

Setting it up

1. Read the prerequisites for the workflows you need (kubernetes.deployment.*, kubernetes.manifest.*, …) via get_workflow_prerequisites or the dashboard flow.
2. In your cluster: create a dedicated service account and bind only the roles the guide lists — prefer namespace Roles over ClusterRoles wherever your workloads allow it.
3. Create the org-scoped connection; validation performs a read-only check against the API server.

What people run on it

• App operations — deployments, rollouts, jobs, config, secrets, across any cloud's cluster.
• Cluster reconciliation — the desired-vs-actual drift detection loops for runner and app infrastructure.
• Runner capacity — Kubernetes-hosted runners live behind this connection.
• Managed-cluster lifecycle — pair with the provider family that owns the control plane (azure.aks.*, gcp.gke.*, mgc.kubernetes.*, aws.eks.*) for create/scale/upgrade.

Browse the full family at reference.orkestia.dev/kubernetes.