 All right we're going and we should start. I'd like to thank everyone who's joining us today. Welcome to the today's CNCF webinar. Kubernetes storage is more than CSI, do it the right way with the OpenEBS way. My name is Orlin Vasilev and I'm a software engineer at VMware and I'm also proud cloud native ambassador. I'll be moderating the webinar today and like to welcome our presenters for today. Murat, who is the VP of products in Maya data. Brian is developer advocate at Maya data and Kiran who is the chief architect for Maya data. First thing first some housekeeping items. During the webinar you're not allowed to talk as an attendee. Please make sure you post all your questions in the Q&A box on the bottom of your screen. Also this is official CNCF webinar and such subjects to the CNCF code of conduct. Please do not add anything that on the chat or questions that will violation of that code. Basically be respectful and follow the participants and the presenters. With that I'd like to hand over to Murat, Brian and Kiran to kick off today's presentation. Thanks Orlin. Hi everybody and thanks for joining. I want to say welcome to all. My name is Brian and I'm a developer advocate for Maya data. I'm joined by two of my colleagues Murat and Kiran and on this webinar we're going to talk about OpenEBS. A CNCF managed open source container attached storage solution for Kubernetes. OpenEBS is used by many organizations and it's a technology that's flexible across a lot of different use cases. These organizations are using OpenEBS to transform their Kubernetes clusters into a resilient data plane and they're turning Kubernetes itself into a storage array. That's why a lot of people were talking about OpenEBS at KubeCon in San Diego. Who is Maya data? We are code contributors to the CNCF. We will talk today with one of OpenEBS' founders Kiran and we'll get some roadmap info from Maya data's head of product Murat as well as a demonstration from me of OpenEBS in action. Then we'll open up the floor to questions at the end but please do submit your questions early in the Zoom interface using the questions interface at the bottom. So now we're joined by Kiran to talk a little bit about Kubernetes and OpenEBS. Hi Kiran. Hi Brian, great to be here. To speak about the stateful applications in Kubernetes, the short answer that I would give is the state of stateful applications in Kubernetes is always evolving. I have definitely seen a lot of improvements in the last three years that I've worked in Kubernetes and I still see it's evolving. In fact, if you look back, the community was mainly focused on making sure we connect to an external storage and that interfaces have now evolved into what we call CSI. CSI is definitely promising but it has a lot in terms of extending the interfaces to perform a higher objective or higher problem that users have around data management. So data management is something beyond connecting or deleting volumes. It involves running distributed applications that require multi-tiered storage, need some data protection mechanisms and ability to seamlessly migrate from one cluster to another. In fact, with the adoption of Kubernetes, there's a lot of use cases that are coming up in terms of migrating from non-Kubernetes environment into Kubernetes clusters. So in fact, as we speak today in the six storage, there's talk about formation of a SIG data protection that in fact talks about or is going to focus on resolving some of these problems that I just mentioned. I'm also excited to be part of a new Linux Foundation project called Soda that's going to be launched and it's also going to be focused on data management. And there's several projects that are complementing the features that are available in Kubernetes itself. OpenEBS is one of them. Valero is another project that I'm closely associated with and I've used. So to come back to your question on how OpenEBS or in what aspect of the puzzle that we saw and to just go back on the history a little bit, right? So Kubernetes is definitely a game changer. It has changed how applications are developed and deployed and early on we saw the potential in Kubernetes could change the way the storage software itself can be written in open community-driven similar to Kubernetes. And that's how OpenEBS picked off. In short, OpenEBS is helping users convert Kubernetes into a data plane. We'll probably get into that a little more in this talk. In fact, one interesting thing with Kubernetes is the original artist never anticipated the way Kubernetes itself is being used today. Definitely they would have not thought of it as a data plan, data plane. In fact, today Kubernetes is used to orchestrate VMs or even other Kubernetes clusters itself. So I'm excited to be working on OpenEBS and the other projects. It's an exciting time for OpenEBS. Can you tell us why so many people are interested right now? Yeah. So one of the primary reasons that I talked about is Kubernetes itself that we just touched. The other two things that draw the interest in OpenEBS, I can kind of attribute it to the background with which the contributors of the founding contributors came from and the early support that we had from the user community itself. So just to talk about the founding theme, this theme has helped even, you know, you could say like coin the term software defined storage and worked on several software defined storage systems and in open source as well. And in fact, like some of the team has worked on the first containerized storage using previous details. This actually helped us as a team to work closely with universities, enterprises and cloud service providers to set up storage in their data centers and look closely at the challenges faced with monolithic block and kind of an architectures. And Kubernetes promises to solve some of these problems. It basically helps us break down this monolithic into microservices and then also build on top of open source technologies. So that's how OpenEBS started and OpenEBS feeds in with the same principles. So it's built using containers. It uses the microservices are designed for philosophy and it is completely orchestrated by Kubernetes. I think it would be fair to say that OpenEBS is completely Kubernetes native storage solution and up to date it only supports Kubernetes. Great. Thanks for that discussion and a little history. So if I can ask why did you contribute it to the CNC app? Right. So CNC has become this neutral home for any cloud native open source project that we develop. It helps the maintenance to put the entire project through a much wider and stricter lens. It also helps the adopters, you know, like we have Orange, Alistar and Comcast not only adopters also provide them a commitment that it's not just open source, but it also also follows the open governance rules that CNC has set forth. Great. Absolutely. Thank you for that, Karen. And thank you everybody for bearing with us. And I wanted to share a comment that our CTO is fond of using which is that applications have changed and someone forgot to tell storage. With Kubernetes app deployments are automated. Highly dynamic. OpenEBS storage has the same characteristics as this. This makes it easy for loosely coupled cross functional development teams to use familiar Kubernetes commands to manage storage for their suite of microservices. The storage is under the full control of the app developers and SREs and is not a centrally managed resource to be maintained by specialized personnel. OpenEBS is container-attached storage. It's implemented inside of Kubernetes and it takes advantage of the availability and security features already present in the Kubernetes cluster. What container-attached storage does for you is really two-fold. It makes stateful apps as easy to deploy as Kubernetes and Kubernetes as stateless apps. And it makes data mobile so that you can move apps to a different cloud regardless of data requirements. When you have a storage solution that's external to Kubernetes, your whole cluster becomes tightly coupled to that storage provider. If you have an external app storage that is on an on-prem storage array, how are you going to move that app to the cloud? If your external app storage is from a cloud provider, will they help you migrate your data to a different cloud provider? With OpenEBS, you put a fully featured storage array inside Kubernetes. It can use any collection of block devices on virtual or physical nodes and it can turn those into enterprise-grade resilient storage with replication, snapshots, clones, encryption, and more. What is OpenEBS? It's the CNCF project with the truly cloud-native approach to running stateful apps. OpenEBS is implemented with a pluggable storage engine architecture. The local PV engine is often used for provisioning local storage in an automatic fashion. CSTOR is another storage engine with features like replication and snapshotting. You can create a Kubernetes storage class that uses CSTOR to store the data in three replicas on three separate nodes where each node has, for example, 12 GP2 disks attached and attached and aggregated into the CSTOR pool. You can then reference that storage class, whether it's local or remote, and replicated in a PVC spec in your application deployment manifests. Or you can simply make it the default storage class. When the pod referencing that storage class comes up for the first time, OpenEBS will create a volume to match the PVC. Since OpenEBS provides storage and works in any Kubernetes, it's useful for just about any stateful application you might want to run. Lots of users use it for GitLab and other CI CD frameworks. We've also seen an increasing adoption as a sort of substrate for Kafka and other data pipelining technologies. And machine learning is another application that can really benefit from data agility since the training sets need to be made available wherever the GPUs are. So now I'd like to show you how easy it is to set up a stateful application in Kubernetes with OpenEBS. Well, just take me a moment to switch over to a terminal. In our setup, we have installed OpenEBS already and configured a simple CSTOR pool. Above you can see the manifest for the storage pool claim. The list of block devices below that shows that the devices referenced in the configuration are claimed by OpenEBS. These could be pretty much any block device, but in this case, they're dev and VME 2 and 1 on three different machines. Next, let's take a look at the storage class definition that references this claim. It specifies that volumes created in that class always have three replicas of the data. You can see we've already applied this configuration. So the system is already set up, set up in a way that a typical enterprise software developer might use it to develop a microservice. If that developer needs an object store, why not deploy MinIO directly within the cluster? Okay, well that creates, let's look at the PVCs associated with that MinIO application. And you can see that the PVC is bound and is using the correct storage class. Ah, there it goes. So you can see the MinIO came up just fine on its storage that with OpenEBS it's just as easy for developers to stand up a stateful application as it is to stand up a stateless one. With that, I'd like to hand it over to Murat to take us through some of the new features coming in OpenEBS. Thanks, Brian. And my name is Murat Karstoglu. I'm one of the maintainers of OpenEBS and also community observer. I'm in the Slack channel as well as Brian and Kiran and all of our team. OpenEBS is on a monthly release cadence and we are excited that we are approaching to 1.5 release as soon as maintainers, we keep the planning public. And all users and our contributors are welcome to attend our planning and prioritization meetings. And this time, if we list all the features and updates, that would be five, six slides here. But I have summarized the most relevant high-level updates on the slide. And as you may already aware by now, OpenEBS is granular, has multiple storage engines that we maintain and Giva, Seastore, LocalPV are production great engines, Dynamic LocalPV, Provisioner, Seastore and Giva all are used in production by large enterprises today. MayaStore is one of our new alpha engines targeting high-performance use cases and recently got encryption and also adding replication and reviews at the moment. CSI, Kiran talked about this a bit, community has made a great progress. OpenEBS CSI support is getting matured and but that's just the interaction with Kubernetes and there is much more behind the scenes to get the API calls executed in the storage world of things and not disk managers, storage engines are big part of our data plane work. On the operational and infrastructure side, Kudo is a great open source operator concept that we are looking recently and OpenEBS Kudo operator is currently in review test will be released with 1.5 again and also ARM infrastructure support is something recently introduced. We have been talking about this quite a long time, especially with the availability of new ARM instances in the cloud vendors like M6G, R6G, C6G on AWS and packet also has very strong, I think it's called C1 large ARM instance, like 96 physical ARM cores and bonded 20G network, very affordable, makes it super attractive for Kubernetes deployments and with the help of our community members starting from release 1.4, we had ARM64 builds for GY in the control plane, now getting into automated builds including C store into that soon and next please and if we look at the next slide, Brian, if we look at the high level roadmap, OpenEBS and its control and data plane components are core to our community and Maya data as enterprise customers as well. Enterprise solution is a bit more than OpenEBS on top of that we have with OpenEBS director users get user interface and monitoring we provide data resiliency and chaos engineering with Litmus and other open source project in the CNCF landscape and also cross cloud and data mobility with KubeMove project which is new under development and data and policy-driven optimization operators for day two operations also in design review right now. If you can switch to next again, Brian, we believe in this mission to turn Kubernetes into data plane, it's been a long journey for us since the days of software-defined storage to app-defined storage with OpenEBS, we proved it now trusted by 10,000 of users they are running OpenEBS on-prem and on the cloud. Storage is a big piece of the puzzle always achieving freedom from cloud or any type of lock-in because data has gravity and your help is always appreciated here seeing users help each other in the Slack channel and also a CNCF ecosystem interaction between projects accelerating users pipelines hearing feedback from users is what keeps me and my team always motivated you can be part of it it's extremely diverse community and we have Rust experts coding very low-level storage parts also we have Go issues for beginners we also have a goal to train and coach new graduates and bring them to Kubernetes ecosystem so we had interns now became core contributors to key CNCF projects and also again Brian mentioned so we Maya data didn't just become one of the top CNCF project contributors so we are by coincidence so by ecosystem users before the company always for us and our mission if ecosystem succeeds we will all have a better future built on the foundation of Linux and open source ecosystem that's all I wanted to say and so giving a mic back to you Brian great thanks Marat and now we'll open up the floor to Q&A awesome thank you guys thank you for the great presentation I see one question I'm sorry three questions on the Q&A box can you guys take a look at it or should I address them we have a question from Felipe if you can elaborate on the data application yeah let me take one question could you compare G1C store historically so G1 came first because we wanted to prove that this DevOps way of providing storage can be used or useful for this new persona but between G1C store G1 creates sparse files on top of existing file system most of the time the root disk so it is useful in the environments where your volumes are smaller and when you don't have specially additional disks to manage let's say edge devices or small environment or mini cube deployments so you only have the OS disk from the nodes you can create a highly available storage by creating sparse file on multiple nodes where C store is a more advanced version where it brings in this disk management capability or or striping or rating disks on multiple nodes as well so where you have additional nodes and where you need larger volume sizes and then on top of that it C store uses copy on write files system underneath which means the snapshots and clone capabilities are more efficient and then where with G1 when you take a snapshot and clone which naturally becomes a full copy of the data and on the C store site it's just a pointer. Hamrat I can probably take another question and just read out the question and then answer it. Can Kubernetes cluster with Open EBS act as a dedicated storage cluster for another Kubernetes cluster? Though with the community project that we have we recommend using Open EBS on Kubernetes cluster itself but we have had conversations in the community channel where users have tried to do just exactly what this person is asking. So if you look at the influence of Open EBS, Open EBS provides block volume services and the block volume services in turn translate into Kubernetes objects. For example you have for each volume a service that uses a cluster IP but you can easily change it to use an external IP that can be accessed from and via more like another instance outside of the Kubernetes cluster that can access the storage. Well let me take this new question what about IOPS in my store is it fast? It comes from Sergei. Yes, Maya store after C store which like I mentioned uses a copy on write file system. Our core strength is storage and we started this Maya store project a year ago now. So I wrote everything from scratch it's written in Rust and then built from scratch like I mentioned and uses Intel SPDK libraries and our goal was to remove the overhead of IceCasin and other overheads in the network layer and also do this in the user space. So we were able to achieve like single digit loss even with the replication over network. So which means if you are using NVMe devices which are now which you can get multiple millions of IOPS. So in a demo at last cubecon we demoed I don't exactly remember but multiple millions I think like five six million IOPS in a single container very close to the raw device performance. But I can take another question. So this question is from anonymous we've tried Rook but found safe to be a bit complicated to manage. Why should I consider OpenEBS and how it differs from Rook? Let's check on the aspect of how OpenEBS differs from Rook. So Rook is a orchestration platform so I see multiple storage engines being orchestrated by Rook and Rook is focused on just being a orchestration layer for storage. With OpenEBS we have the orchestration layer as well as the storage engines and there are multiple storage engines that OpenEBS supports we just touched upon the CSTOR and CHIVA but we also have local PV which is dynamically provisioning of the local PVs is supported in OpenEBS and they're like different flavors of local PV that we can use from host park to block devices to even using on top of ZFS. If you would like to set the encryption on the local PVs then ZFS is a good option and my store is you can already try my store which also has similar capabilities that are being built in. If we are good with time let me take another question from Majesh I hope I pronounce your name right. So for cloud GK, AKS, EKS I should use CSTOR I think question is why should I use CSTOR? OpenEBS abstracts the storage management and layer and it unifies but comes with the additional benefits of course especially with cloud volumes if you are running Kubernetes on cloud you can replicate volumes across multiple availability zones that's one benefit our users find useful most and the second one is you can also use locally attached disks which are not persistent in cloud environment and replicate over multiple so that would give you lower cost higher performance storage devices but also highly available and another benefit is this known cloud volume mount-on-mount issues when it's replicated or sometimes mount-on-mount can take quite some time or get stuck and in that case also OpenEBS our users find it useful to have a replica and this probably would help another question from Philippe hello I would like to know if you can elaborate on data replication over multi-cloud restoring case of failure tanks so yes and if you have we are also using in the enterprise version of OpenEBS but the plugin is available in the open-source repository leveraging velero with some of additional code on top of velero we OpenEBS has a velero plugin you can create a scheduled backups of complete backups of your application and pvpvcs into a S3 backend and then from that backend you can asynchronously restore to any cloud this solution is used again by our users in the community you can you can see the users use this to provide some type of multi-cloud availability solution you can have application running in one cloud and if there is a availability issue on that cloud to recover the data and application to on-prem or another cloud vendor from the scheduled backup anything you want to add here Kiran I think that's good so like we said we have like other efforts also ongoing like Google is another project that's helping us to enhance the capabilities around that area we have a couple more minutes so if you guys have any questions please post them in the q&a box on the bottom I see one more question regarding OIDC this has come up in the community and we are working on implementing the authentication via OIDC that's a work in progress another question from Sergei will replication cloning be implemented in Maya store yes yeah so rebuilds are as I am aware of are in progress right now and and also replication in Maya store we'll be able to replicate across multiple protocols you can use a me me over fabric or I see right there was a question about the the slides in the video the slides will be later on today available online as well was the video and then another question do you plan to package open ebs with velero by example to offer a full persistence and backup so it is in the free open ebs director solution so that if you are an open ebs user you can sign up to this SaaS offering it's free to use again that gives you a user interface for open ebs with velero which we call DMS data migration as a service and it is probably closest and get to a full persistent and backup solution for storage so you can take a scheduled backup from the user interface to an s3 target aws gcp or minio and then recover one more question so you create a storage solution over multi region will there be an impact on performance yes if you're the same with kubernetes clusters if they are spreading across multi region they need to have a good network communication in between latency would have an impact on storage performance as well but in that case where the latency is higher we recommend the solution I recently mentioned the DMS so you can take a kind of asynchronous replication you can call it asynchronous replication but it's more like a disaster recovery solution back up on one cluster and instead of synchronously replicating asynchronously recover data on another cluster we have time for a couple more questions so please ask your questions in the q&a section on the bottom there's a question for a modular on I think I would raise it as do you have any plans of optimizing the rebuild in the case of VM completely getting lost and if we are coming up I think yes that's in progress with each release we are also automating a lot of operations around the rebuilding and optimizing that maybe I can try to take this last one do you have any benchmark comparison with self so apple's apple's comparison would be difficult because open ebs is a granular per application storage so it grows easily where scale out storage solutions you pre-configure pre-deploy it's for a different different purpose and you can it has a larger blast radius than open ebs so we do have some comparison but it differs in every every scale so one it wouldn't be fair to run benchmark on one workload versus when you grow to thousand workloads so open ebs you get the same performance where on scale out storage solutions over when you put multiple solutions it it degrades degrades so it's not fair to compare to a scale out storage solution yeah I think there's a good one from Alec maybe just try to take this as a last question the question is can you talk about how storage engine updates are performed so one cool thing about open ebs is it's all in user space and running as Kubernetes parts so that helps you to perform the upgrade just like any other Kubernetes applications you can actually do rolling updates to get the storage engines updated and with 1.0 open ebs 1.0 that we just released like post the Barcelona coupon we have Kubernetes jobs that go and help us do the rolling updates on the storage engines all right thank you with that I think we can close up the Q&A session and just a reminder from the CNCF don't if you're in the area of Sydney or Seoul don't forget to subscribe yourself for the Kubernetes forum it's a great place to meet professionals and discuss your issues or your desires about the Kubernetes with that I would like to close thank you more at Brian and Kiran great presentation thanks for joining us this webinar will be recorded and it will be posted later today we're looking forward seeing you on the future CNCF webinars have a great day everyone and see you next time thank you