 Today we're going to be talking about meat kairos. I mean, for those who have already seen us at the booth, meat kairos again, the meta distribution for the edge. So when we talk about meta distribution, what do we mean? We understand that different teams use different Linux operating systems. For example, Alpine, Opium Susei, and Fedora. And we do not want to reinvent the wheel. I mean, all those operating systems already do a great job at providing great package managers and everything that they do. So we don't want to ask you to change your operating system. And we also understand the fact that companies have invested so many years into learning how to use those operating systems. So kairos is not asking you to change any of this. Aside that different organizations have licenses that they use, and you don't want to do away with that. There are also, for people that don't have licenses, you might have golden images. And those golden images, like some of the templates and the standardization that your team makes use of, you don't want to do away with that. So that's not what kairos is asking you to do. Kairos actually builds on top of what you have already. A lot of our computing is moving to the edge, which means that we want to move away from centralized data centers and then move our workloads closer to the customers or closer to our clients. And for real-time processing and all the advantages that the edge provides, we are gradually moving more to the edge and then less towards data centers. So because our devices and our workloads are moving closer to our customers, there are a lot of challenges that this comes with. And some of these challenges include security. I mean, so when your computer is closer to the customer, there's increased vulnerability. It can be tampered with easily. And there's also the case of stability. So if a user wants to make an upgrade or make an update, you want the user to still be able to make use of that edge device without having any issues. So the case of stability also comes in. And then there's deployment. Everybody wants a plug and play. Nobody wants to go through all the deployment hassles. And companies also want it to be able to have very easy deployment experiences. So these are some of the issues that come with having your devices or your computing closer to the customer or in the edge. So Kairos to the rescue. So for security, right? One of the ways in which Kairos solves this problem is by immutability. This means that all the OS components, including the kernel and init-rd, are immutable. You can only read. You can't write. However, Kairos also provides a persistent way you can persist your data. And you can always update this part of Kairos. And then when you think about it, the first thing that comes to mind is, OK, it doesn't mean that this other part can be tampered with. And that's not the case. Kairos actually provides security by encrypting this user data part, encrypting it in TPM chips. And this means that if for some reason your hard disk, for example, is stolen, decryption cannot happen except on the same computer on which it was encrypted. So the user actually needs your physical device to be able to decrypt that data. So Kairos provides the security both on the OS level and then on your persistent volumes. And then for stability, Kairos also provides alpha beta upgrades. What this means is that you have your running image, which is your active image. And you want to make an upgrade to another, like make an upgrade. And then that upgrade that you want to make, we call it the passive one. So Kairos downloads the newer image that you want to update to. And there's a transition phase where after the download, Kairos tries to reboot your device and then loads the new image which you've downloaded. And if there's any issue, it's going to switch back to the previous image. And this is how it provides stability. So I'm going to allow Mauro to continue from here. Yeah, and of course, even if we try to make everything as simple and resilient as possible, we know as engineers that bad stuff can happen. For those scenarios where for some reason, neither the active or the passive image is working properly, we offer also a recovery partition in which you can have a shell and try to either fix one of those two images that is broken or at least get a hold of your data and save it. Another interesting feature that comes with Kairos is what we call a peer-to-peer network with self-coordinated cluster bootstrap. What does this mean? Well, there's this component that we introduced called HBPN. It's basically a mix of a BPN ledger. And what it does is that every node that you install with this component is going to keep record of every other node which you provided with the same kind of key. And these nodes are running on top of the live peer-to-peer library. That means that if for some reason there is limited connectivity, some protocols are not working, you can make use of any other protocol that the live peer-to-peer library offers. This can be useful because some of the edge locations might be restricted in the kind of connectivity that you have there. So I don't know if for some reason TCP is not working, maybe the web sockets are available and the nodes can continue speaking to each other there. And another way in which this is useful is let's say that I want to install a cluster and I decide to have, for example, two master nodes and the rest can be workers. But of course, one of our master nodes stop working for some reason. Then what happens is that because every node has the ability to know about the others, then they will start to communicate between each other and with consensus decide, you know what, we lost one of the master nodes. So now I'm going to become master node and again update this ledger that each of these nodes had in its own so that at the end of the day you continue having the stability, in this case, for example, if you want to provide a high availability on that particular cluster. Of course, if at some point that other master node come back online, he's going to be able to talk to all of them and again decide whether it stays as a master node or if downgrades as a worker. What else? Another thing that we want to do like we were mentioning is make it easy to deploy and one of the things we provide here is that Kairos is easy to configure and maintain. What we use right now is cloud init for the configuration of those nodes. So all your configuration can be done via YAML files. That means that you can keep it in your GitHub repositories, keep track of the changes that that configuration is having throughout time. And as you can see here, this is of course a very, very simple configuration, but you can get an idea of how it works. You just have, in this case, the number of users that I want to install. I want the user Kairos. It's going to have the password Kairos. And also on top of that, I'm gonna tell that this user can get the GitHub SSH key from the user called Modeler and also maybe an SSH key that I provided there. And finally, in this case, for example, I'm enabling the use of K3S. So that means that this node will have the full API capabilities of a Kubernetes cluster. Another way in which we try to make it easy to deploy is that we provide a web interface so that the only thing that you have to do is if you know the IP of one of the nodes, you go, in this case, for example, to that IP and the 8080 port and you will see a website where you can just copy-paste the configuration that you want installed for that node and then you run it and by the time it's done, your system is gonna be configured to the like of that configuration. Some cases, being at the edge, you have some particular scenarios. Maybe the person that is in physical possession of the node doesn't have... You don't want them to have the full configuration of the node itself. And in those scenarios, what we provide is that as soon as the machine is booted, it will show a QR code and then the person just needs to take a picture. Then they can send this picture to your headquarters or however you're doing this and the person in the headquarters is gonna, with the simple use of a CLI tool, in this case the Kyro CTL, is going to register that node and as you can see here, I'm going to provide what is the configuration file that I want and provide the QR code and just by that, I don't need to pass an IP or anything else. It's going to know how to connect to it. Another interesting component that we provide, also useful when you're doing deployments is something that we call Aurora Boot. Let's say that for some reason, you want to send a couple of clusters to different places across the country to build these clusters in, I don't know, different parking lots or grocery stores, whatever it is that your business is, right? But you don't want to go send a person, do the full configuration in the place and then go back, it could be very expensive or it could take too long. And for that scenario, what you might want to do is do some net booting configuration. You just spin up Aurora Boot and then you tell it which image you want to install, again, which configuration you want for that image and then every machine that you start in the same network is via Pixiboot, it's gonna be configured to have that specific setup that you set for it. Then of course, you just unplug all those devices, put them in boxes and send them to the locations that they need to be. The next time that they boot is going to be with the proper configuration that you were expecting to have. So, you wanna... So to finalize, we think Kairos is a great solution for edge computing because just to summarize the little things that we mentioned right now, it's immutable and that means that we reduce the risk surface that an attacker will have is distribution agnostic. So we allow you to continue using your existing knowledge on whatever main distribution of Linux that you are using. We do AB upgrades to facilitate and to avoid ending up with a system that is not working after an upgrade. We have TPN encryption to add security on the user data that you have there. We have peer-to-peer networking so that communication between the nodes is as easy and simple as possible and as reliant as well because of the peer-to-peer library. And finally, it's easy to configure and maintain. And last but not least, let us do a quick demo. I would have loved to do a live demo about the risk of this not going properly, right? So instead, I decided to go for a video, this so that you continue listening to me. And what we're gonna do here is that we're going to create five nodes and these five nodes all together are going to become a cluster, a Kubernetes cluster and I will be skipping because you don't need to wait for everything that is happening. And then once I create those machines in my data center, I am going to spin up Aurora Boot. Here, you can see that Aurora Boot can be run from a container or you can install it on your machine. And I'm going to pass, this YAML is the configuration YAML that I was just describing before. It has K3S configuration and in this particular case, I also mentioned that I want to have three master nodes from the five machines and that's it. We let it continue for a bit. And what Aurora Boot is doing right now is it's downloading an image from the cloud. This can be one of the images that we provide or one that you built with Keras and it's going to copy the root of FES into your local system or in the container depending on which of the two versions you used. And the final result that it does is an ISO image that will be delivered via the Pixiboot configure, via the network. And now we're going to start spinning up the VMs. So you can see here we can start them in parallel. They are all in the same network so they are all going to start getting the same configuration. And I'm going to launch a remote console so that we can see what is happening in the node. Here on the left you see Aurora Boot receiving already all those connections from the different VMs and that smaller window is the VM that's been spin up and it's already receiving Aurora Boot instructions on how to configure and install this node. And let's make it go a bit faster. That way there's more room for questions. Yeah, we open consoles on all of them so that you can see that everything is happening in parallel. You don't need to wait in serial for each of these to be configured. Let's go faster. This part is a bit slow. Yeah, and you can see that one of the nodes at this point is already booting. I think I went a bit too far, yes. So you can see that there is grub and it's a bit small maybe but there you can see that we have the option to just boot Kairos to go into the fallback which is the description that we were saying about the AB upgrade. So if there is some issue with the current image you can fall back to the previous one that was running. The recovery one in case the two A and B are broken so that you can try to fix things. And the rest of the nodes, of course, are also going to start booting at some point. And here in this screen back here we can see that Kairos already booted for that particular machine. So now what we're going to do is we're going to SSH into one of the machines and using the Kairos agent inside the machine we're going to fetch the information on how to connect to that cluster. So for that what we use is a command called getCubeConfig and this gives me all the information of that configuration which then I could either, all of these images come with K9S as well so you could do it from that node but just to show you that I also can do it from my machine all that needs to be done is copy that configuration save it locally and then point our cube config to that configuration then we start K9S is going to communicate with the cluster that we just spin up and now we can see it there. And next step we can see how we have five machines the five have been registered in the cluster three of them the first two and the last one are masters like we defined and two of them are workers and just like we can do anything that can be done at this point with a Kubernetes cluster like showing up the pods and see traffic there or any other service, KubeBeeb, anything like that and that's pretty much for the demo. As you can see it's relatively simple to set up a complete Kubernetes cluster on your edge devices. So now I would like to give you guys time for questions. Is there any question out there? Sorry? Immutable, yes, you're asking if the images are immutable, that's correct. So what we make is that the root partition and all your configurations like everything on their Etsy directory and all of that is not gonna be able to be changed because it's mounted read only. And on top of that, what some distributions do is that they create the init ramfs at the moment of doing the installation. And the problem with that is that during that step you could be at risk. But what we do is that we create the init ramfs at the moment of building the image. So at that point you're still within your network, right? Within your safe environment to a certain degree. And once you have it installed in the system even the init ramfs is read only and same thing for the boot partition. Anyone else? Yeah, at the moment we, sorry, I'm going to repeat the question. So which flavors or which distributions are supported with Kairos? And at the moment we have, as you were mentioning Ubuntu, we have Alpine Linux, we have Fedora, we have Rocky Linux. Yesterday someone coming to the booth asked me if we could make it work with Alma Linux which is very similar to the Red Hat family as you were asking, turned out just changing two, three files very simply made it work there. So I thought that was pretty cool. Red Hat, yes, but of course with Red Hat you're probably using licensing. So then there's this additional step that you have to do but it's basically supported since we have Rocky Linux and Fedora there, yeah. And we're happy to try to introduce more distributions if people are interested in them of course. The basic requirement that we need is right now our two types of systems are System D and OpenRC and ideally G-Lib C but of course for example with Alpine we only get access to Muscle. So it will really depend what your distribution offers for us to do the transition. Anyone else? Well, if it's not the case then thank you very much for your time and if you have still any other questions or you wanna try Kyro's out, we have our website where it's all the documentation and the different image matrix that we support. There's also our GitHub repository. We also have matrix and Slack channels where you can make questions and finally we have office hours. We meet at 5.30 every Wednesday European time. So if you just wanna pop up, say hi or tell us what is missing in Kyro's, please do and we'll be happy to try to make it better. Thank you.