Advanced Operations

Operating a fleet

When you manage several clusters, look at them together rather than one by one. kubeopera-api's federation API aggregates data across every registered cluster:

Endpoint	Returns
GET /api/v1/federation/overview	Health, nodes, usage and cost for every cluster.
GET /api/v1/federation/health	Health scores and issues, fleet-wide.
GET /api/v1/federation/cost	Cost by cluster, namespace and workload.
GET /api/v1/federation/anomalies	Recent anomalies across the fleet.
GET /api/v1/federation/optimizer	Right-sizing opportunities across the fleet.

The Multi-Cluster view is built on these endpoints, and to AI agents through the get_multi_cluster_overview tool.

Tips for fleets:

• Name clusters consistently (<env>-<region>) so sorting and filtering stay useful.
• Use the same environment structure for every cluster; let overlays capture the differences.
• Review the Multi-Cluster treemap weekly to spot clusters drifting in cost or usage.

Working with GitOps

Everything KubeOpera deploys — its own services and every tenant app — is delivered by Flux from Git. A few habits make this smooth:

• Change Git, not the cluster. A manual kubectl edit is reverted on the next reconcile. Change the dashboard or the repository instead.

• Expect a short delay. Changes apply on Flux's next reconcile (typically within a minute). For an immediate apply, reconcile explicitly:

  flux reconcile kustomization <name> --with-source

• Roll back with Git. Reverting a commit rolls the change back everywhere it applied. Apps also have one-click rollback in the dashboard, which does the same thing for you.

• Pause for maintenance. flux suspend kustomization <name> stops reconciliation while you investigate; flux resume starts it again.

To see how an app's configuration becomes resources in a tenant's vCluster, read app-controller.

Next steps

• Setup — how environments are structured.
• kubeopera-api — the full API.
• Clusters — add and manage clusters.