KubeBolt docs
GitHub

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:

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 parks the current connector instead of tearing it down: its informers, metrics collector and insights engine keep running in the background, so switching back to a cluster you already opened is instant. A cluster you haven’t opened yet is connected on first use — the permission probe runs for it, and the frontend shows a “Connecting to cluster” overlay while it does.

Because parked clusters keep evaluating, insights and notifications cover every connected cluster, not only the one on screen. The Fleet page (/fleet) shows all of them at once.

API

Any API call can target a cluster other than the active one with the X-KubeBolt-Cluster: <context-name> header.

GET    /api/v1/clusters                      → list registered clusters
POST   /api/v1/clusters/switch               → { "context": "production-eks" }
POST   /api/v1/clusters                      → { "kubeconfig": "<yaml>" }         (admin)
PUT    /api/v1/clusters/{context}/rename     → { "displayName": "prod-us-east" }   (admin)
DELETE /api/v1/clusters/{context}            → remove an uploaded context          (admin)
DELETE /api/v1/clusters/by-id/{clusterId}    → remove an agent-connected cluster   (admin)