Skip to main content
Every platform component Celum installs on a supervisor — the CNI, cert-manager, the monitoring stack, Loki, ClickHouse, CAPI, KubeVirt, storage operators, and the rest — is tracked the same way: a status endpoint per component family that reports whether the component is installed, whether it is ready, which version is running, and why if it is not. Learn the model once and every health panel in the product reads the same. The onboarding wizard's full status view — stepper and per-component Installation Summary

​
The status model

Components are installed as Flux HelmReleases. Each component’s status endpoint returns a helmRelease block read straight from the release object on the supervisor: A healthy monitoring stack looks like this:
The reason and message are the diagnostic. When a release is not ready, the same block carries the chart controller’s explanation — a failed hook, a values error, an unreachable chart repository — verbatim. Every install panel in the UI renders it, so you rarely need kubectl to find out why a component is stuck.
Change the HelmRelease, never the object it rendered. Every ConfigMap, Deployment and DaemonSet a component owns is an output of its release, and Flux re-renders it from the release’s values on the next reconcile. A hand-patched ConfigMap therefore works until the reconcile, reverts without warning, and leaves no trace of why the fix stopped holding.The durable edit is spec.values on the HelmRelease — or, better, the step’s own Apply, which writes the same place and keeps Celum’s view of the desired configuration in step with the cluster’s.

​
Install → ready lifecycle

The onboarding wizard maps this lifecycle onto its step states: a step is locked until its dependencies are ready, ready when it can be installed, running while the HelmRelease exists but is not yet ready, and done once the release reports Ready. The same derivation drives the installation summary in the wizard sidebar, so the stepper reflects real cluster state on page load — not what you clicked last.

​
Where statuses surface

  • Onboarding wizard — each install step shows the component’s chart panel: available versions with the pinned default marked, the installed version, an automatic “Upgrade to X” action when the picked version differs, a re-apply button, and the release’s Ready condition with reason and message as the footer.
  • Day-2 panels — the supervisor’s Networking, Storage, Monitoring, Security, and Virtualization surfaces re-read the same status endpoints, so component state on a tab always matches what the wizard would show.
The in-product assistant, Celum AI, answers health questions from these same status APIs — asking “is monitoring healthy on this supervisor?” reads the identical data the panels render.

​
Release state is not the whole story

A green HelmRelease means the chart deployed. It does not mean the workloads are running, and it does not mean data is flowing. Triage in this order:
1

Release state

Is the HelmRelease ready? If not, read the Ready condition’s reason and message — this resolves most install and upgrade failures without leaving the UI.
2

Version drift

Does revision match the desired chart version? A lastAttemptedRevision ahead of revision means an upgrade is stuck — the conditions say why.
3

Runtime state

Are the component’s workloads actually up? Status endpoints report runtime signals beyond the release: DaemonSet readiness for collectors, ClickHouse instance state, discovered ServiceMonitors. A release can be Ready while a restrictive namespace policy leaves a DaemonSet at zero pods — see Logs for the classic case.
4

Data freshness

For telemetry components, check that data is arriving, not just that components are green. Empty flow dashboards with every component healthy almost always means stalled ingestion — Flow telemetry makes freshness the first check.

​
Component families

All actions are scoped to the supervisor, e.g. krn:celum:supervisor:<supervisor>:monitoring:* for the monitoring family, krn:celum:supervisor:<supervisor>:security:* for the security stack, and krn:celum:supervisor:<supervisor> for supervisor:GetSummary.
The last two rows used to be one. Splitting them is not tidiness: the security stack’s own status moved to security:Read in August 2026, so a policy granting supervisor:GetSummary reaches the Flux and cluster-agent status and stops there. Nothing reports that as a permission problem — the KRN simply does not match, and the panel comes back empty.
Networking engine health — BGP sessions, advertise drift, gateway conflicts — has its own dedicated surface; see the Networking overview.

Supervisor overview

The page a supervisor opens on: its tabs and its Helm releases.

Monitoring

The Prometheus stack — install state, ServiceMonitors, and opt-in exporters.

Logs

Loki and the Alloy collectors — release state vs runtime state.

Flow telemetry

ClickHouse, the flow pipeline, and freshness — the ingestion-first triage.

Infrastructure & nodes

Node boards — capacity, disks, NICs, GPUs, and power profiles.