Sveltos Kyverno fleet · ConfigHub Workshop

Generated at: 2026-10-06T13:45:42.258Z UTC · source: committed helm-expt evidence for this rendered repository document.

What it is. Sveltos ClusterProfile kyverno-fleet v1.12.0, as 1 Kubernetes object.

Install it. Apply it on a Sveltos management cluster. The five steps below give the commands.

Needs first. A Sveltos management cluster, and the clusters it selects.

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 example shows how ConfigHub and Sveltos can divide the work of managing a platform component across a cluster fleet.

ConfigHub stores the reviewed configuration, its variants, policy checks, and promotion history. Sveltos runs on a management cluster, selects workload clusters by label, and installs the declared add-on. Teams can change the configuration once in ConfigHub instead of running an upgrade command against each cluster.

This Space requires approval before apply because it changes cluster-wide admission policy, even though this example targets staging.

What to inspect

Open the clusterprofile Unit first. It contains the Sveltos ClusterProfile used by the live demo Space:

select clusters labeled environment=staging;
install Kyverno chart version 3.8.1;
run three admission-controller replicas;
keep the cluster aligned with ContinuousWithDriftDetection.

The chart version and values are fixed in the reviewed object. The separate clusterprofile-pilot.yaml file adds rollout=pilot. The two-wave proof starts with that narrower selector, then removes only the rollout label after review.

What the live tests showed

The test used Sveltos v1.12.0 with separate kind management and workload clusters. ConfigHub stored the ClusterProfile under the catalog's standard checks. The exact object exported from ConfigHub was applied to the management cluster.

In the first run, Sveltos selected the staging workload cluster, installed Kyverno 3.8.1, and reported the Helm feature as Provisioned. All four Kyverno deployments became available. The test then changed the admission-controller replica count from three to one on the workload cluster. Sveltos restored it to three.

The current OCI delivery run used two workload clusters. ConfigHub blocked the pilot profile until its exact revision was approved. It published the approved profile as a private release and as a temporary portable OCI. Argo CD reconciled that OCI digest on the management cluster. Sveltos installed Kyverno on the pilot and left the second cluster unchanged.

The next ConfigHub revision removed only spec.clusterSelector.matchLabels.rollout. That revision was also blocked until approval and published at a different OCI digest. Sveltos then kept the pilot healthy and installed Kyverno on the second staging cluster. The test changed the replica count on both clusters, and Sveltos restored both.

What remains

The current run installed Sveltos directly from a pinned upstream manifest and used a temporary registry for the portable OCI. It used two local kind clusters. A permanent package, a larger fleet, and a rollout that pauses after a failed target still need their own tests.

Chapter three

The environment rollout example starts the next chapter: one reviewed values change promoted from pilot to staging to production, with a per-cluster matrix that shows exactly which cluster runs which revision at each checkpoint.

Repeat and verify

The website guide explains the commands and results. The source profile, pilot profile, source lock, and live receipt record the first result. The OCI delivery summary and OCI delivery receipt record the automated handoff.

How to run the live proof

Run the offline self-tests first. They drive the same approval bracket, portable OCI round trip, and receipt checks against fake ConfigHub and OCI surfaces. They need no account, cluster, or network access and finish in seconds.

npm run sveltos-example:self-test
npm run sveltos-oci-delivery:self-test

The two-wave delivery proof is fully self-contained: it creates its own kind management cluster, two workload clusters, and a local OCI registry, records the receipt, and cleans up. The fleet build takes five to seven minutes.

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

# 1. Two authenticated contexts, deliberately separate: the maintained
#    policy organization that owns the reviewed profile, and a scratch
#    organization for the throwaway cluster Spaces. A browser round trip
#    each, well under a minute.
cub --context my-policy auth login     # choose the catalog organization
cub --context my-scratch auth login    # choose a scratch organization

# 2. Explicit consent plus both contexts, then one command. The fleet
#    builds in five to seven minutes (registry, management cluster, two
#    workload clusters, Sveltos converged); the two delivery waves add a
#    few minutes more.
HELM_EXPT_ALLOW_LIVE_SVELTOS_OCI_PROOF=1 \
HELM_EXPT_ALLOW_SCRATCH_ORG=1 \
CUB_CONTEXT=my-policy \
SVELTOS_CLUSTER_CONTEXT=my-scratch \
npm run sveltos-oci-delivery:run

# 3. Verify the recorded receipt offline, no live access needed.
#    A few seconds.
npm run sveltos-oci-delivery:verify

The recorded run used the maintainers' catalog organization, named helm-catalog, because it owns the approval policy space and trigger filter the runner checks for. To run this in your own organization, create that wiring first from the committed policy; the runner verifies its preconditions and stops early with a named reason instead of failing after the fleet build.

The approval gate attaches about a second after a Unit is created. npm run sveltos-gate:probe confirms that in your own organization before a run, and refuses in seconds if the wiring is wrong instead of failing after the fleet build. When cleaning up scratch Spaces by hand, delete each management Space before its -argo-apps sibling, or the Target is stranded by a dangling reference (confighubai/confighub#4980).

Use this entry in ConfigHub

Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.

Steps 1 and 2 need no account.

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

sveltos is v1.12.0
chart is kyverno/kyverno
version is 3.8.1
clusterSelector is environment=staging
syncMode is ContinuousWithDriftDetection
admissionController.replicas is 3

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

Kubernetes v1.35.0 with Sveltos v1.12.0 Checked in a live run.
SveltosCluster labeled environment=staging Checked in a live run.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

Once the destination is known. The current receipt records two approved ConfigHub revisions, two portable OCI digests, and Argo CD reconciliation on the management cluster. Who: not selected. Passed in a live run.
Once the destination is known. Sveltos selected the rollout=pilot cluster first. Removing that one selector in the second approved revision selected both staging clusters. Who: not selected. Passed in a live run.
Once the destination is known. Sveltos installed Kyverno 3.8.1 and reported the Helm feature as Provisioned on both targets. Who: not selected. Passed in a live run.
Once the destination is known. After the admission-controller replica count was changed from three to one on each target, Sveltos restored both to three. Who: not selected. Passed in a live run.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog retains its 1 object in one file, exactly as supplied.

# fetch the retained objects for this entry
$ curl -fsSL -o sveltos-kyverno-fleet-3-8-1-staging.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/examples/sveltos/kyverno-fleet/clusterprofile.yaml

# check the bytes against the listing
$ shasum -a 256 sveltos-kyverno-fleet-3-8-1-staging.yaml
1fba789198af3d5cba564ba9777b86ec8e5db8aaf07f4f25e8bc2766c0317396  sveltos-kyverno-fleet-3-8-1-staging.yaml

2. Compare with another version or base Not available yet

The Catalog holds no other version or base of this entry's source in the same format. A second entry for kyverno-fleet in this format would give this step a sibling.

3. Upload it as a variant Partly run for this entry

The record holds a local, temporary or separately recorded upload for this entry, and no retained one. The listing names no public artifact for it, so no upload command is given. Read the record that states this.

4. Deploy it Run for this entry

A delivery run passed for this entry. Argo CD passed, Flux does not apply, and kubectl has no record. Read the record that states this.

5. Promote a change Not available yet

This step needs an upload command from step 3, and this entry has none. A published artifact for this entry, with a receipt, would make this step available.

For agentsThese steps are the nextSteps array of sveltos-kyverno-fleet-3-8-1-staging.json. Each state was read from flattened.retainedObjects, flattened.inventory, source.ociRef, oci.bundles, oci.runtimes, lifecycle.promotion, lifecycle.coverage and variants.known in the same listing. A command marked needsAccount there contacts ConfigHub. A step's notes hold its cautions, carries lists the CRDs the base brings, and liveWalk links the dated log that ran its commands.

Technical notes and disclaimers

This entry is one instruction to Sveltos on a management cluster. A test needs Sveltos and the clusters it selects, so the entry has no plain-objects test.