Kubernetes · mum-1a
Your cluster, all the way down.
We provision a versioned, single-tenant control plane — one node or three — on
dedicated VMs inside your org. They show up in exc compute list like any
other instance, and the kubeconfig we hand you is the admin one. No hidden management
layer, no neutered RBAC, no black box humming somewhere you can't see.
$ exc k8s cluster create \
--control_plane_image_id 1 \
--control_plane_instance_type m1a.large \
--subnet_id 1 \
--ssh_pubkey my-key
✓ cluster 7 provisioning
$ exc k8s cluster kubeconfig merge --cluster_id 7
✓ admin context merged into ~/.kube/config
$ █Division of labor
Managed where it's boring. Yours where it matters.
The control plane, the default CNI/CSI/CCM, and the per-cluster OIDC issuer arrive working. Everything above that line — workloads, ingress, observability, when to patch worker images — is genuinely yours, because you hold the admin kubeconfig, not a scoped-down imitation of one.
Kubernetes docs| Layer | Detail | Owner |
|---|---|---|
| Control plane | versioned, single-tenant — one node or three, on dedicated VMs in your org | managed |
| CNI · CSI · CCM | pre-installed and tested defaults; replace them if you disagree | managed |
| OIDC issuer | per-cluster, so pods can mint identity tokens — AWS-style workload identity | managed |
| Worker nodes | ordinary compute instances, any instance type, added and removed via CLI | yours |
| Extra add-ons | ingress controller, cert-manager, observability — install what you like | yours |
| Workloads · RBAC | namespaces, policies, deployments — the admin kubeconfig is in your hands | yours |
| Worker OS patching | we publish the images; you pick when to roll them | yours |
No black box
What "your cluster" actually means here.
The admin kubeconfig
Full cluster privileges, fetched with
exc k8s cluster kubeconfig get --cluster_id 7 -o ~/.kube/excloud.yaml or
merged straight into your config. CRDs, admission webhooks, kube-system — nothing is
fenced off.
Control plane you can point at
One or three dedicated control-plane VMs, single-tenant, living in your org and
listed by exc compute list. If you can see it, you can reason about it.
Workers are just VMs
Any instance type — the m1a family runs on dedicated AMD EPYC. Add one with
exc k8s cluster worker create, drop one with
exc k8s cluster worker delete. No node-pool abstraction between you and
the machines.
Workload identity, built in
Every cluster gets its own OIDC issuer, so pods can mint identity tokens AWS-style — no long-lived credentials baked into images. How it works.
$ exc k8s cluster worker create \
--cluster_id 7 \
--worker_name worker-1 \
--worker_image_id 1 \
--worker_instance_type m1a.xlarge \
--subnet_id 1 \
--ssh_pubkey my-key
✓ worker-1 joining cluster 7
# exc k8s cluster worker list · worker delete
# exc k8s cluster list · cluster deleteScaling
Add a node like you'd add a VM.
Because that's what it is. Workers join with one command and leave with one command;
the whole lifecycle — cluster create, worker create,
worker delete, cluster delete — fits in your shell history.
Billing
There is no Kubernetes line item.
The cluster runs on regular compute instances at published compute rates — control plane and workers alike. A one-node control plane on m1a.large meters like any other m1a.large. The full instance card is on the compute pricing page.
| Instance | Spec | Rate |
|---|---|---|
| m1a.large | 2 vCPU · 8 GiB · dedicated | ₹1.889/hr |
The honest part
Upgrades are re-creates, for now.
The Kubernetes version is set by control_plane_image_id and
worker_image_id at create time — exc compute image list shows
what's available. In-place upgrades (rolling control plane, worker drain) are on the
roadmap; today you upgrade by creating a cluster from newer image IDs and moving
workloads over. Also: one region, Mumbai (mum-1a). We'd rather tell you here than have
you find out in a runbook.
kubectl by midnight.
One command for the control plane, one to merge the kubeconfig, one per worker. The rest is your problem — which is exactly the point.