This example now lives at confighub/sveltos-confighub. This copy is a frozen mirror; new work, live recordings, and issues belong in that repository.
This is chapter four of the Sveltos fleet example, fleet patch day with evidence instead of hope. One reviewed chart version bump moves every cluster from Kyverno 3.8.1 to patch release 3.8.2, promoted pilot to staging to production, and the run closes with a coverage audit that proves no cluster was missed.
Sveltos selects the clusters and installs the add-on; ConfigHub holds the reviewed record, gates it, and publishes the approved revision as an OCI image that Sveltos fetches. The run pins Sveltos v1.13.0 and needs the addon controller build that decompresses gzipped layers, which the ConfigHub gateway serves. The source lock carries that pin and the chart provenance pin together.
Why this chapter exists
Patch day is the operation every platform team is judged on and few can evidence afterwards. The claim here is not that a new chart version reached the clusters. It is that the bytes that shipped hash to the digest someone reviewed, that no cluster took the bump before a named person approved that exact revision, and that the run can name every cluster it moved and show that the list is complete.
The boundary
This chapter proves governed delivery of a version bump. It does not scan for vulnerabilities and it does not verify any advisory claim. The candidate carries an operator-supplied advisory reference as context, and the pipeline treats it as text.
See the result
The matrix shows which cluster runs which chart version at four checkpoints: the baseline, then after each wave. No live run has been recorded on the gateway path yet, so every observed cell stays empty and no receipt is committed. The expected columns come from the reviewed example files, and the offline surfaces are verified in the repository gate.
How it works
The chapter reuses the reference fleet from chapter three, one management cluster and four workload clusters grouped as pilot, staging, and two production clusters, defined in the shared fleet design.
The baseline continues chapter three's story. Each environment keeps its own governed ClusterProfile at chart 3.8.1 carrying the values that chapter three promoted, and the repository gate enforces that continuity: if the chapter three outcome changes, this chapter's baseline must change with it.
The patch candidate is one reviewed version bump with digest-bound provenance, naming the from and to chart versions, their upstream digests from the chart repository index, and the artifact address. Before the runner stores any revision it downloads the patched chart and refuses to continue unless the bytes match the pinned digest.
Each environment's reviewed profile lives in its own ConfigHub Space with an approval gate. Approving a revision publishes it to the ConfigHub OCI gateway. One bootstrap profile per environment points Sveltos at that Space's gateway reference, and Sveltos fetches it and sends the reviewed profile to the clusters matching that environment label.
Promotion never touches the bootstrap profile. Publishing the approved release moves the tag, and the fleet follows on its interval.
The reviewed values must survive the bump on every cluster, which the observations check directly, and the final coverage audit requires every registered cluster at the patched version with none missing.
The matrix
The per-cluster matrix follows the Kubara matrix discipline: expected evidence comes from the reviewed files, observed evidence only ever comes from a live run, and empty cells stay empty until a run earns them.
Chapter five
The bulk operations example closes the brief: one reviewed change fans out to every environment record in one pass, and a zero-drift audit proves it everywhere, including a set-aware gate query across the Spaces and drift repaired on every cluster.
Repeat and verify
# Deterministic self-test of the matrix generator: fixture compile,
# continuity and candidate refusals, and the receipt-fill path.
npm run sveltos-cve-patch:self-test
# Deterministic self-test of the live runner: the gate preflight, the chart
# provenance and values-fit checks, all six approval brackets delivered
# through the gateway, and the coverage audit, against fake ConfigHub and
# management-cluster surfaces. A few seconds.
npm run sveltos-cve-patch-proof:self-testOne live question is already answerable today with no account or cluster: does the pinned patched chart still match its digest, and do the reviewed values survive a render of it? The check downloads the chart, hashes it against the pin, renders it with the reviewed values, and requires the four expected deployments with the reviewed replica counts.
npm run sveltos-cve-patch-proof:verify-chartConfirm the approval wiring before a live run. The probe wires one throwaway Space, creates one probe Unit, watches for the approval gate, and cleans up after itself:
CUB_CONTEXT=my-policy npm run sveltos-gate:probeThen record the run. One authenticated context is enough, because no cluster Spaces are created:
HELM_EXPT_ALLOW_LIVE_SVELTOS_CVE_PATCH=1 \
CUB_CONTEXT=my-policy \
SVELTOS_ADDON_CONTROLLER_IMAGE=docker.io/projectsveltos/addon-controller:v1.13.0-ch \
npm run sveltos-cve-patch-proof:run
# Then refresh the summary and the observed matrix columns.
npm run sveltos-cve-patch-proof:generate
npm run sveltos-cve-patch:generateFleet proofs run serially against the organization, never in parallel.