Clusters — Kubernetes with zero agent install

Connect a Kubernetes cluster directly via kubeconfig, or deploy a lightweight relay pod for private clusters — no VM agent required either way.

Already run Kubernetes? You don't need to install anything on a VM. Clusters is a second, independent way to connect infrastructure — sitting alongside Machines in the sidebar — built specifically for people who are reluctant to run an agent on their VMs but already trust kubectl against their cluster.

There are two ways to connect a cluster, for two different network situations.

Option 1 — Direct connect (kubeconfig upload)

Click + Connect cluster in the Clusters sidebar section, choose Upload kubeconfig, and paste or drop the file. InfraCanvas connects to your cluster's API server directly from the cloud backend — the same way kubectl does — with no pod deployed into your cluster at all.

This only works if your cluster's API server is reachable from the internet, and if your kubeconfig authenticates with a static token or client certificate — not an exec: auth plugin. Most managed Kubernetes (EKS, GKE, AKS) has an internet-reachable API server, but the kubeconfig aws eks update-kubeconfig / gcloud container clusters get-credentials / az aks get-credentials generate for you authenticates by executing the aws / gcloud / az CLI — and that CLI runs on InfraCanvas's own backend, not your machine. Unless you've separately arranged for that binary and its credentials to exist there, direct-connect will fail for that kubeconfig even though the file itself is valid. For a cluster provisioned by a cloud managed-Kubernetes service, use the relay pod below instead — it sidesteps this entirely by authenticating from inside your own cluster.

Your kubeconfig is encrypted at rest (AES-256-GCM) before it's stored, and only ever decrypted in memory to make the actual connection. It's never logged.

A kubeconfig with multiple contexts shows a picker so you connect exactly the cluster(s) you mean to — nothing is added silently. Add as many clusters as you like.

Option 2 — Relay pod (works for any cluster, including private/VPC-only)

Click + Connect cluster, choose Deploy relay pod, name the cluster, and you'll get a ready-to-apply Kubernetes manifest:

kubectl apply -f infracanvas-relay.yaml

This deploys a single pod inside your own cluster that connects outbound to InfraCanvas over the same protocol a VM agent uses — no inbound port on your side, and it authenticates using its own in-cluster ServiceAccount token, so there's no exec-auth problem and no dependency on your cluster's API server being internet-reachable. This is the right choice for private, VPC-only, or on-prem clusters, and it also works for any managed cluster if you'd rather not upload a kubeconfig at all.

The manifest's RBAC is scoped to exactly what InfraCanvas's Kubernetes actions use — read/watch on core and workload resources, plus the specific mutations (scale, restart, delete, exec) actions expose in the UI. It is not cluster-admin. Review the generated YAML before applying it, same as you would for any RBAC-bearing manifest from a third party.

Which one should I use?

	Direct connect	Relay pod
Install anything in the cluster?	No	Yes — one pod
Works for private/VPC-only clusters?	No	Yes
Works with `exec:`-auth kubeconfigs (EKS/GKE/AKS default)?	No	Yes
Kubeconfig ever leaves your machine?	Uploaded, encrypted at rest	Not needed at all

If you're unsure, relay pod is the safer default — it works everywhere and sidesteps the exec-auth limitation above. Reach for direct connect when your cluster's API server is internet-reachable and your kubeconfig already uses a static token or client certificate (for example, a cluster you provisioned yourself with kubeadm, or a service account token you generated on purpose).

Plan limits

Clusters draw from their own quota (max_clusters), separate from your VM count — connecting a cluster never uses up a VM slot and vice versa. See Plans & pricing.

What you can do once connected

Everything Machines support for Kubernetes resources: the live topology canvas, pod exec terminals, log streaming, and actions like scale, rollout restart, delete, and edit-YAML — identical whether the resource came from a VM-connected agent or a Clusters connection.

Disconnecting

Remove a cluster from its ••• menu on the Clusters page. For direct connect this deletes the stored (encrypted) kubeconfig and revokes its API key immediately. For a relay pod, this only removes it from your dashboard — also run kubectl delete -f infracanvas-relay.yaml in the cluster to actually stop and remove the pod.