Day 4 - Manage Kubernetes Add-Ons for Multiple Clusters Using Cluster Run-Time State
To build a Kubernetes cluster, additional add-ons are needed. To make things more complex, add-ons likely have to change when clusters run-time state changes. Sveltos wants to provide the best declarative solution to install and manage add-ons: 1. have a management cluster from where managed clusters can be reached; 2. from the management cluster, selects set of clusters with a label selector; 3. lists add-ons to be deployed on such clusters. Such solution still requires admins to manage cluster labels.Ideally admins should simply express the intent: if cluster state is this, then those are the labels cluster should have (and so indirectly the add-ons). Simple scenario:set of add-ons are deployed in clusters with Kubernetes version v1.26.x. When any of the clusters is upgraded to a Kubernetes version v1.27.x, new set of add-ons needs to be deployed. Sveltos aims at solving that: express intent on the labels cluster must have based on its run-time states; express the add-ons a cluster with certain labels must have.Then let Sveltos reconcile the cluster to match expected state. All this while still providing platform admin with a solution to onboard tenant admins and programmatically grant them permissions.
