Hello everybody, my name is Luca Mardente. I'm a principal engineer at Cisco Systems and today I will be presenting Sveltos and specifically how Sveltos can help platform admin to onboard tenant admins and allow each tenant admin to deploy add ons and application in a subset of managed Kubernetes clusters. We all know that kubernetes by itself is not a complete solution, that when you build to build those production clusters you have to deploy around cell applications. And if you're managing a fleet of Kubernetes clusters, managing around cell application is not a critical problem. So Zveltos wants to help those and the idea behind Sveltos is simple. Sveltos runs in the management cluster and from the management clusters a fleet of managed Kubernetes clusters can be asked and Sveltos can be easily told what to do. Essentially select a set of managed Kubernetes clusters using a Kubernetes selector and list the advance or application that needs to be deployed and Sveltos will take care of the rest. So we have a management cluster where Sveltos is running and we have a bunch of managed Kubernetes clusters. Sveltos has built in support for cluster API, meaning that every clusters which is powered by cluster API is automatically discovered by Sveltos, but any other cluster which can be easily registered to be managed by Sveltos. For instance in this case we have GK cluster or Siva clusters or rancher cluster or regiment cluster which are all registered with Sveltos. And at this point pretty much Sveltos can manage a launch and application from the management cluster onto these managed clusters. The only requirement of Sveltos is that there is a network connectivity between the management cluster in each one of those managed clusters. Here cluster profile is the main CRD that is used to instruct Sveltoscore to do and it has in the spec section like four main fields. The first field is the cluster selector. The cluster selector is just a pure Kubernetes label selector and it selects a subset of managed Kubernetes cluster. In this case it's selecting all the clusters which have the label environment set to Fe stands for functional medication. So first thing is select a set of clusters and then tell Sveltos what to do. In this case, what we are telling Zveltos we have an n charts where section where we can list one or more n charts. In those case we are asking Zveltos to deploy Caverno version 2.6.0 in every cluster that it's matching the cluster selector EMV equals Fe. Then there is a customization those where you can say you can list all your sources where you have customization file. In this case too much, you have a git repo containing a customization files in the path hello world and what Sventos will do, we'll take all those files, we'll done the customization SDK and then we'll deploy the output in the Eng namespace in every cluster matching the cluster selector. And finally there is a policy wrap section where you can reference one or more config maps and or secrets. And the config map and secrets can contain one or more Kubernetes resources. In this case I have an example where there is a config map which is in the default namespace called Contour gateway which contains a gateway class, a namespace and a gateway. So if there is a cluster profile referencing this config map in every cluster matching the cluster profile, Sveltos will take the content of this config map so the gateway class, the namespace and gateway and will deploy those resources in every cluster matching the cluster provide and you can put in the config map bot Yaml or JSon. This essentially a summary of how Zeltos works. We have a management cluster where Veltos is running and we have two clusters which are powered using cluster API. So we apply in the management cluster a clusters profile that says select every cluster matching the labels environment project stands for production and deploy Caverno version 2.5.0 in every such cluster. So if we add the label environment production on the first workflow cluster, Zveltos will detect that this workflow cluster is a match for this cluster profile and will take all the listed add ons and applications and deploy those one. In this case we only have cavernos as well as will deploy Caverno in those workflow cluster. Likewise, if we add the label environment production on the second cluster, Veltos Financial logic will react by detecting that this cluster is now a match for this cluster profile and it will deploy Caverno in this cluster as well. What differentiates Veltos from all the other tools which are available today to manage add ons and applications in a fleet of Kubernetes clusters? Well, Speltos allows you to express helm charts and Royam and JSON as template and instantiate those templates using information which is present in management in resources which are present in the management cluster. For instance, in this case we are asking Sveltos to deploy calico in every cluster in every production cluster, but those value section of those helm chart is expressed as a template and it's referring the cluster. So what Sveltos will do before we'll find every cluster matching this clusters selector and for every cluster we'll take the clusters instance which is present in the management cluster and represents the cluster where Sveltos is about to deploy this calico. And we'll take this spec clusters network podcaster block section of this resource which again is present in the management cluster. We'll instantiate this value those template using the information found in the resource present in the management cluster. And after this instantiation we'll go ahead and deploy the resources. By default, Veltos is access to a set of resources that represents the cluster. If you're familiar with cluster API, the cluster API cluster instance representing the cluster, the infrastructure provider, the Kubeadm control plane or this Veltos cluster instance which represents a cluster which a GK cluster for instance which has been registered to be managed by Sveltos. But Sveltos can be instructed to fetch any resource present in the management cluster and use its content to instantiate those templates. In this case, for instance, mentors is being instructed to fetch a secret which is present in the management cluster which is in the default namespace and code scalar and instantiate the content of the content map which expresses a template using information which is present in the secret. Here. You just have to give like Sveltos the right permission to fetch those type of resources if you need like extra resources. But as Veltos says they have built at those point like to fetch anything. Now what if we are a platform admin and we want to onboard a bunch of tenants? One approach is to give every tenant a subset of clusters. So what you can do in this case is that as a platform admins you can create cluster profile in the management cluster. Those cluster profile can match any cluster in any namespace, but then you can import a tenant by giving every tenant its own namespace. And Sveltos has another CRD which is called profile the profile. It's exactly same as a cluster profile. It has a cluster selector where you can select clusters where to deploy the add ons and applications and then it has an answered section, a customization of sections and a policy intersections. The only difference between a cluster profile and cluster that a cluster profile is cluster wide. So I can manage any clusters in namespace. A profile is a namespace resources, so I can only match clusters which are in the same namespace where the profile is defined. So what happens in this case is that again you are the platform admin and the platform admin can create cluster profiles and the advance and applications listed in those cluster profiles can be deployed like in any cluster, in any managed cluster because a cluster profile can match any clusters in any namespace. But then you onboard tenants by giving every tenant his own namespace. So in this case the tenant one has been given like the tenant one namespace, those tenant two has been given the tenant two namespace. So the tenant one at this point can put like his own profile configuration and his own profile configuration is only going to be deployed on clusters which are defined in the same namespace. In this case the clusters which manage cluster with those blue background, the tenant two namespace can put the tenant to admin can put its own configuration and it's going to create like its own profile configuration in the namespace that has been assigned to tenant two. And this provide configuration put by the tenant to admins is only going to affect cluster which are in the same namespace. In this case those tenant, the managed cluster with the yellow background. So what happens is every name, every tenant can put his own configuration listing which advance an application is to be deployed, but two tenants do not interfere with each other. The configuration by set by tenant is only going to be deployed in clusters which have been assigned by the platform admin to the tenant. This is one way of doing it, and this works well when you want to give a clusters to a tenant. But another scenario is what happens if instead I have a set of clusters and I want to give one of those clusters to be shared across multiple tenants. Well, Sveltos is a solution for that as well. What Sveltos like introduced in this case is yet another CRD. It's the role request CRD and those role request CRD. Again, it's a cluster wide resource and it contains a cluster selector which select like a set of managed clusters. And then it has a role type section which reference one or more config maps. And in the reference config map for secrets you can put a bunch of cluster role and role and then you have an admin section. The admin section identifies an admin. In this case I'm saying that the engineering admin, as in every cluster matching the cluster selector department equals engineering as all the permissions that are defined in the config map in the default namespace called full access. Let's look at an example before we go there. How can Zveltos know that a cluster profile has been created by given admin. Well, Zweltos expects this folding label to be present in every cluster profile. So if you want us Veltos to say to know that those cluster profile has been created by a given admin, add this label projectsveltos IO admin name with the name of those admin. How you can achieve that? Well, if you're a plugmon admin you can use an admission controller and Sveltos for instance provides this Caverno cluster policy that says like every time a cluster provide is created, take the name of the service account creating this cluster profile and add this label here. Now let's see in an example how this works. As a platform admin you can create a role request that says in every clusters matching the cluster selector environment pre release give the admin ange all the permissions that are defined like in the config map in the default namespace called clusters. And this config map contains a cluster role star star which means that we are giving those engineer mean like cluster admins permission in every cluster matching the cluster selector environment pre release. So what happens if later on the tenant admin inch creates a cluster profile and we can see that this cluster profile has been created by the tenant admins inch by the presence of this label project's veltas IO admin name that the caverno is going to be deployed in every cluster that is matching the label environment prerelease. Because we have given like this admin the previous slides, we gave this admin ange for permission like in every cluster matching the label environment prerelease. But what happens if the same admin so you see the label, it's again projects Veltos ao admin name engine tries to deploy caverno in every cluster matching the label environment production. Well in this case like this admin here has not been given permission to deploy anything in this clusters. So Veltos will block will block that. This concludes this presentation and thank you for your time and hope this was useful. Thanks.