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.