Project Lightning Talk: CNCF Sandbox Project K8Up Under The Hood - Aarno Aukia, Maintainer

In this talk, Arno, one of the maintainers of the KubeUp project, discusses the importance of robust backup solutions for Kubernetes workloads, especially as many organizations now deploy stateful applications. He highlights alarming incidents where data loss occurred due to poor management of infrastructure, underlining the need for effective backup strategies. KubeUp aims to operate as a backup-as-a-service solution that allows users to define their own backup policies and requirements. The speaker emphasizes the integration of GitOps principles and the use of Restic, an established open-source backup tool, for seamless data management. By leveraging Custom Resource Definitions (CRDs) within Kubernetes, users can easily backup and restore their persistent volume claims (PVCs), ensuring greater reliability for their data needs. Arno calls for collaboration and participation in evolving KubeUp further as a community-driven project.

So, I'm Arno and one of the maintainers of the KubeUp CNCF sandbox project. When I started using Kubernetes in 2000 late 2015, of course most did mostly for like stateless apps. So, I mean the data it was mostly ephemeral, right? But, I mean I guess we're at KubeCon, but even outside of of this bubble, more and more people are using Kubernetes to actually host important workload with

important data. Now, you might have an idea that, you know, something bad can happen to your data, right? And this you make you think about, you know, making more and more more replicas and stuff. You distribute your your nodes on the multiple racks or multiple availability zones. And then you wake up one morning and you discover that all your racks you distributed on were actually stacked one

on top of each other. And when the lowest started burning, all the others went up in smoke as well. As it happened actually not that far from here. The other one is is actually built three different data centers in one major region. They distributed all the nodes on on the different availability zones. And then they woke up one morning and discovered, oops, I don't know if it

was accident or the labeling was off or whatever the the incident that postmortem doesn't say. They discovered that actually the nodes were distributed like regularly all over all the availability zones. The majority of the nodes happened to be in the same availability zone. And this of course it was the one that went offline. And this they didn't have quorum anymore and this the whole service went down

for a few hours until they had the fire put out and the the power put back on. So, you see, when you have this kind of, you know, life happens, when you have this kind of incidents, they're it would make sense to make backups, And that's how we started to develop KubeUp the backup operator in 2018. And we had there already then there were some other backup

operators out there. Some of them even open source and and you know, backed by community project. But most of them were making backups from the infrastructure side, right? You as a Kubernetes operator make the backups, and then when it breaks, when it goes up in flames, you restore the data, right? But, the problem there's some problems with that, right? First one is, which data should you back

up and how often, right? Usually, you as the operator, you don't really know that, right? There might be multiple workloads running on there, you don't know their restore point objectives, their restore time objectives, and then when something happens, you have to go and you have to um restore it for them, But, that's why we went out and make made more of not a backup, but a backup

as a service, right? So, you as a platform engineer, you provide the backup service, which then the users of the backup, uh users of the cluster can define what kind of backup they want and need, which data is important, how often it should be backed up, where should it be backed up, what are the security requirements, and all of that, because of course the application people know

that about their applications. Uh we're focusing on the data. Uh we believe in GitOps, all the uh config should be somewhere in a Git repo, and then you have your tool of your uh choosing, many of them are of course here as well. Um that then takes care of syncing the the Git state with the cluster. we use uh a battle-proven uh open-source backup tool called Restic.

Um that's been around for a way longer than we have. We're just a scheduler and the Kubernetes packaging around that. Um and of course, believing in GitOps, we believe that not only the backup, but also the restore and everything else should be like Kubernetes native um CRDs, primitives, that we all work with with all the rest of the applications. And of course, enabling the others to use

these services, that's not us they call when they want to restore, they just restore it themselves, and then if they have a problem with that, they can of course call, and we're we're more than happy to help them with that. That's the whole idea about uh around KubeDup. Um to uh have uh all your uh PVCs in your um in your namespaces backed up. You you a

schedule, for example, nightly backup here, uh weekly prune, monthly check, whatever you need, whatever your application people need. Rest encrypts everything, so there's a repo password that it takes from a secret, and then wherever you put it, Rest has a a few dozen of back like storage back ends. It can put it in S3, whatever, that you of course also provide as a as a secret. And

then when you want to back up stateful applications, you can either run it inside a pod or you can start a new pod to get it from a service or whatever. You need to kind of stream the data and then make it back up. And no backup makes sense without a restore. You can list the backups, you can restore your backups, all using Kubernetes CRDs. So the

the users of the cluster can use the services as you We've been launching this at KubeCon Barcelona 2019, drinking beers with Stan Coen at the time. We're looking for We're still in a sandbox project. We're looking to people to help us on the journey to become an incubation product project. So if you have a interested, whether you are more into development and engineering, whether you're a technical

writer, project product manager, please join us and connect with us on Slack or on any other the other things. For example, tomorrow at the project pavilion, 10:00 to 2:00, we have a a quorum of maintainers there. Thank you, Tobias, Niklas, Lena here, and thank you Sebi, Simon, and Gabriel who could not be here, but also help us with KubeUp all through the year. Thank you.