 Welcome everybody, and thanks for tuning in. I am Alex Chalkies, Kubernetes product manager at Canonical. With me, I have the pleasure of having Alex Jones, our engineering director for Kubernetes. Thanks for the introduction, Alex. I'm really excited to be here too. Today we're going to talk to you about low-ops Kubernetes storage with MicroKates and OpenEBS. Let's have a look at our agenda for today. We will start with a problem statement, the challenges of storage in Kubernetes. We will then introduce OpenEBS, the popular CNCF project for storage, and its latest backend called MayaStore. We will continue with a quick intro of MicroKates and its add-on ecosystem and architecture. And then tie everything up by showing you the new MicroKates MayaStore add-on, which we believe solves a lot of the Kates storage challenges. The second half of today's webinar is going to be a technical demo, where we will show you how easy it is to create distributed block storage volumes for your Kates clusters with MicroKates and OpenEBS. So let's dive right in, shall we? Alex, what is so hard about storage in Kubernetes? Well, because Kubernetes is effectively the posix of distributed systems, that means that it has the same kind of constraints as you'd have in a traditional infrastructure setup where you're trying to replicate data across physical locations. You're trying to make sure that data is kept up to date and you have a way to back that data up. So fundamentally, the problems with Kubernetes storage are the same as storage on many other types of architecture, but on top of that, the abstractions are very complicated because you're often having to deal with the idea that you're working with primitives that don't necessarily map to the Kubernetes landscape directly. So what I mean by that is whether you have a NAS or a SAN, different types of file systems and all these other considerations when you're thinking about your storage, not to mention this type of storage such as block storage versus object storage. So in these three bullet points, I think that effectively summarizes what I was saying with the last part being that whilst all this is going on, you need to make sure that you're not having any sort of data loss and integrity is kept overall. So it's a really tricky thing to get right and we've seen a bunch of different vendors and different open source projects attempt to cover this. And really, the star of this talk is MayaStore, which is a driver that was released by OpenEBS just gone into GA quite recently. OpenEBS aren't new to developing Kubernetes-based storage systems. They've actually developed C-Store amongst one of their other drivers and have been doing this for a while. What's particularly interesting though about MayaStore is that not only is it built on pure Kubernetes primitives, it has a control plane, a data plane in Kates with the associated custom resources, but it's also boasting a bunch of key features that are pretty exciting. So you've got the ability to deploy it anywhere. What does that mean? Well, it's not tied into any cloud in particular. As long as your underlying host is relatively commodity-based. So what I mean by that is that it's sort of off the shelf and it has the normal kind of Linux kernel settings. It also has a bunch of other interesting things such as NVMe OF support. So using NVMe OF enables a key gain in IOPS for read and write to disk, which is really, really useful. But on top of that, it supports multiple different types of disks. So you can support sort of in-memory RAM disks, async disks, and a bunch of other options as well. And with all this, given the fact that it's an open-source project, which is currently in the CNCF sandbox, we were very, very excited to leverage it for MicroKates and the needs of the distributed storage. MicroKates is a CNCF-certified Kubernetes distribution. MicroKates stands out for its ease of use and low ops approach to Kubernetes deployments. All Kubernetes services are packaged in a single artifact called a SNAP, and it only takes one command to install it under a minute. MicroKates can be used as a single-note Kubernetes on a developer workstation or as a highly available cluster for production in clouds or the IoT Edge. On workstations, it supports multiple Linux flavors, Windows and macOS. It can be deployed on both ARM and Intel hardware, so it can run easily on a Raspberry Pi type of device or something like a 5U rack in a back office or a cell tower. The main characteristic of MicroKates is the great developer experience that spans compute environments and use cases. With MicroKates, developers have a lower barrier to entry in the Kubernetes and cloud-native ecosystem. They can use MicroKates to quickly and easily set up their Kates nodes and to build disposable clusters, either for their own testing or for experimentation with the latest upstream features. This last thing is possible as MicroKates releases a week after upstream and all the latest updates are made available immediately. Using MicroKates as a local Kubernetes allows for a seamless transition from development to staging and production, as you can use the same conformant Kubernetes deployed in all stages. For DevOps, features such as self-healing, high availability, transactional over-the-air updates and security patches and sandbox cubelet environments make MicroKates the go-to platform for mission-critical workloads. You can also quickly spin up nodes up or down as part of your standard CI CD pipeline. Another big benefit for platform teams is lower cluster maintenance costs. As with MicroKates, many of the cluster operations, such as datastore maintenance and upgrades, are automated or simplified to just a few commands respectively. And for software vendors working on container solutions, MicroKates' simplicity, robustness and security make it a great Kubernetes platform to embed into their cloud-native solution. They can leverage a system that doesn't require too much of their attention as a delivery framework for their software and focus on building their apps and keeping their customers happy. One of the key features that highlights MicroKates' minimal UX is the add-on system. A single command gets you bootstrapped with Kubernetes networking, storage, observability, view acceleration, serverless frameworks, and so on. Just one command to turn these on or off. And by the way, you can also create your own add-ons using the add-on framework. One of the latest MicroKates add-ons is OpenEBS. The OpenEBS add-on was originally contributed by one of our community members in 2021 and was delivered as part of MicroKates' release 121. The original add-on was using the older Jiva storage backend. But now, it has been taken on by the MicroKates team as one of our core add-ons, and it uses the Maya store backend, as this one is better maintained, more feature-rich, and recently hit general availability. So now let me present you a bit of the MicroKates architecture and show you how the OpenEBS add-on works on top of MicroKates. Like I said before, MicroKates is delivered as a snap, which is really a SquashFS file system that runs all the Kubernetes services in a sandbox, therefore shielding the underlying system. The snap packaging also unlocks automatic updates and uses semantic channels to easily handle upgrades. When you install MicroKates on a single machine, you get all control plane and worker node services running. Installing MicroKates on three or more nodes, as shown in this picture, allows you to build a highly available multi-node cluster. Running the MicroKates add node and join commands on the three nodes distributes the control plane and data store services across the nodes, something highlighted in blue here. When it comes to storage on a single node, you can enable the host path or Maya store add-on, and your pods will be able to consume the local storage through the PVCs. What's really great about the Maya store add-on is that when you cluster individual MicroKates nodes that have the add-on already enabled together, the Maya store control plane will also become distributed across the nodes alongside the Kubernetes control plane, no additional commands or configuration needed. A local file is being used inside the snap, so you don't need an attached drive to enable this, and this is how we enable distributed block storage with Maya store from single to multi-node clusters. Now that you know how this feature has been designed, this time we show you how it works. On my screen here I have a very simple setup where I'm just running a bare-bones MicroKates. You can see that it's just been spun up and bits and pieces are finishing off. So the first thing I'm going to do is MicroKates enable Maya store. What this is going to do is check that I have huge pages enabled, check that I have NVMe TCP modules turned on, and also turn on Core DNS. After this, it will install the Helm chart and bring up the additional services that are required. This is a battery's included installation, so we do quite a few things under the hood beyond just installing the Helm chart, such as provisioning the storage, connecting up the storage pools and making sure that you're able to create volumes. So let's talk about how that works. Just after we validated that things are starting up. So this looks good. We've got Core DNS started, and the next few seconds we'll see Maya store enabled. So looking at this illustration here, you can see that we have three nodes in this example. We pick one of these nodes, just like the one we're looking at today. Maya store has its storage inside of sparse image file that we create for you inside the snap. This is intentional because it doesn't rely on any external volumes, any external disks, or set up to be required. We have it all in this self-contained snap, which is really nice because when you delete the snap, you can get rid of the block storage if you so wish to. It also means as well that we can set with a known set of defaults, and that means that we can start to build out a cluster in a very predictable way. Just in the background, let's check. We can see now that Maya store is coming up online. Maya store is comprised of two primary category of components. You have the control plane, which is known as Moac, and then you have the data plane, which is comprised of the CSI controller and the Nexus pod. The CSI controller does all the typical handling functions such as attach, detach, publish, unpublish, and then the Nexus pod is what controls replication and actually writes as a proxy to other pods. With that said, those are primarily illustrated here in this teal color where the Nexus pods are effectively the most important parts of the Maya store components. However, you need all of them to make it work. What's really cool about this is that when you scale up a MicroKates cluster with Maya store enabled, you automatically get new block storage available, and that will get recognized by Maya store and it will start replicating where required. On top of this illustration, you can see that we have this object called Maya store. These are custom resources. The reason these exist is that these are to help us to effectively manage the local node and that local node, we want to be able to tell it which disks to connect to. Now, because we're providing this as a batteries included solution, we know where these block storage files live, so we write that into the custom resource but what's cool is that you can also extend this Maya store pool to add some attached optional disks later on. You might want to modify these CRs or put them into Git and then to update them by GitOps. It's your choice really, but the point being is that this enables you to control how Maya store interacts with the physical node. So let's go back and see how we're getting on. The initializing pods here, you can see we have now the Maya store Nexus pod, which is just coming up online and we also have the CSI controller that's finishing off. It's worth noting if you look at our custom resource definitions, that we have also our Maya store pools type, which has been installed and we have the pool of foo, which is the name of my node, which has just come up online. So if we go back now, a CSI controller just came up. Let's have a look where this stuff actually lives. So we got a vast snap microcates, common Maya store. You'll see we have a data directory with microcates in there. That microcates file is 20 gigs and that means that we can start using it straight away. So what I'm going to do is I'm going to go to home foo and I think I have here a couple of YAML files. I've got a PVC and that PVC uses the storage class name of Maya store. What I haven't mentioned is that we give you two storage classes that connect to Maya store out of the box. You've got a one replica storage class and we also provide you with a three replica storage class. This is so that you have some realistic differences in the choices here, right? One is just for local development and potentially getting something up quickly and then three is for full HA. So for this example, I've just picked a single replica. So let's go ahead and install that and then I've got a pod that is going to attach to that PVC just for good measure. So we look inside our cluster you can see we already have container creating. We go to our PVCs. You can see that that PVC is bound to the storage class of Maya store and now you can go to volume attachments and see that the attacher is set to the CSI Maya store. Let's take this PV UID. Now we go to cat proc self mounts. This is where you can see where you have your attachments. I think what's really interesting about this is that we can start to find our PVCs. So here you can see we have a mount point which is working inside our cluster all the way down to our host OS. So let's have a look. That pod should be up and running now. There we go. We can see that the task PV pod is running with this persistent volume claim in the background. Of course, this is only the beginning. What's also really exciting is as you start to scale out this cluster you can start to see Maya store and its replication and all the powers that go with that. This is just the first step on what will help to give you HA storage without even having to think about it. So as I go back to my Maya store pool I may want to add additional disks. I may want to make adjustments. It supports a bunch of formats. So you've got async disks. You've got RAM disks. You've even got in memory disks as well. So there's a bunch of stuff you can do that's really cool here especially for performance testing quickly fuzzy testing as well, which is really nice. That effectively concludes what I wanted to show you. You can see how in five minutes time we've got up and running with Maya store and it's as easy as microcates enable Maya store. So just as a recap from the demo there I'll show the illustration again and just as a reminder Maya store is being used inside of microcates and in the conjunction with the sandbox environment of microcates it means that anybody can deploy out distributed storage on top of microcates in a very simple way. What's also really cool here is that of course as I mentioned and showed you the get up and get going part is super simple but then adding more nodes into the cluster is equally very straightforward and then you have built-in resilience and replication. So yeah, we're pretty happy with it and we're excited to see our users start to adopt it. That was a truly awesome demo, Alex. Thank you. And that also concludes our error time for today. Thank you very much for watching. We invite you to try out the new microcates OpenEBS add-on using the commands you see now on your screen. We of course look forward for your feedback. So feel free to reach out to us on Slack, GitHub or our social media channels and you can always check out our website for more information about microcates and canonical Kubernetes. Thank you again, everyone. I really enjoyed demoing and being here with Alex it's been a real exciting opportunity for us to talk about some of the latest innovations in microcates. We really like the fact that we're marrying together the CNCF project and especially one that's bringing such awesome features as MayaStore. Thanks very much.