Multi-Cluster
Kubeconfig contexts, agent-connected clusters, and metrics-only clusters in one persistent registry.
Connection types
The cluster registry mixes three kinds of clusters:
- Kubeconfig contexts — auto-discovered from your kubeconfig at startup. The initial connection targets the current-context.
- Agent-connected clusters — added through the Add Cluster wizard; the agent dials outbound to KubeBolt, so no inbound network path or shared kubeconfig is needed. Remote exec, port-forward, and the file browser work over the same channel (see Remote Clusters).
- Metrics-only clusters — agent ships telemetry, no live channel. Ideal for clusters you only want on dashboards.
The registry is persistent: registered clusters survive restarts, and the UI badges each cluster with its connection type.
Renaming
Any cluster can be renamed from the UI (admin only). Display names are stored in the registry — the agent’s advertised name never overwrites a manual rename.
Switching
When switching clusters, the manager tears down the old connector (informers, metrics collector, insights engine) and creates a new one for the target. The permission probe runs again for the new cluster, and the frontend shows a “Connecting to cluster” overlay during the switch.
API
GET /api/v1/clusters → list registered clusters
POST /api/v1/clusters/switch → { "context": "production-eks" }
PUT /api/v1/clusters/{context}/rename → { "displayName": "prod-us-east" } (admin)
DELETE /api/v1/clusters/{context} → remove from the registry (admin)