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.
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.