And so welcome to my session introduction introducing the Kubernetes checkpoint restore working group.
Please be quiet.
Thank you.
So this talk will be as the title suggests about the Kubernetes checkpoint restore working group.
It's also, I only have 10 minutes.
And there's no time for questions.
So if you have any questions, please catch me later somewhere.
And then we can talk about it.
So why did we create the Kubernetes checkpoint restore working group?
So there's a bit of history.
So I'm personally working on checkpoint restore for, I don't know,
long time, 16 years probably.
And since the last six years we've been focusing trying to get checkpoint restore working in Kubernetes.
And the reasons why we want this, the use cases, that's an interesting site story kind of.
If you look at the last 25 years of papers written about checkpoint restore outside of the context of containers also,
it's always the same, it hasn't changed.
We read a paper from 20 years ago.
The reasons why people want to have this probably still the same.
So this is mainly you want to have four tolerance.
You have a workload running.
And for whatever reason you want to project it, if some of the resources in your cluster or
failing, you want to have a point where you can continue running your workload without starting from the beginning.
Another use case is which has come up in the last years is more and more in the last years.
This fast startup time, this is mainly people are using this with Java applications today.
So you initialize a Java application.
You take a checkpoint and then you restore it from the checkpoint and it will start.
And much faster.
And the thing which why people are really interested in the last years is better resource utilization.
So you have a cluster, Kubernetes or not.
And you want to redistribute your workload.
You want to rebalance your workload and without stopping the workload without losing any progress.
And so this is also reason why you would like to maybe use checkpoint restore to migrate your workloads.
And especially the resource utilization part has become interesting in the last years with GPUs.
GPUs because GPUs are really expensive and everybody wants to run something on GPUs.
And so people are really interested to finding a solution how to better utilize existing resources and existing GPUs.
And that's why we have seen much more interest in checkpoint restore related topics.
In the beginning, I have done this mainly all alone.
And then sometimes later, I don't think he's here.
He's slightly slightly joined the effort.
And I think Victoria's over there.
She also joined the effort.
And so we in a small group started to work on this.
And in 2022, we had the first thing which was merged in Kubernetes, container check pointing and restore.
And but the problem or it did work for us at the time, it was all happening in a small group, most discussions were private.
And we we tagged along pretty good, but it was it was a really small group and they were it was easy it was difficult for people from the outside.
Understanding what we did and why we did it and so.
So in the last one and a half years.
Working group idea came up and last year here at Boston after my talk people started to talk about us about why we do things we do them and couldn't we do this differently.
And then all of the first half of 2025 people were reaching out to us and saying what's happening here can we also joined this effort.
And so we thought.
Maybe it's time to make this something official and the Kubernetes community has this this construct called working group.
So they have special interest groups which live for a long time and they have working groups which are more for short time to try to solve a certain problem.
And so we thought yeah well maybe creating a working group and having more people join this effort would be the the right the better approach.
So what we did in in May 2025 we started to fill out the Kubernetes paperwork.
It's a pull request where you describe what you want to do why you want to do.
And then just a half year later this pull request was merged and we were able to officially say that a Kubernetes checkpoint we still working group was established.
We then did all the Kubernetes infrastructure thing we need for the working group of mailing list zoom call thing slack channels calendars.
And in December 2025 we actually had a first meeting and the first meeting we kind of introduced what we think are the open topics what this working group could solve in the context of Kubernetes.
And so at this point the meeting we have maybe 2025 people who are interested in in the topic and all working together to find some way how we could get more support in Kubernetes and extending what we currently have.
So it was pretty clear early that the one thing we want to focus in the next time is pot check pointing restore.
So currently we have just container but because Kubernetes is more about pots and there are many resources which are connected to a pot.
It seems like to make this feature useful it's important that we have it connected to a pot and so.
Pot check pointing restore is what we currently working on and this happens in the usual Kubernetes way we are having a Kubernetes enhancement proposal which is a lot of document where we describe everything.
How we want to do it design architecture and all those things and in parallel to this theoretical description we also have an implementation a proof of concept where we try to implement what we describe and this is mainly for us to see if if the ideas that we have on paper actually also work in real life.
And important for us is that the proof of concept doesn't have to be the final solution so if we see in our I don't know.
Testing it or designing it it doesn't work out the proof of concept is just what the name it is it's just a concept and what we want to do to bring pot check point restore to Kubernetes is an iterative approach.
And the main reason is to make it easy for reviewers and I think this is like in any other open source project if we would bring everything at once we would need forever to design and code it and people would have a really hard time reviewing it and that's why we want to.
And do it in small steps and just have first some some initial functionality in Kubernetes and it will not from the beginning support all pot attached resources like volumes or shared memory this will be all happening in in later steps.
And one of the goals of this pot check point restore is at some point maybe we would like to see a scheduler integration so that if resources are getting low somewhere the scheduler can make decisions to automatically migrate the pot from one node to another node.
So who's currently working it or I already mentioned Victoria is one of the chairs how does he and he's one of the chairs and one of the chairs Peter he's not here.
I know that other people who are joining this effort in the working group are also at first them so please say hi and but in the end it's everybody who's interested in the topic.
We're welcoming you to join us help us move this forward in Kubernetes and hopefully we can see it implemented pretty soon.
So when do we meet currently we meet a Thursday 6 p.m. until European time and anytime on slack on the mailing list and my time is up and that's it. Thank you for listening.