Rachid Zarouali—How I Build a Cloud-Agnostic, Kubernetes-as-a-Service Platform 100% OSS in a Month

In this talk, the speaker shares his experience as a freelance cloud architect tasked with building a Kubernetes developer platform for a client. He describes the challenges of creating a fast, secure, and scalable solution that can be deployed on-premises. The speaker emphasizes his preference for open-source tools, focusing on the use of Kubernetes to manage and deploy multiple clusters efficiently. He discusses the importance of a seamless upgrade process, which he achieves through the implementation of the Cluster API and GitOps practices. Additionally, he highlights the stability and advancements in the Cluster API over the past few years, especially the ability to manage multiple cloud providers and streamline the deployment process. The session concludes with insights on evolving tools such as Kubara to further simplify Kubernetes management.

This talk is a a part of my history as as a freelance a product. Um I've worked for a couple of weeks. Let's make let's say that way. Um here's how it started. And this is literally how it started. I just got an email from someone I knew from a a company and they said, "Hey, we want to build our own um Kubernetes developer platform internally with

everything." It was it was almost like um the Christmas tree. So we want it to be fast, secure, scalable. We want to move very fast and we want to have it on premise. and on premise in this case is probably the most important path part of of the story. Um I'm Rashid Z. I'm French actually. Uh freelance cloud architect 7 is my own company. My daytoday job

is basically building tools and platforms for developers to consume as easily as possible. Literally, if the teams I'm working with can leverage what I'm building with a single git commit, that's what I'm paid for, more or less. So, how do we started? Um, so this company knows most nothing about uh infrastructure as code. So, plain click ops portal and click and click. But they had a very

deep and solid Kubernetes expertise, no resources and they had their own open stack that was building up and the whole story was you have to cope with all of these rules if I can say that way and help us achieving our goal. My first attack was to understand what really means we want to go fast, we want to be secure, we want to be highly scalable and

on premises. So what I did at first I'd simply um cut the whole thing in pieces fully open source that's my core I don't work with proprietary solutions I always offer and suggest open source solution that was perfect hyperscalable is everything and nothing at the same time it it really doesn't mean anything the main idea was we just want to be able to deploy several instances of

our developers Kubernetes clusters at once and we want to be able to destroy them at once. That was um the overall idea. The other point is probably the most challenging. Fast for me was at first we want to have something that is highly performant. In their head, fast meant three weeks. So I literally had three weeks to do the R&D, build the platform, test it, secure it,

ship it, train people, and put it in production and on premises, which is another uh challenge in a way that uh I can't leverage any cloud provider. So all the tools that you can have with all the cloud providers that we know was cut off. couple of goals that I made myself for me to make it um how can I say easier I really wanted to be

simple for developers even though those developers knew about Kubernetes how it works and it's internal that wasn't the case for the whole team so we have different level of expertise in the team and I really wanted some to have something that is as easy as possible as I said a single git commit should fit each and any developers depending on their needs I made it or I

thought about it being as extensive ible as possible. You don't have to have a single monolith platform. You should be able to have as many add-ons as you want. Uh change one block to the other. Uh replace the ingress by another one. Uh choose another storage interface for another one. Again, without having to dig in. Fully open source. Again, I'm really into it. And there's just no

way I would um how can I say go into oh I'm sorry but for this project you have to pay. So I thought about what if what if we could use Kubernetes to drive Kubernetes. We know how to deploy a Kubernetes clusters. is I think there's more than 100 way to deploy Kubernetes clusters with Terraform and civil um binaries the cloud providers way all the distributions that

you can find and as those people knew a lot about Kubernetes I was really into let's think about using what you know best to fill again I'm hammering this because that was for me the the I really can't say it clearly. That's that wasn't a nightmare, but that was really stress and let's figure it out. Let's see how you feel about it. That was my first reaction.

Honestly, I just get a phone call. I was like, I'm sorry. Three weeks you wanted this and this and this and this. I can't make it. And we we just had to settle down a little bit and say, "Okay, let's let's chill, think about do your R&D, and then we decide how I fixed it or how I tried to fix it. You will probably discover that there's

some glitches in a way. first R&D I discovered back at that days uh that again there was plenty of solutions to deploy Kubernetes clusters but there's also plenty of solution that exists to automate Kubernetes deployment some were stable somewhere into um um a specific solution um tied to OpenStack for example or something that has been built on top of gardener somewhere tied to the rancher platform and

so on and so forth. And the main point was find something that is evolving as stable as possible again in three weeks without having to lock them into a solution that they will have to probably drop in two or three years. Again, make it flexible, make it composable, and make sure that if whatever happens for the project that we choose, they can either move to another one

without rebuilding everything or simply doing their own evolution. And it probably doesn't seem that way, but that was another challenge in the fact that most of the solutions that you have in this slides back at that time wasn't stable at all. Most of them were like, "Oh, we want to do something with Kubernetes. We thought about probably building uh Kubernetes on top of Kubernetes. We try something

and let's see. Yeah, breathe." And that's what I'm doing. breathe because I was in front of 30 different solution, their own implementation, their own road map, no clear expectation about if I would be really able to leverage them in the topic or if I can contribute to them to make it work for my client. again another round of R&D testing building breaking a lot and then uh

move In the end my suggestion for my client was okay this is what you're doing right now on the left. So basically you are building your own kubernetes one by one. This probably doesn't mean a lot to you but let me explain it a little bit more. What this means on the left is for example upgrades mean you have to upgrade each and any of them one

by one depending on the number of nodes or the complexity of the cluster you have to go through the upgrade process one by one. If you follow the um Kubernetes upgrade path, it could be let's say simple but if you miss one of them then that means that for each and any of these clusters you have to go through one probably two at least three upgrade path.

I have it in another um professional experience and for 40ish clusters it took us three weeks. Three weeks, three people just doing upgrades. This wasn't at all the case. So we move to okay, we have a solution. We will create a seed that you have here uh on the right. A single cluster that has the ability to deploy, manage, destroy, upgrade, but also deploy applications on top

of it. From a very single point of view, from a central Kubernetes clusters, you don't have to connect to 10 or 20 clusters. Just connect to this central one, throw your upgrades, and there's some magic in between. We will dig into it afterwards. that does this for you automatically. Go through each and any clusters, looks at the version, takes the upgrade path automatically, do the upgrade, checks

and passes from one to the other So without moving from three weeks to literally as a git commit. So you just do your git commit, you go have lunch with your colleagues or your family or whatever just to take one or two hours and be back at the office and the full upgrade is done. We wanted to have again something that allow us also to deploy application

on top of those clusters. But the overall idea on top of it was let's say for example I'm deploying WordPress. So the famous CMS that we all know all know of. We didn't wanted to have to go through each and any of those configuration and say hey would you please deploy WordPress on top of all of them. We wanted again to have something as a git commit.

I want to deploy WordPress on cluster A C D FZ blah blah blah and do it to achieve that there's a project which is called uh Capy cluster API who never heard about the cluster API project please raise your hand just to know you're in the right place and I am too that's good cluster API project is basically Kubernetes with Kubernetes or Kubernetes deployed created uh managed

with Kubernetes plain objects. What we able to achieve with my total friends here is to use a single Kubernetes cluster to deploy those clusters almost anywhere in the world almost. So you have the ability, you have a tool, a set of tools actually um that allows you to deploy those clusters on Asia, Amazon, Google, VMware, OVH, Scaleway, um Exoscale, whoever. As long as there's a provider that

has been built for the Cappy project, you're able to deploy it. Another great feature is you're not tied to one provider. Meaning for my AB CDE EF clusters. I can say AB is on Amazon, CD is on Google, DE is on uh exoscale and XYZ is I don't know um scale way I can split them. This project also allow us to move clusters from one provider to

the other. And this was very interesting for me in this project and in another uh I've been working on in the way that that allows your company client team to start somewhere internally with your own platform probably based on OpenStack u and then move it elsewhere without having to rebuild everything. It is mainly changing couples of uh objects in your manifest and that's it. And this magic

tool um cappy will literally automatically move your cluster from your local OpenStack platform for example into I don't know Google AWS whoever you want automatically internally how it works let's let's move it out uh briefly this is the raw uh view of this project what's really interesting here is everything is managed by a new Kubernetes object which is the cluster object and this cluster object has his

hands on everything. The um the part that manages your infrastructure. So where you deploy is the infrastructure cluster and this is where you will decide I want to move to Asia, I want to move to OVH, I want to move to Scaleway. You have the ability to change the Kubernetes distribution that you want. You can go from pure vanilla to K3S, K0 cops, whatever. All by Kubernetes

itself with all the components baked in and allows you to also leverage all the default Kubernetes features, multi-tenency, ARBback security and so on and so forth. How it works? Very very very simple. This is us on the left. We just create a YAML. I will try to show you some of them if I have a couple of minutes. Those YAML you give them to the management cluster

where you have Cappy and all this uh toolkit and that's it. Basically uh cube cuddle apply my very shinu my very shiny yl and that's it and it will deploy on wherever you want. In our case it was open stack but again do it everywhere. There's something that's coming up um being stable, not really stable at least for me, is the ability to also mix. Mix in

this case and I think for some companies it could be interesting is for example you could have your um the masters on AWS because it's cheap there and the workers on OVH because the workers are cheaper on OVH than on AWS. You can literally move your your your nods everywhere again just by doing a simple yaml. Technically how it works and how is it for us? Two

things to keep in mind. Uh v1 alpha 3. If you know about kubernetes the alpha versions means breakage on each and any version could also mean a full rewrite of the whole specification without anybody asking you if they're allowed to. they will just do it because they wanted to. That was the case in my project. And as you can see, I have new clients. We all know

about deployment, uh, name space, um, pods, uh, storage and stuff, um, persistence, volume, network, all those kinds. And now Kappy adds new objects into the, um, Kubernetes Kubernetes features. We now have clusters which is the basic the the umbrella and this umbrella manage is different. The cubadium control plane is where we will deploy the control plane where how why with what and which kubernetes distribution and the

infrastructure is where we will manage the workers where your application will really be deployed. In our case, in the case on this project, it was an OpenStack, but again just depend those kinds are Kubernetes objects. So when you deploy your cluster with the cluster API product, you can do um cube cuddle get clusters cube cuddle get openstack clusters and it will tells you what you have what

has been deployed when the status health and so on and so forth. How do we move on? Very very very easily. Um, start with your own laptop. That's enough. Kind is very enough. You just deploy a small kind cluster and that's it. Deploy the cluster API toolkit. There's a tool for that cluster ctl that does all the magic for you. You can also pass to this tool.

The add-ons that you want to use. I will show you a couple of them afterwards. And that's it. Just a kind cluster. Kind create cluster. Easy. Cube cuddle in it. Easy. done. You have your cluster API preed cluster. So the um how do I say um where you cook your instance locally without anything else. Moving on, create now the real cluster which is which for me is

where you will really deploy your production instances. You don't necessarily have to deploy only one. For example, for huge platform where you have thousands of clusters, it makes sense to have multiple seat clusters just to spread the workloads and have something that is more flexible than one huge cluster that manages thousands of which also could have some issues. And once this cluster is done, move I have

cooked my platform locally. I have prepared my production seed cluster. I just want to move what I built locally to the destination. And there's a command for that cube cut move and will literally move everything. So it will reinstall all the components with the right version move the um connect to the uh manage clusters and so on and so forth. And your seed now will be self-managed.

It's yours real one. And now you're able to create your clusters. Boom. Do it. Either you want to use plain YAML. That's what we use at first. You can use Helm customize whatever the templating engine you want to use. You can deploy multiple clusters at once with several regions, whatever. Again, fully centralized. Just a quick example from the uh OpenStack provider. As I said, this is an

OpenStack machine template. So we define what's the uh image that we want to use for all the nodes um in the sense of this class uh in the sense of this I have let's say put aside couples of of details here uh intentionally but this is the raw idea what I haven't been speaking about is a lot of details that you have to work on uh in

the background. This image is a default one but you can create your own push it and reuses it. Um you can extend the configuration of the nodes that you want to deploy using cloud init or ignition depending on uh the version of the operating system you're using. You can create your network out of it. You can create your load balancer on top of it. everything again baked

in um into uh into the cluster API. Basically what we leverage with the cluster API cluster API project is uh what we called cloud controller managers built for the platform where you want to deploy your clusters. And those cloud controller managers offers you all the features that you want to leverage. Security, networking, storage, uh load balancer if you want to use them. Uh identity if you're on

I don't know the cloud provider and you want to connect to the central uh IM whatever again everything baked in and we're almost there. I mean at that time I think I was like two two weeks in the project and and I was almost there. We had our first clusters deployed automatically and it was working and it was fine. But there was way too many manual steps.

It was developer friendly. They knew Kubernetes. They know how to write TML. They have their templates. That was fine. It was highly extensible. You can add you can add all the add-ons that you want to play with fully open source. But it wasn't really simple to operate in a way that it was manual manifest pushed into a git repository and then applied manually. So we wanted to

move forward and go into GitOps again single git repository use Argo CD create your application set. Argo pulls the information from your git repository syncs automatically done upgrade create. deploy package with Helm or customize with whatever. We used Helm back at that time because I wanted to. um this allows us to train the developers into here's the Git repository. Here's where you would put your values from

the hel for the uh Helm package. Just change those three values. the version of Kubernetes, the number of nodes, and the flavor that you want to use. And that's it. And you can even deploy 10 clusters at once if you want. 3 minutes job. Get commit. Go have lunch. Done. Sorry. Why Argo City or Argo City or Flux um is the same. We wanted to have continuous

reconciliation mechanism not from the Cappy project because the operator does it for you but from the whole management system. We really wanted to avoid someone that says hey I have access to the seed cluster let me cube cuddle edit cluster blah blah blah manually and then change it and then boom your production is done. We really wanted to have something that have u several guardrails uh of

controls and allow us to say oh no no no this is not the appropriate configuration. The appropriate configuration is from the git repository. Let's get the git repository I told you I had some challenges on this project. These are couple of them. Um I have one story. I don't know if it's fun, but it's real. Um, I was working on this project and so I discovered that

I had to use a non-transparent proxy. Uh, the cluster API at that time or ignition at that time uh wasn't offering that kind of feature. So I have to find a way to push those proxy configuration. I discovered that OpenStack was deployed meaning going through the official documentation and that's it. Nobody really knows how it works, how to manage Probably the now the fun point really not

at that time is I discovered that I have limited internet access even worse. I was working for them for I think let's say from the since u let's say 8 a.m. in the morning and the connection to the platform cut. I wasn't able to manage or do my job through uh the VPN connection. So I just gave a a quick chat about hey what's going on and

someone told me I'm sorry we have a sensetorm and I was like I'm what's the relation between my internet connection and the sensetorm is okay you have the sense that's fine but and it was like yeah but the platform you're working on is using radio internet connection so if there's sandstorm rain or even winds you're cut yeah but I have to download around 10 gab of files.

So what the heck? So what in Europe and that takes 10 minutes took me four days and again I had three weeks and I also discovered that documentation is really not our best skills as developers. we really bad at it and we will always be bad at it and this project was really at that time bad at it. So there was couple of undocumented features. Some features

were documented as stable they weren't. Um I had some go issue where you look at the logs and the logs nowhere tells you what really happening. You just have to guess that oh yeah I just changed this line and this line has a space. And what's the relation with the space? And someone tells you, yeah, but you know, the way we build the operator and how it

works, it's really, really strict. So if there's a space in between, it doesn't work. Yeah, but this message doesn't tell me that there's a space in between. And the guy was like, yeah, I know. We have to fix it again. Three weeks production. In the end, I succeed. one git commit one or many clusters automatic rec reconciliation remediation through Argo City and Helm Kubernetes drive Kubernetes I

was able in more or less three weeks let's be honest not really three weeks probably fourish a portable Kubernetes as a platform um project and they were able to use it internally on their open stack and I'm not the kind of guy who wants to just stop and say, "Hey, I did it." I really tried to offer something that is as with the best quality as possible

with the amount of time that I had. So I was like, "Yeah, probably you can we can do better. We delivered at time, but we can do better." What if this project now would have been run today almost four year in the future. The first point is uh the cluster API has become boring meaning stable really stable now highly efficient tons of features has been added there's

way more providers than what we had back then I think we're now into 50 providers that has been supported so it has really opened a lot in what we are capable of with the tool and how we can really leverage it the clusters template configuration were based on Helm. Now in the cluster API, we have the cluster class in topologies that allows you to create clusters template

from the cluster API itself and not from your Helm templates. So you can say okay Helm is for my application and the cluster topology is for um the um the clusters. The main change here is Helm automatically doesn't reconcile. The cluster API does. So that allows us also to have a full control or that would allows us if I was able to do it today to have

full control of the full cluster configuration and make sure that if anything happens in between this configuration will be replied. We now have a hosted control plane. I'll talk about it later on. This is um a pretty cool feature we have not yet stable but we will have in the upcoming releases in place upgrades. Back at that time upgrades mean you have to create a new image

of your Kubernetes platform make it available trigger the upgrade. The upgrade is redeployed new nodes move the pods and so on and so forth. And now we have coming up as an experimental feature the in place and chain upgrades. What that means is for example I could move from 1.31 to 1.35 at once single command locally without draining the without um sorry rotating the nodes. I'm just

using the same nodes and the whole system will upgrade the full cluster out of them moving for sorry from more or less three or four hours time to 10 minutes and there's a lot of addon that comes up let's again um put it for now how the cluster class moves this is the helm what I did before this is now the cluster API way and as You

can see we moved. We're now in V1 BT2 almost G stable, fast, secure. Did it. And we have this topology. This topology explains exactly how you can configure your cluster name, version, um, replicas, label, blah blah blah. All the add-ons, um, networks, storage, um, I don't know, Argo City or all the applications stays in Helm. Before we baked in Helm the application and the cluster everything in

which was easy to deploy but complex to manage because you are mixing infrastructure configuration with application deployment. Now we're able to separate them application helm infrastructure cluster API cluster class easier. So now you can separate rules. Developers can manage their application and your DevOps infrastructure team will manage this object. nobody will mix in with the same um with the same files. We now have an operator for

the cluster API. It probably doesn't make a lot sense and that's fine. This operator is um is golden. The value of this operator is if you remember deploying the operator is cluster ctl in it. So that's a common line that you do manually. This operator allows you to deploy your um cluster API instances automatically on a lot of clusters and manage the upgrades and the system automatically.

No more cube cuddle uh no more uh cluster CDL in it and so on and so forth. You deploy the operator you say hey I want to have cluster API there there there uh the hosted control plane. The hosted control plane is probably for me one of the best uh feature that's comes up. There's two projects I highly recommend you to look at. Cosmotron or Kamei. Those

two tools are fully open source again and they allow you to move the control plane from virtual machine or physical host to pods. So you now you don't deploy for example eight nodes, three masters and four workers. you deploy three pods in your um seed cluster and five workers. If you work for a company that is highly sensible in the PHOPS way, this helps a lot. And

by moving the control plane from virtual machine or bar system to pods that allows you to have a better control of your control plane, but also leverage the feature of Kubernetes itself. Now your control plane is self-filling with HA out of a Kubernetes cluster. Easier to manage. You're losing one pod. No worries. It just responds somewhere. It's not the same as, oh, I lost the virtual machine

or the bar metal system And again, that allows you to have another layer of control of what exists in your platform from a single point of view. You really don't have to connect everywhere. you have all the brain system if I can say that way local um into your seat cluster single point manage everything and redeploy very briefly I'm seeing the clock ticking um as I said

highly highly highly experimental you can play with it it comes from the version what2 or.13 can't remember exactly Um my main uh how can I say the the the main value here is to shrink the upgrade time and make it easier. You don't have to deal with I have to create new image. I have to deploy those image. I have to deploy new nodes. No, I want

to move from 131 to 135. Do it. Don't change the node. Don't change the IP or whatever. depending on the company you're working for. I had some clients that have very strict network rules. Even the communication between nodes were secured with firewalls in between. This allows us to not touch anything in the nodes and still offer the upgrades. We don't have to deal with security. We don't

have to deal with the network team I told you about add-ons. There are a couple actually I would leverage if I would uh work on this project nowadays. The first is um the helm provider again no more helm apply or whatever no more uh git pull from the helm package. This allows you to use Helm as an add-on to deploy application using the cluster API and leverage

all the reconciliation mechanism from the cluster API. If something is wrong, the cluster API will automatically detect it and redeploy the package automatically. This is um more interesting for the infrastructure point of view the network interface the cloud controller managers or the storage again applications side live it to Argo City but again that allows you to split what's the infrastructure live it to the cluster API what's

related to the application is a newcomer u but I really liked it It's something that comes again on top of it. It's an eventdriven add-on depending on what's happening on the cluster and the labels. It allows you to automate some actions, redeploy applications in several regions in several clusters at once just by moving a label from another from one to another and it will um automatically do

it. There's cluster profiles that allows you to reapply some specific configuration on all the clusters at once without leaving the cluster API to go one by While cluster API goes one by one, Zeltos goes full wide again easier to move. Um, speaking briefly about about Zeltos, I'll told you about it. One of the feature is I liked the most especially for the clients I'm working on right

now is you're able to put it in a gap environment. Even if your environment is fully closed, you are you're able to leverage. It probably doesn't make a lot of sense, but we tend to forget that most of the project that we leverage needs internet connection to deploy, get features, get files and so on and so forth. This is one of the tools I really like because

you have the ability to deploy it in a very closed environment and still leverage all the features. One project I would stop here and move it briefly. I'm seeing the clock ticking and I just want to show you a couple of things and have couple of minutes for for question. Um, if you followed me this way, congratulations. Very good. Um and you probably have understood that there's

a lot of tools that we're piling up So we have the clusters, we have the uh operators, we have Argo City, we have Zeltos and so on and so forth using the git repository. Everything needs to be built needs manual uh operation. There's a human we can make mistakes and it takes a lot of time. A new project has been announced I think this year at CubeCon

is a project called Kubra. Um basically what Kubra does is it leaves you to deploy your clusters with the cluster API project and everything like um Argo City uh traffic search manager um your um uh your secret manager in here which is open bow if I remember correctly. Everything is baked in for you using a template and a single binary. So everything that I did in three

weeks or four weeks manually, I could have done it with three comments in it. Generate bootstrap more or less 10 minutes. And this project well I think um again is open source. I encourage you to look at it. The the website is kubara.io. Um it has been open source this year by a company called stackit. And this is one of the tool that I really like because

again it makes things easier centralized templated and automated. Let's see. let's move a little bit faster and go this way. So, how does this work? Easy. You have your infrastructure as code, OpenStack in my case, cluster API, Kubara, your apps done, five stages, 10 minutes, all good. How it works underneath it has its own configuration as you can see here. So I can choose the eert manager,

the ingress I want to use, if I want to use external secrets or not, which is my policy engine, if I want to use monitoring and so on for this is the kubra config file and once this file has been done in it generate bootstrap done as simple as that. Technically um how can I enroll cluster that has been deployed by the cluster API into Kuber labels

monitoring true I just have to add the same label in both spaces and it will automatically sync and then Kubara will enroll the capy cluster and deploy in this case the monitoring features of Kubara into the cluster that has been deployed by the um cluster API product just by using labels or to summarize that would be the first uh the full project uh that I would have

go in if I was working on this project nowadays the infrastructure at the top open stack for um all the features that I need internal image mural because argap git repository creds done and you have a quick example here um that allows you to see how it works. Basically, you create your kind cluster, you deploy the uh uh project, apply the configuration, bootstrap label, done. To summarize

a little bit and open for questions, you have on the left what happened to me four years ago. Here's what I would do today. Back then I heavily leveraged Helm templates because I didn't have anything else to work on. Everything was pure VM. The upgrades was rolling. So like nodes by nodes. Argo City was deployed manually. Um I had to write couple of YAML. If I want

to do it today, I can leverage the cluster class, the operators, probably the hosted control plane, and then I have the ability to switch between either Kubara as I told you or vCluster if you're into um the vCluster side. Key takeaways, we can use Kubernetes to deploy Kubernetes and do even more. I think I have convinced you about this. This project, this ecosystem around cluster API opened

a lot of features not only kubernetes but uh there's a lot of interaction that you can use to move the whole platform from one provider to another. Deploy application, deploy uh several instances of your production platform in different region at once. If you're into um a company that works on different international region, you have this ability. You don't have to do it manually. You just tell the

cluster API project for the infrastructure and Kubara for the engineering stack. Just deploy it and it will automatically deploy in region A, B, C, D Dev can manage their clusters. They don't need me anymore. They don't need uh any uh platform engineer. Just a commit. You just create everything, put it in a Git repository, commit, done. And as I said before, tools like Kubara, at least for

me, I think really lowers the entry level of the kind of projects. You don't need to know everything about the infrastructure, network, um, security and stuff. There's someone like me who prepares the whole stack, make the template, put it in a git repository, couple of documentation, a rhymi file is more than enough. leave the developers to do your git commit and you're good. I have five minutes

left either I go to a quick demo or questions whatever you want. Is anybody has question perhaps so far? One, two, three. Okay. No one. All right. quick demo. So, this is what we did or this is what what I would do. So, we're Oh, no. Sorry. You're not You're not seeing it. Where am I? There we are. All right. So, we create the cluster locally with

a file that is the the current The node is deployed. You see that kind is deploying everything. I'm doing the cluster in it. In my case, it's the Docker infrastructure because I'm working on this demo locally on my machine. Again, there's couples of infrastructure provider that you are able to leverage. Docker is the simple one, but you can use OpenStack, AWS, Asia, Google, Open uh OVH, Scaleway.

There's a lot of them. It's really up for you to choose. As you can see, the management cluster is ready. And now it tells me, oh, if you want to deploy your very first cluster, here's how you do it. cube cuddle uh cluster ctl generate cluster blah blah blah and then apply. And this is what I did. So it created for me a simple file with a

flavor development for Docker, a version, how many control plane I want, how many workers, in my case, none because I wanted to make it easy. And that's it. There we are. I have my two clusters ready here locally. And now move on to Kubara. As I said in it, Bootstrap and as you can see it deploys a lot of stuff. I have open bio there, Argo City,

the search manager. I have traffic that has been deployed as a load balancer. I haven't done anything. Kuba um manages everything for me And we're done. Kubar bootstrap completed. Here's how you can connect to your um Argo City or your Graphana blah blah blah. Here's the login and I can switch to them. And as you can see, I have my clusters ready. More or less five minutes

and now time for questions. Thanks for enjoying this talk. I hope you really like it. If you have any question then please raise your hand. We have uh two minutes I think. Please give some feedback. This is a new talk I've been working on. So I'm really eager to get as much feedback as possible to improve it if any. And u again open for questions if you

want. Thank you. the question >> it's more an understanding question so I get that right uh kubara uh deploys a order tools in the destination cluster so to say >> how does the the user who requested the cluster knows where it can access the ago installation and uh how is the >> the g onboarding as well on that because you need some repo where it deploys from

right so how how is that part done or would be done I guess because you >> you mean how Kubara deploys their ago city and how to access it. >> Yeah. How how the user knows how to access it and how the user configures which repo would be deployed in that cluster with their applications you know >> um Kubara le leverages some templates um let me see

if I can show you briefly um I think I have something like there we are. So these are the templates that Kubra manages uh to deploy the whole stuff. So when you do your init and bootstrap it creates automatically in the git repository all the configuration file that it needs to deploy the whole stuff and then it starts by argo city and then ask argo city to

deploy the rest. So looking for the argo city configuration for example we have it here and that's the helm So you can change the configuration from this template and then apply it everywhere you want if that's your I think I will take it off right. Anyone last question? No. Can we do a I don't know how to say it in English. I'm sorry. Um I just want

to hear from one to five how you like this talk. So just raise your hand and do the one, two, three, four, five, Thank you so much.