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)