Connecting Clusters — KubeBolt Docs

KubeBolt supports three connection types, and you can mix them freely across your fleet. The Add Cluster wizard in the UI walks through the options and prints the final helm command with everything you selected.

Connection types

Type	How it works	What you get
Kubeconfig	KubeBolt reads a context from your kubeconfig	Live resources, actions, insights, Metrics Server data. Zero install in the cluster.
Agent	A lightweight agent runs in the cluster and connects outbound to KubeBolt over gRPC	Everything above, plus historical metrics, network flows (Hubble), remote exec / port-forward / file browser, and optional cost data
Metrics-only	The agent ships metrics but keeps no live channel	Dashboards and history for clusters you only want telemetry from

Connected clusters are stored in a persistent registry — they survive restarts, and any cluster can be renamed from the UI (admin only).

Installing the agent

The agent installs from the OCI Helm registry:

helm install kubebolt-agent \
  oci://ghcr.io/clm-cloud-solutions/kubebolt/helm/kubebolt-agent \
  --namespace kubebolt --create-namespace \
  --set backendUrl=<your-kubebolt-url> \
  --set auth.token=<token-from-the-wizard>

Use the wizard-generated command instead of writing this by hand — it embeds the ingest token, the cluster name, and every option you toggled.

Metrics sources

The wizard exposes the agent’s metrics topology with progressive disclosure:

Built-in collectors (default) — kubelet stats and node signals collected by the agent DaemonSet.
Scrape sidecar (scrape.enabled=true) — a bundled vmagent scrapes Prometheus targets in the cluster and ships samples to KubeBolt, with defensive cardinality caps.
Read your existing Prometheus (agent.promRead.enabled=true) — instead of scraping, the agent queries your Prometheus’s query_range API. This is the path for managed Prometheus: Amazon Managed Prometheus, Google Managed Prometheus, and Azure Monitor, with per-provider auth (none, basicAuth, bearer, awsSigV4 via IRSA, gcpIam via Workload Identity, azureWorkloadIdentity).

scrape.enabled and agent.promRead.enabled are mutually exclusive — one agent has one canonical source of samples. The chart fails at helm template if both are on.

Advanced options surfaced by the wizard: mTLS (CA + client Secrets), ServiceAccount annotations (IRSA / Workload Identity), tolerations, GOMEMLIMIT override, and free-form extraEnv.

Cost data (optional)

To light up the Cost tab, give the agent OpenCost data using any of the three modes described in the cost documentation — including a bundled OpenCost sub-chart (opencost.enabled=true) if you don’t already run it.

Upgrading

The agent versions independently from the backend (its own 1.x line, same metric schema). Upgrade with helm upgrade — avoid --reuse-values so new chart defaults apply.