Day-2 operations

Once a cluster is running, its detail page (/s/<supervisor>/clusters/<cluster>) is built entirely from read-only calls through the tenant’s own kubeconfig, which Celum already holds on the supervisor. All of these live under /api/clusters/<cluster>/... and take ?supervisor= and ?namespace= query parameters to disambiguate which supervisor hosts the cluster and which namespace its Cluster API objects live in.

<supervisor> and <cluster> are placeholders throughout, and payload excerpts are trimmed — real responses carry more rows and fields.

Nodes and events

GET /api/clusters/<cluster>/nodes lists the cluster’s machines — the Cluster API view of its nodes, with phases and versions. It pairs with the events feed, GET /api/clusters/<cluster>/events, which is the first stop for “why is something failing in this tenant”:

[
  { "type": "Warning", "reason": "BackOff",
    "message": "Back-off restarting failed container frontend-check in pod loadgenerator-5f47d56dcb-zddlc_default(...)",
    "count": 895, "lastTime": "2026-08-16T12:32:12Z",
    "objectKind": "Pod", "objectName": "loadgenerator-5f47d56dcb-zddlc" },
  { "type": "Normal", "reason": "Pulled",
    "message": "Successfully pulled image \"busybox:latest\" in 3.027s (3.027s including waiting).",
    "count": 1, "objectKind": "Pod", "objectName": "loadgenerator-5f47d56dcb-zddlc" }
]

Events carry the tenant’s own reasons and messages verbatim — Celum adds nothing, so what you see is what kubectl get events would show.

Metrics — and the `available: false` case

GET /api/clusters/<cluster>/metrics aggregates CPU, memory, storage, pod counts, per-node stats, and top namespaces. When the tenant has no metrics source installed (no metrics-server or monitoring agent), the endpoint does not error — it returns this, and it is the expected response, not a failure:

{
  "available": false,
  "source": "",
  "cpu": { "used": 0, "total": 0, "percent": 0 },
  "memory": { "used": 0, "total": 0, "percent": 0 },
  "pods": { "running": 0, "capacity": 0 }
}

Enable the monitoring addon on the cluster (or install metrics-server in the tenant) and the same endpoint starts returning live numbers with available: true.

Helm releases

This section is about tenant clusters. A supervisor’s own releases have their own panel, on its Overview under Summary, which refuses to uninstall the platform’s releases. See Helm releases on the supervisor overview.

Tenants have no Flux. Celum reads a tenant’s releases with Helm, through the tenant kubeconfig, and writes them through Cluster API add-ons (CAAPH) on the supervisor:

Install creates a HelmChartProxy for the cluster, unless the request asks for imperative, which installs with Helm directly.
Upgrade and Uninstall re-apply or delete the release’s HelmChartProxy when one manages it, and fall back to Helm for a release installed directly.

GET /api/clusters/<cluster>/helm-releases is the app inventory:

[
  { "name": "cert-manager", "namespace": "cert-manager", "chart": "cert-manager",
    "chartVersion": "v1.20.2", "appVersion": "v1.20.2", "status": "deployed", "revision": 2 },
  { "name": "cilium", "namespace": "kube-system", "chart": "cilium",
    "chartVersion": "1.19.4", "appVersion": "1.19.4", "status": "deployed", "revision": 1 },
  { "name": "prometheus-agent", "namespace": "monitoring", "chart": "prometheus",
    "chartVersion": "29.24.0", "appVersion": "v3.13.2", "status": "deployed", "revision": 12 }
]

The write side mirrors the Helm CLI:

Task	Endpoint
Install a release	`POST /api/clusters/<cluster>/helm-releases`
Upgrade a release	`PUT /api/clusters/<cluster>/helm-releases/<release>`
Poll a running upgrade	`GET .../helm-releases/<release>/upgrade-status/<jobID>`
Read a release’s values	`GET .../helm-releases/<release>/values`
Uninstall	`DELETE .../helm-releases/<release>`

Upgrades run asynchronously — the PUT returns a job ID and the status endpoint reports progress until the Helm operation completes.

The cluster detail page with its Helm Releases panel expanded — chart, version, status, revision and last update per release

Exposure — LoadBalancers and ingresses

Two endpoints answer “how is this cluster reachable from outside”. GET /api/clusters/<cluster>/lb-services lists its LoadBalancer Services with the external IPs the supervisor’s pools assigned:

[
  { "name": "demo-cl-lb", "namespace": "proj-demo", "externalIp": "203.0.113.10",
    "ports": "6443/TCP", "age": "44d" }
]

GET /api/clusters/<cluster>/ingresses lists the HTTP surface — Ingress objects with hosts and TLS state:

[
  { "name": "api-ingress", "namespace": "portal", "hosts": ["api.demo-cl.example.com"], "tls": true, "age": "25d" },
  { "name": "admin-ingress", "namespace": "portal", "hosts": ["admin.demo-cl.example.com"], "tls": true, "age": "25d" }
]

Tenants can also run their own Gateway API stack: /api/clusters/<cluster>/gateway/... installs Envoy Gateway inside the guest and manages its gateways and routes. Publishing through the supervisor’s shared gateway instead is covered in Gateways & routes.

Workloads — namespaces, pods, logs

The workloads drill-down goes namespace → pod list → pod detail, all inside the tenant:

Level	Endpoint
Namespaces	`GET /api/clusters/<cluster>/workload-namespaces`
Pods in one namespace	`GET /api/clusters/<cluster>/workload-pods?podNamespace=<ns>`
One pod’s detail	`GET /api/clusters/<cluster>/workload-pod?podNamespace=<ns>&podName=<pod>`
One pod’s events	`GET /api/clusters/<cluster>/workload-pod-events?podNamespace=<ns>&podName=<pod>`
One pod’s logs	`GET /api/clusters/<cluster>/workload-pod-logs?podNamespace=<ns>&podName=<pod>`

The pod list is where trouble shows first — status, readiness, and restart counts per pod:

[
  { "name": "cilium-operator-7487789fb9-5bnfq", "namespace": "kube-system",
    "node": "demo-cl-md0-d5kp8-b4q46-pmdd4", "status": "Running", "ready": "1/1", "restarts": 3 },
  { "name": "hubble-relay-758b8867dd-9m5zx", "namespace": "kube-system",
    "node": "demo-cl-md0-d5kp8-b4q46-527pn", "status": "CrashLoopBackOff", "ready": "0/1", "restarts": 1205 }
]

Log reads accept container and tailLines parameters, defaulting to the first container and the trailing 200 lines.

The kubectl-get escape hatch

When the curated views don’t cover a resource, GET /api/clusters/<cluster>/kubectl-get is a generic, read-only kubectl get against the tenant: any kind — core resources or CRDs — listed or fetched as full YAML with resourceName, scoped with resourceNamespace or allNamespaces=true. It never mutates, and Secret values are redacted. Everything it serves is subject to the same permission (cluster:GetResources) and lands in the audit log like every other call.

Permissions

Task	Action
List clusters / fleet health	`cluster:List` / `cluster:GetHealth`
Read nodes	`cluster:GetNodes`
Read events	`cluster:GetEvents`
Read metrics, namespaces, pods, logs	`cluster:GetWorkloads`
kubectl-get	`cluster:GetResources`
Read LB Services / ingresses	`cluster:GetLBServices` / `cluster:GetIngresses`
List releases / read values	`helm-release:List` / `helm-release:GetValues`
Install / upgrade / uninstall releases	`helm-release:Install` / `helm-release:Upgrade` / `helm-release:Uninstall`

Celum AI works these same views — get_cluster_events, list_cluster_workload_pods, and get_cluster_pod_logs let it answer “why is this pod crashing?” from the identical data, and get_cluster_exposure covers the LB/ingress side.

Troubleshooting

The triage order that strings these reads together.

Access & credentials

Kubeconfig, talosconfig, and SSH — when you do need direct access.

Get Started

Concepts

Clusters

GitOps & Apps

Virtual machines

Networking

Security

Platform Health

Storage

Reference

Administration

Day-2 operations

Nodes and events

Metrics — and the `available: false` case

Helm releases

Exposure — LoadBalancers and ingresses

Workloads — namespaces, pods, logs

The kubectl-get escape hatch

Permissions

Troubleshooting

Access & credentials

​Nodes and events

​Metrics — and the available: false case

​Helm releases

​Exposure — LoadBalancers and ingresses

​Workloads — namespaces, pods, logs

​The kubectl-get escape hatch

​Permissions

​Related

Troubleshooting

Access & credentials

Nodes and events

Metrics — and the `available: false` case

Helm releases

Exposure — LoadBalancers and ingresses

Workloads — namespaces, pods, logs

The kubectl-get escape hatch

Permissions

Related