classifier

🚀 Features:
Introducing cluster sharding: when Sveltos is managing hundreds of clusters, it is advised to use cluster sharding to spread the load between multiple instances of Sveltos controllers. To enable horizontal scaling, add annotation on cluster sharding.projectsveltos.io/key.
The Sveltos shard-controller will detect new cluster shards and start new set of Sveltos controllers to handle all clusters in a given shard.

🐛 Bug fixed:

• Fixes this bug causing configuration drift detection to not work in certain scenarios.

🐛 Bug fixed:
Long running jobs are explained here
When a job is completed, if it is also present in the dirty list, it needs to be re-queued.
This new release picks a fix in that logic (job options were not copied in such scenarios).

🚀 Features:

• Sveltos can be configured to start agents (sveltos-agent and drift-detection-manager) in the management cluster. Default behaviour is to start those agents in each managed cluster
• SveltosCluster has new field KubeconfigName which allows overriding the default sveltos convention which expected a valid kubeconfig to be hosted in a secret with the pattern ${sveltosClusterName}-sveltos-kubeconfig.

🚀 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 https://github.com/projectsveltos/addon-controller/issues/325)

🚀 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

🚀 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

🐛 Bug Fixed:

• https://github.com/projectsveltos/addon-controller/issues/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 https://github.com/projectsveltos/event-manager/issues/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.

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

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

🚀 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

🚀 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 |
+-------------------------------------+--------------------------+----------------+-------------------------+----------------------------+

🚀 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

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.

• Move to go version v1.20
• Grant addon-manager rbac permission for yttsources

Fixes for add-on-manager:

1. Fix crash when Flux source is present but artifact is not ready yet;
2. Fix issue when a ConfigMap/Secret entry contains more than one resource

Add kustomize support.

ClusterProfile KustomizationRefs field can point to:

1. ConfigMap/Secret containing kustomization files;
2. Flux source (GitRepository/OCIRepository/Bucket) containing customization files

Change add-on manager behavior with respect to template. Use option missingkey=error to force all values to be present at time of instantiation.from management cluster and make it available for templates

🚀 Features

• Support to deploy resource YAMLs in the management cluster
• Support to fetch any resource from management cluster and make it available for templates

🚀 Features

• events and healt checks fully integrated with sveltos multi tenancy solution. This means a tenant admin can create EventSource/HealthCheck/EventBasedAddOns and Sveltos will make sure user can evaluate only resources it has been granted access by platform admin (via sveltos RoleRequest). Sveltos agent running on managed clusters will achieve it by impersonating the tenant when fetching resources (so Kubernetes RBAC will end up validate permissions).
• cross cluster configurations: in response to an event happening in a cluster, Sveltos allows deploying add-ons in the very same cluster event happened or request add-ons to be deployed in a different set of clusters.
• snapshot collects also EventSources/EventBasedAddOns/HealthChecks