Sveltos Kyverno fleet

A repository document, rendered for the site. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

This example is for a platform team that needs to install the same system component on a group of clusters. The team should review the configuration once, keep its history in ConfigHub, and let a fleet controller handle cluster selection and reconciliation.

ConfigHub stores the reviewed configuration and runs the catalog's checks against it. Sveltos runs on a management cluster, selects workload clusters by label, and installs the declared add-on. ConfigHub keeps the reviewed record; Sveltos handles cluster selection and reconciliation.

The reviewed configuration

The ClusterProfile contains the decisions a reviewer needs to see:

The pilot profile adds one selector, rollout=pilot. The two-wave test begins with that file and then removes only the rollout selector to add the second staging cluster.

The source lock pins Sveltos v1.12.0, the upstream commits, downloaded manifest checksums, kind version, and Kubernetes versions used by the test.

What the first live run proved

The test created separate kind management and workload clusters. It installed Sveltos v1.12.0 on the management cluster and registered the workload cluster with the environment=staging label.

The ClusterProfile was uploaded to the live helm-catalog ConfigHub organization as the clusterprofile Unit in Space sveltos-kyverno-fleet-3-8-1-staging. The standard catalog policy was attached to that Space. It requires approval even in staging because the profile changes cluster-wide admission policy. A human README in the same Space explains the example before someone opens the YAML.

The exact object read back from ConfigHub was applied to the management cluster with kubectl. Sveltos then:

  1. selected the staging workload cluster;
  2. installed Kyverno 3.8.1;
  3. reported the Helm feature as Provisioned;
  4. brought all four Kyverno deployments to their requested replica counts.

The test changed the admission-controller deployment from three replicas to one. Sveltos restored it to three. The live receipt records the ConfigHub IDs and hashes, cluster result, deployment counts, and drift test.

What the OCI delivery run proved

The OCI delivery receipt records a separate run with one management cluster and two workload clusters:

  1. ConfigHub stored the exact pilot ClusterProfile under the catalog's system-configuration policy.
  2. A dry-run apply was blocked until the pilot revision was approved.
  3. ConfigHub published the approved revision as a private release.
  4. The runner packaged the approved Unit data as a portable OCI using a local, no-server step.
  5. The package was pulled back without a ConfigHub account and compared with the approved data.
  6. Argo CD reconciled that exact OCI digest on the Sveltos management cluster.
  7. Sveltos selected the pilot cluster, installed Kyverno, and left the second cluster unchanged.
  8. The next ConfigHub revision removed only spec.clusterSelector.matchLabels.rollout.
  9. ConfigHub blocked that revision until approval and published it at a different OCI digest.
  10. Argo CD reconciled the new digest. Sveltos kept the pilot healthy and installed Kyverno on the second staging cluster.
  11. Sveltos repaired a deliberate replica change on both clusters.

The receipt lists the controller-managed fields added to each live ClusterProfile revision and confirms that every approved field kept its value. It also records the OCI digest and Kyverno result for each workload cluster.

This run shows that the public work can sit at different points in the delivery flow. ConfigHub handled the stored review. Portable package creation was local and did not need ConfigHub Server. Pulling that package needed no ConfigHub account.

What remains

The runner installed Sveltos itself directly from its pinned manifest as a management-cluster prerequisite. It used a temporary registry for the portable OCI and two local kind workload clusters. A permanent public package, a larger fleet, and a rollout that pauses after a failed target still need their own evidence.

Check the evidence

Check the committed files without a live cluster:

npm run sveltos-example:verify
npm run sveltos-oci-delivery:verify

While logged into the helm-catalog ConfigHub organization, also check that the live Space still contains the same profile and README under the recorded policy:

CUB_CONTEXT=<your-helm-catalog-context> npm run sveltos-example:hub-verify