v0.17.0

🚀 Features:
Rolling Update Strategy for ClusterProfile

A ClusterProfile might match more than one cluster. When adding or modifying a ClusterProfile, it is helpful to:

1. Incrementally add the new configuration to a few clusters at a time.
2. Validate health before declaring deployment successful.

This pull request introduces two new ClusterProfile Spec fields:

• MaxUpdate: Indicates the maximum number of clusters that can be updated concurrently.
  Value can be an absolute number (e.g., 5) or a percentage of desired pods (e.g., 10%). Defaults to 100%.

  • Example: When this field is set to 30%, when the list of add-ons/applications in ClusterProfile
    changes, only 30% of matching clusters will be updated in parallel. Only when updates in those clusters
    succeed will other matching clusters be updated.

• ValidateHealths: A slice of health validation expressed using the Lua language.

  • For instance, when deploying Helm charts, it is possible to instruct Sveltos to check deployment
    health (number of active replicas) before declaring the Helm chart deployment successful.

Benefits of a Rolling Update Strategy

A rolling update strategy allows you to update your clusters gradually, minimizing downtime and risk.
By updating a few clusters at a time, you can identify and resolve any issues before rolling out the
update to all of your clusters. Additionally, you can use the ValidateHealths field to ensure that
your clusters are healthy before declaring the update successful.

How to Use the Rolling Update Strategy

To use the rolling update strategy, simply set the MaxUpdate field in your ClusterProfile Spec to
the desired number of clusters to update concurrently.
You can also use the ValidateHealths field to specify any health validation checks that you want to perform.

For example, the following ClusterProfile Spec would update a maximum of 30% of matching clusters concurrently
and would check that the number of active replicas is greater than zero before declaring the update successful:

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: kyverno
spec:
  clusterSelector: env=fv
  syncMode: Continuous
  maxUpdate: 30%
  helmCharts:
  - repositoryURL:    https://kyverno.github.io/kyverno/
    repositoryName:   kyverno
    chartName:        kyverno/kyverno
    chartVersion:     v3.0.1
    releaseName:      kyverno-latest
    releaseNamespace: kyverno
    helmChartAction:  Install
    values: |
      admissionController:
        replicas: 1
  validateHealths:
  - name: deployment-health
    featureID: Helm
    group: "apps"
    version: "v1"
    kind: "Deployment"
    namespace: kyverno
    script: |
      function evaluate()
        hs = {}
        hs.healthy = false
        hs.message = "available replicas not matching requested replicas"
        if obj.status ~= nil then
          if obj.status.availableReplicas ~= nil then
            if obj.status.availableReplicas == obj.spec.replicas then
              hs.healthy = true
            end
          end
        end
        return hs
      end

🐛 Bug Fixed:

Leftover ClusterConfigurations and ClusterSummaries after CAPI cluster deletion (more details projectsveltos/addon-controller#325)

v0.16.0

🚀 Features:

Projectsveltos can now manage also the management cluster.
Management cluster can be registered to be managed by Sveltos either as any other cluster or using sveltosctl register mgmt-cluster

v0.15.3

🚀 Features:

• Make management referenced resource name template: ClusterProfile can references resources in the management cluster which need to be fetched and whose values are then used to configure resources to be deployed in managed clusters. Those resources' namespaces/names can be expressed as template and reference Cluster namaspace/name

🐛 Bug Fixed:

• Reconcile ConfigMap/Secret when annotation change

v0.15.2

🐛 Bug Fixed:

• projectsveltos/addon-controller#308: if an Helm chart contains both CustomResourceDefinitions and instances of such resources, compliance validations won't work (helm dry run mode won't work). This limitation was added to Sveltos documentation and Sveltos code was fixed to make sure it works if no compliance validations are defined;
• Fixed an projectsveltos/event-manager#94 when EventBasedAddOn references multiple ConfigMaps or Secrets. Before this fix only the content of the last referenced ConfigMap/Secret was deployed by the auto-created ClusterProfile.

v0.15.1

🚀 Features:

• quickstart: addon-controller repo has now a Makefile target for trying out projectsveltos with a test cluster (it creates a management cluster with projectsveltos and workload cluster).

🐛 Bug Fixed:

• Changing ClusterProfile Reloader knob from true to false was incorrectly processed by sveltos-agent.

v0.15.0

🚀 Features:

• start rolling upgrade for Deployment, StatefulSet, DaemonSet instances when a mounted ConfigMap, Secret changes. ClusterProfile has a knob, Reloader. When this knob is set to true, any Deployment, StatefulSet, DaemonSet instance deployed by Sveltos because of such ClusterProfile will have a rolling upgrade triggered by Sveltos when any mounted ConfigMap/Secret changes.

🐛 Bug Fixed:

• some Sveltos components (classifiers, addon-compliance-controller) used to go in CrashLoopBackOff if clusterAPI was not installed in the management cluster;
• cluster classification based on Kubernetes version was not working properly on GKE clusters.

v0.14.0

🚀 Features:

• RoleRequest expiration time is now configurable

🐛 Bug Fixed:

1. ClusterAPI Cluster Ready: check the Cluster instance status to verify if control plane is ready. Do not assume existence of control plane machine
2. Helm chart deployment: skip sections which are either empty or contain just comments

v0.13.0

🚀 Features

• when creating HealthSource, Sveltos can now be programmed to collected resources as well
• new command "sveltosctl show resources" which can be used to display information from resources in managed clusters

+-------------------------------------+--------------------------+----------------+-------------------------+----------------------------+
|               CLUSTER               |           GVK            |   NAMESPACE    |          NAME           |          MESSAGE           |
+-------------------------------------+--------------------------+----------------+-------------------------+----------------------------+
| default/sveltos-management-workload | apps/v1, Kind=Deployment | kube-system    | calico-kube-controllers | All replicas 1 are healthy |
|                                     |                          | kube-system    | coredns                 | All replicas 2 are healthy |
|                                     |                          | projectsveltos | sveltos-agent-manager   | All replicas 1 are healthy |
+-------------------------------------+--------------------------+----------------+-------------------------+----------------------------+

v0.12.0

🚀 Features

• Addon compliance can be expressed using Lua as well.
  Addon compliance using Lua look at all resources together. It is for instance possible to define a compliance policy requiring each deployment to have an associated HorizontalPodAutoscaler.
• k8s client v1.27
• helm/v3 v3.12.1

👌 Kubernetes version support

• v1.24 to v1.27

⚠️ Breaking changes

• AddonConstraint CRD has been renamed AddonCompliance

v0.11.0

Introduce Kubernetes add-on constraint. If any constraint is defined for a cluster, add-ons must satisfy all constrains otherwise add-ons won't be deployed.