Skip to content

Multi-Cluster Fleet

Fleet topology: KubeGlass hub connects to production, staging, and development clusters with health scores, showing cross-cluster operations like resource diff, RBAC compare, drift scanning, and config sync

The Fleet Dashboard probes every kubeconfig context in parallel. You get a single view of your entire infrastructure:

  • Per-cluster health probes - Pod/node scanning, status breakdown, overall health score
  • Connection diagnostics - Walk through DNS → TLS → auth → RBAC step by step to debug connectivity
  • Cross-cluster resource relationships - Dependency graphs spanning multiple clusters
  • Environment tagging - Mark clusters as production, staging, or development. Production clusters require confirmation before destructive actions

Compare resources across clusters side-by-side. Select a resource in one cluster and diff it against the same resource in another to find configuration drift.

Compare RBAC policies across clusters to identify permission inconsistencies.

Scan for configuration drift across all connected clusters. Concurrency is bounded to prevent overwhelming your API servers.

Replicate configurations from a source cluster to one or more target clusters. Supports dry-run preview before applying changes.

Terminal tabs are scoped to the cluster they were opened on and survive context switches. Color-coded so you always know where you are:

┌──────────────────────────────────────────────────────────────────┐
│ 🟢 prod/frontend-pod │ 🟠 stg/api-pod │ 🟠 stg/db-pod │ + │
└──────────────────────────────────────────────────────────────────┘

KubeGlass reads every context from your kubeconfig. To add a cluster:

  1. Add the context to your kubeconfig (kubectl config set-context ...)
  2. The cluster appears automatically in the Fleet Dashboard
  3. No restart required - context changes are picked up dynamically

Tag clusters with environment labels (production, staging, development) from the Fleet Dashboard. Production-tagged clusters require confirmation dialogs before destructive actions like delete, scale-to-zero, or drain.