KASLIN FIELDS: Hello, and welcome to the "Kubernetes Podcast" from Google. I'm your host, Kaslin Fields.

ABDEL SGHIOUAR: And am Abdel Sghiouar.

[MUSIC PLAYING]

KASLIN FIELDS: In this episode, we speak to Angelos Kolaitis, a senior software engineer at Canonical and the Kubernetes 1.31 release lead. We dive into what's new in the 1.31 release. But first, let's get to the news.

[MUSIC PLAYING]

ABDEL SGHIOUAR: Google announced a new variant of Gemma 2, its open model family. The 2 billion parameters model is the smallest model in the Gemma family and is built on the same research as the other larger models. Gemma 2B is lighter weight-- enables it to be more cost effective in its resource utilization and to run on a wider variety of hardware.

KASLIN FIELDS: AWS is discontinuing some services under its new leadership. The cloud provider stopped allowing new resources to be provisioned for products like CodeCommit, CloudSearch, and Cloud9. Check out the link in the show notes for more information.

ABDEL SGHIOUAR: A refreshed KCD, or Kubernetes Community Days program has been rolled out by the CNCF. The new program introduces changes, like capping the number of events per year to 30 and limiting the number of participants to 500 max per event. The CNCF announced they will offer monetary support, core branding, centralized tools, and regular support meetings to assist organizers. KCDs are community-driven events for Kubernetes and cloud native ecosystem. They are organized by volunteers and community members around the world.

KASLIN FIELDS: And that's the news.

[MUSIC PLAYING]

Welcome to our Kubernetes 1.31 release episode. And I am excited today to be interviewing the release lead for 1.31, Angelos Kolaitis. Angelos is a senior engineer at Canonical working on Kubernetes. He has multiple contributions to open source projects, a highlight of which is his involvement in the Kubernetes release team since Kubernetes 1.26. Welcome to the show, Angelos.

ANGELOS KOLAITIS: Hi, Kaslin. Hi, everyone. I'm super glad to be here and talk about Kubernetes.

KASLIN FIELDS: I'm excited to have you. And we've had a number of release episodes, of course, on the "Kubernetes Podcast" from Google. And something I noticed is that every release lead definitely has a different path to becoming the lead. So would you tell me a little bit about how you ended up becoming a release lead?

ANGELOS KOLAITIS: Sure. So in general, the nice thing about the release team is that it has this shadow program, where essentially anyone from the community is able to apply to become a shadow at the start of each release. So for me, it started around 1.26, where I applied for a number of roles. I was very lucky to be selected as a shadow for the bug triage team. So it was in 1.26 I was a shadow for that team.

Then for 1.27, I was nominated to lead the team, actually, which was-- to me, already, it was like an honor, honestly. So from that then, after that, I thought, most likely, that was nice to release this, that I helped the Kubernetes team. That's probably it. But then the release lead of 1.28 reached out and asked if I wanted to be a release lead shadow, which, again, was very exciting to me.

So I was a release lead shadow for three releases, pretty much from 1.28 to 1.30, which was, again, a very nice experience. I learned lots of things about the project. The release team only touches on a number of subjects. You don't get into all of the technical details, but still it's too many things that is happening too. People see a Kubernetes release, and they don't really see all of the making of the sausage, let's say.

So it was a great experience to be part of this team and see how this thing comes to be. At the end of 1.30, Kat Cosgrove, the release lead for 1.30-- basically, we met at KubeCon. And she said, hey, I wanted to ask you something. And I was like, OK. Is everything OK? Do you need me? Do you need anything? And she said, yeah, do you like to lead the 1.31 release, to which I said, yeah. That sounds great.

How much time is it going to take from me and from work? Ah, nothing to worry about. In the beginning, it's just a few hours, then close to the end of the cycle it's a lot of time. But yeah, overall we discussed a bit about it. And yeah, that's how it basically happened, which was quite nice.

KASLIN FIELDS: A very prudent question to ask when asked to take on new responsibility. [CHUCKLES]

And we also mentioned in your bio that you have contributions to other open source projects as well, it sounds like. So were you involved with open source in projects other than Kubernetes before getting involved with the release team? Are you involved with Kubernetes at all?

ANGELOS KOLAITIS: Yeah. So, in the past, I was working at a company who was involved with OpenStack, where we were deploying an OpenStack cloud for customers and for research teams. Well, the specifics are not very interesting, I think, for this podcast. I think the most interesting thing for me, at the time, was that the team itself was very focused on being, let's say, upstream-focused, where any bugs we would find, the idea was not that we solved it just for us, but rather we contribute upstream.

So if we have a bug, we report the issue. We try to share reproduction steps. Or if we had the bug fix even, we would share it upstream. And it was a great experience for me also as I was getting started in open source to see how this process typically works, which was very interesting. I also got quite a few patches merged during my time there, which is quite nice. And it also brought this, let's say, spirit of contributing.

So from that time, it's not just OpenStack in Kubernetes. It's been more projects, even small projects on GitHub, where I might have some issue with them. And I will just pop up with a PR saying, hey, I have this problem. Maybe people are willing to accept the bug fix for that. And it's quite nice.

And it's also in line with the spirit of open source in general, where the whole point of open source, I think, is that anyone is able to contribute. And not sure if that's relevant for the podcast. There are lots of discussions about what does it mean for a project to be open source. There's lots of maintenance effort that is needed from the maintainers themselves. But in general, the idea is that you fix a bug for yourself, but others can benefit from it in an open way without things getting in the way.

KASLIN FIELDS: Wonderful. Of course, open source is one of the major topics of this podcast. We just had a really nice conversation with Kelsey Hightower over the 10-year anniversary, where we talked quite a bit about the spirit of open source, and what open source looks like for businesses these days, and things like that, so always relevant. So you've had some experience with open source. You got to contribute to OpenStack, you moved into Kubernetes. How has it been being the release lead for 1.31?

ANGELOS KOLAITIS: In one word, I think I would start with a bit stressful. Being the release lead, there's probably quite a few things you have to be aware of. The good thing about it is that it's all very well-documented. There are handbooks, there is previous documentation, there is previous leads, or the the advisor that can help you in many ways.

But there's also quite a few things that are left to your judgment. So as the release lead, you have to-- you see a Slack message-- for example, someone is having an issue, or some bug came up, or some regression has been introduced. And at the end of the day, it's up to your judgment to make a call and figure out what exactly is supposed to be the path forward. So that is from the nerve wracking, let's say, part of the experience.

On the other hand, what I have had-- I feel almost honored to have such a wonderful team with me. So both the subteam leads from the individual subteams of the release team and also all of the shadows that we have had with us this cycle, they've been very not only active, but also focused. They are asking the right questions. They are bringing up the important points.

And they are, in a magic way-- maybe they do this before they become a big problem. So there have been, I can recount, more than two or three things-- I'm not going to name them, obviously-- where it could have been a serious problem for the release. But precisely because they were communicated early and in the proper way, we were able to deal with them and they never even got out of a small discussion of, "let's deal with that-- let's find a solution for this." And we were able to solve things out.

So this honestly, for me, I want to really say once again-- I've been saying this in the release in meetings, I think, for the past two or three weeks. I really want to repeat that. Thank you all for the release leads. Thank you, everyone. It's been a blessing to have you on the team.

KASLIN FIELDS: I love the way that you highlight the leadership there.

ANGELOS KOLAITIS: Right. And the final thing is that I've also had, myself, very good mentors. So the three previous release leads, Priyanka, Grace, and Kat. They have been there for me since they have been there for me before even I really started with advice, or sharing their experience, or helping me with driving this thing. And I am very grateful to them as well for all of their guidance and support. So in one word, how has it been? It's been stressful, but also very rewarding and very exciting. Well, that's three words, but you know.

KASLIN FIELDS: [CHUCKLES] Such is leadership, right? A lot of work, but it's really nice to see what comes out of it. One thing that I've been working on a lot in open source lately is I have a couple of different leadership roles, and I have a number of shadows as well. The release team is such an influence on both the rest of the project and even externally from the project in the way that it structures leadership and the way that it brings up new folks in the project.

And so it's absolutely beautiful to see. I love to see it. And I think what you were saying there is really important to point out, that the role of a leader is to make sure the thing gets done. It's not necessarily to do the thing yourself, but it's to make sure that whatever problems may arise, they get taken care of.

ANGELOS KOLAITIS: Couldn't have said it better myself.

KASLIN FIELDS: Excellent. So as the release lead, one of your most important and sacred duties, in my opinion, is setting the release theme. What is the release theme for 1.31?

ANGELOS KOLAITIS: The release theme for 1.31 is a simple one. It's basically one word. Now, I'm no expert in linguistics. Maybe someone that has a lot more experience in that than me would tell me that I'm wrong. But in general, Elli is a great name, and it has a note. It basically means a person that is bright or beaming with light.

The logo itself is a small dog-- really, a cute and joyful dog. I hope at least people find it cute and joyful, and I like to say with a heart of gold, and a nice sailor's cap as a nod to the diverse family of the Kubernetes contributors. And the nice caps that volunteers in the KubeCons tend to wear, and I'm a bit, let's say, jealous of.

So a bit more about the theme. Basically, my goal was to have a simple and joyful logo. People tend to simple things because it's easier to identify with them. It's a lot simpler to grasp. So the logo itself is a very simple picture of a happy dog. Most people will probably have this mental image already in some way or another, so it's easy to see that and to recognize that.

And why joyful, the the other thing-- so for me, since my first KubeCon, the thing that I have enjoyed the most from this community is the spirit that you have. So Kubernetes is a huge project, second only to Linux for project size, or contributors, or lines of code, or what have you-- all of those metrics. And not even counting the feature work that goes into it. Every release comes with 40 or 50 KEPs that are added in.

There is also a lot of maintenance work. There's lots of thankless crude tasks that have to happen. And this can be boring, or this can be time consuming, or this can be thankless task, as we usually call them. And even through that, you go to a KubeCon, and you don't see grumpy folks. You just see nice smiles.

You see folks meeting each other face-to-face from the-- because they haven't seen each other since the past KubeCon, really, for five or six months. They're all very, let's say, prideful of what they do. And they're very happy to contribute to open source. They're very happy to help towards this direction.

Just as a side note, what is the value of open source itself? It's that you democratize access to technology. You make it possible so that everyone can benefit from something. So to be able to witness an even bigger, every KubeCon, number of people doing that with a smile on their face, to me, that's a vibrant community. To me, that's joy. And that is the kind of spirit I wanted to have the logo reflect for this release.

And it's also what I've seen-- most of the interactions, this release, have been through Slack or maybe through Zoom, so it's hard to connect with people over that. But still you see in the way that people write, in the way that people talk, you see this spirit. And I very much enjoy it, and I'm very happy to be part of it in a way.

KASLIN FIELDS: Wonderful. I think the release theme is something that's often easily overlooked by the engineers that use Kubernetes. Maybe you're consuming it through a cloud provider or something. Maybe you don't see the release logs to see the theme. But I think it's a really wonderful thing to point out because it really speaks to the human element of Kubernetes.

It's created by contributors. It's created by human individuals with their own hopes and dreams, both for the project and for themselves. I love that you're calling out the joy and the diversity of the community. And I think the simplicity is an especially good point because a lot of folks will be like, oh, Kubernetes is not very simple. But the goal for the folks contributing to it is we always want to make it as simple as we can and as understandable as we can, even if it's something that's very complex. So I think that's a wonderful wish for 1.31.

ANGELOS KOLAITIS: Yeah, indeed. I think "simple" is not the first word that comes to mind if you think of Kubernetes. But hopefully, with this release, we are doing a better job of going that way. And at least for the most common use cases, that's how Kubernetes appears to end users.

KASLIN FIELDS: And we got to be ambitious with our releases. If we're going to go for simplicity, we got to go for it.

ANGELOS KOLAITIS: Exactly.

KASLIN FIELDS: And so let's dig into the meat of the release. There are a few removals and deprecations in this release. And I was just reading that blog post, so I kind of wanted to start there. It's also very, very important, of course, to our listeners who are running Kubernetes clusters and might have to upgrade those clusters. Deprecations and removals-- especially removals, of course-- are the thing that's most likely to impact them probably. So let's talk a little bit about those. What are the deprecations and removals in 1.31?

ANGELOS KOLAITIS: Without going into too many technical details-- I think people will not be listening to a podcast for this, I guess. So in general, for the removals, this time around, I think the most important one is the removal of in-tree cloud providers. So cloud providers were essentially added in Kubernetes at a very old time.

It was maybe the right thing to do at that time to make sure Kubernetes was easy to use in different clouds. But as time moved on, for the health of the project, it's a lot easier to have this as out of three, as the direction has been for some time now. And why is that? This is to keep the core of Kubernetes cleaner, easier to manage, easier to have a lot, let's say, smaller surface of dependencies that might be used there.

So this is the direction behind it. And it's quite nice that in 1.31, this migration from in-tree to out-of-tree providers is being completed, which is quite a nice thing to see. Then we have the removal of two storage volume plugins. Again, this is in a similar manner as the cloud providers.

Essentially, it's taking the complexity and the implementation-specific details out of the code of Kubernetes, have Kubernetes focus on the-- reconcile the state of my deployment with what I want it to be, the desired state, and pretty much leave all of the implementation, all of the extra source outside of it. Because I will just define Kubernetes as-- we see it in CNI, CSI, CRI, all of those things. Kubernetes just defines the interface that things should be following. And then the implementation knows best how to implement this interface and provide the value to the users in a way that Kubernetes cannot and should not try to do.

And as a final removal from 1.31, it's a kubelet flag, the terminated pod volumes. Essentially, this is a flag that has been deprecated since 1.8, if I'm not mistaken. It's been quite some time for that. This was mostly meant, if I'm not mistaken, as a debugging tool, where you might have some pods that are failing, and they unmount some volumes. And if the pod fails, you're going to keep the volume around and be able to go in there and try to see what's happening.

So this is deprecated since 1.8, and it's being removed with 1.31. As for deprecations, we have, again, in a similar space with the previous ones, any-- we have a deprecation of non-CSI volume limit plugins in the kube-scheduler. Not much to tell you there, I think. Pretty much, if you know what this is about, you understand why these are not kept.

So I think most people would also not be very-- using them daily, let's say. But yeah, if you know what this is-- you know what it is, I think. And as a final note, there is a deprecation for a node status field, the kube-proxy version, essentially. So this used to be set by the kubelet. But the problem is that this is an artifact of another time, where kubelet and kube-proxy versions were always the same. This is not the case for many common deployment scenarios.

So this field is just mostly an informative field, but can be misleading in a way. So the project is taking steps to deprecate it and eventually remove it going forward. So I think this is the main things of removals and deprecations that we are having in 1.31. Just a note for listeners, please go over the release notes to make sure that you are not affected by this.

KASLIN FIELDS: Yeah. And I think that these removals and deprecations speak very nicely to the theme of simplicity that you mentioned with the release overall theme. Folks couldn't see it, but I was clapping when you mentioned the removal of in-tree cloud providers. I'm a big fan of this work. And we've had, I think, a couple of episodes where we've talked a little bit about in-tree versus out-of-tree code in Kubernetes. And it's one of the ways that we try to keep Kubernetes simpler. One of the big issues with in-tree providers and plugins is, of course, that you have all of this extra code in Kubernetes that you may not even need for your circumstance because you might not be in an environment where you would use it.

So having the owners of those environments own that code, which they did kind of before-- and then they had to work with Kubernetes release process, and that was also a big problem. But just making it very clear that the owners of those types of environments tend to own the code, where those environments interface with Kubernetes, makes Kubernetes itself a lot cleaner and is going to make those plugins and that code a lot cleaner as well. So very excited about that, and it very much is in the theme of simplicity.

ANGELOS KOLAITIS: Right. Exactly. And part of this also, there is this thing where let's say, Kubernetes version-- let's say 1.28 just as an example-- if it uses some versions of a cloud API or any implementation-specific details, there is a high coupling between the version of the cloud that you can support with the Kubernetes version. And if you want to change that, that's not easy to do with in-tree providers. So it's also one of the, as you said, simplicity in the out-of-tree providers themselves because they can much more easily iterate and improve and support new features of the providers themselves.

KASLIN FIELDS: And a good thing to point out here too, is that a lot of these changes-- these removals and deprecations are kind of very much in the in-tree, out-of-tree realm. So the breaking stuff to watch out for would be if you're using those environments and you're using those through the current in-tree proders, then you might want to be careful. But these things have been deprecated for a long time. And a lot of them too, especially with the cloud providers, are more the responsibility of the cloud provider than they are the individual, depending on how you're running your Kubernetes cluster.

But like you said, definitely check out the release notes to be absolutely sure that you're not going to be affected by these removals and deprecations. And in that theme, of course, removals and deprecations are perhaps the most important part of a release maybe. But arguably the things that are being added to Kubernetes are maybe even more important. Depends on your perspective. So whether you're maintaining or building. So are there any key features that you'd like to highlight that are going into Kubernetes 1.31?

ANGELOS KOLAITIS: So like every release, there's new features that are being added. I think we are tracking around 44 or 45. I don't remember the exact number of KEPs for this release. I mean, once again, I'm not going to go into too many technical details around this. This is not for a podcast. This is for other mediums.

But in general, the thing I would like to highlight is there is great work coming from SIG Node for this release. In particular, I would like to highlight DRA, Dynamic Resource Allocaiton. This is a feature that has been coming for a long time now. And by many, it is considered to be either the future or the path towards the future for allowing Kubernetes to be, let's say, the orchestrator, or the manager, or the platform to have hardware accelerated workloads running. So that could be GPUs, that could be accelerated networking hardware that would be, you know, all kinds of things.

So 1.31 adds-- it's the first release to have DRA support. And it has the static DRA. There is some discussion there. Again, as I said, I'm not going to go into too many technical details. But it's great to see that this work is coming into fruition, and people can start using this and trying it out.

And basically, in the past, Kubernetes has had multiple ways to get access to the underlying hardware of a host. It's great to see this becoming part of Kubernetes itself and getting proper support. Also, I would like to just highlight some of the great work that SIG Network has been doing. So apart from the new features, there is also a lot of work that's happening-- pretty much, it can be seen as behind the scenes, where Kubernetes, you can have your deployments, you have your services, you have all those kinds of things.

You don't really get to see behind it. You don't see how the service makes sure that traffic is routed to your healthy pods. You don't get to see how service load balances-- well, not in most cases. And it's great to see that 1.31 has quite some work going to improve the stability, the reliability, and overall the performance of these behaviors that people are using in Kubernetes clusters. In general, what is nice about this is that you don't really have to do anything. As a user, you will still be deploying the same old manifest, the same, allow me to say, boring YAML to your cluster.

But you'll have-- the core is being iterated on, the core is being worked on and improved. And you're just getting the benefits of greater stability, greater reliability for just using the latest version. I'm not sure if I've said it exactly as I wanted to, but I just want to highlight this because it's maybe calling back to this thankless work that we talked about earlier, where no one is probably going to see this.

People in their release notes will be probably skipping over that. But this will have, I think, great effects on so many deployments around the world. So kudos to the folks that are doing this work behind the scenes and making sure that Kubernetes is actually a stable platform for people to run their workloads on.

KASLIN FIELDS: I love to see it. And I think both of these highlights really speak to that simplicity theme once again. Dynamic resource allocation is a newer, more streamlined way for Kubernetes to work with your hardware accelerators, which a lot of people are very interested in right now.

And streamlining that with the DRA is going to be really nice. I've followed it a little bit, but I'm really excited to see the release blog on it. I'm sure that I'll learn a lot more from that. And stability features-- so many of our listeners out there I'm sure are like, yes, please give me stability! And so even if it would be hard to catch these kinds of things in the release notes, I think like you said-- but people really appreciate it.

And it makes it simpler below where you usually interact with it. It's not something that you are going to see or touch when you're working with Kubernetes, but Kubernetes just working a little bit better seamlessly for you, I think, is what everybody really wants. So wonderful. I'm excited about 1.31. And speaking of which, a lot of our engineers out there listening are probably maintaining clusters that they're going to have to upgrade. And upgrades are so scary because there's so much that can go wrong. What would you say to folks out there who are going to have to upgrade to 1.31 to encourage them to upgrade to this version?

ANGELOS KOLAITIS: Well, to start with, please don't upgrade your clusters because someone said so in a podcast. As always, the procedure is--

KASLIN FIELDS: Absolutely.

ANGELOS KOLAITIS: --please go over the release notes, and make sure that you're not using any of the deprecated or removed features, and make sure that you're following the right procedure to upgrade. But, in general, upgrades can be tough. But there's, I think, one or two points for 1.31 specifically. As we said, there is new features like DRA, like other things that we didn't touch earlier, like using OCI images as a source for volumes, for example, in your pods.

These new features, once they're added, they can be used by, let's say, third-party projects, other projects to improve the experience of the way that you consume Kubernetes as a user, which is quite nice. But also apart from the new features, there is also this stability we talked about, pretty much, where you don't see it. You don't have to do anything, but Kubernetes will be taking extra steps to make sure that your workloads are running, and are reliable, and can be counted on to have your production services not breaking, let's say.

Maybe the thing that I would add is that, when there is a new version, people will usually, rightfully so, say, wait, I don't actually care about all of those new features. I just want a stable cluster that is there, and I can actually just deploy my workloads on it and be happy. So the thing that happens is that, at the end of the day, there will be some release in the future that you need to go to, or that you might have some feature or some of the projects that you are using inside Kubernetes will depend on.

So it's a lot better to do small steps in iterations rather than having to, in two years time, jump to a lot newer version and have a much bigger jump to go there. Now, this is not advice specific for 1.31. But precisely because 1.31 adds things like DRA, which is, let's say, a paradigm shift of how resources are consumed in a cluster, I think there is good reason for people not to stay behind for too long.

KASLIN FIELDS: Yeah, it's a really good reason to try this out early. It's introducing dynamic resource allocation, which is going to be very foundational if you're running any workloads on hardware accelerators, GPUs, even if they're not AI workloads, which, of course, is what a lot of people are talking about. But if you're using GPUs in your Kubernetes clusters at all, you should maybe check out 1.31 earlier rather than later to see if that dynamic resource allocation really makes a difference for how easy it is to run your workloads on Kubernetes. So whether it's in a small test cluster just to see how things are going or doing a full upgrade path, we hope that you'll check out 1.31.

ANGELOS KOLAITIS: And might I also add something to this? So all of those features, all Kubernetes features, they go over graduation phases. So they start as alpha, then go to beta, then go to stable. And on each of those phases, there is actual feedback that is coming in. So real users can try them out. They can come back with the bug and say, hey, DRA is working well for us in these situations, or maybe this part of the design is not exactly what I would like to have.

And it's also a great opportunity for end users to come back and say, yes, this is some feedback to make the feature even better or even more suitable for all of the use cases it's trying to cover. And coming back to the original point about open source, this is one of the huge benefits of open source. You don't just find something at the end of a tunnel. You can actually follow along on the journey and say what the outcome will be. I would very much recommend that people take this route if possible.

KASLIN FIELDS: Absolutely. And with that, any final words for our listeners?

ANGELOS KOLAITIS: First of all, Kaslin, thank you for having me. It's been really great talking with you. As for a final thing, what I would probably like listeners to take away from this is that open source is probably, at least in my opinion, the best way we have at the moment to collaborate, and communicate, and work on solutions across-- from the diversity across different cultures, across different companies, across different vendors, all of that.

And the nicest thing about it, at least for me so far, has been that it's very easy to get into. So if you are interested, if you have ideas, if you have aspirations, if you want to actually contribute to this thing, people are willing to hear you, people are willing to help you, people are willing to mentor you, people are willing to listen to you and accept your contribution. And you can be part of something and actually give back to open source.

Most of our infrastructure is running on open source. We're standing on the shoulders of giants, we tend to say. Open source is probably one of the nicest ways where you can contribute a small piece here or a small piece there and make the shoulders a bit taller for the next person. I'm not sure if that is very, let's say, proper as an English phrase, but that's what I would like the message to be, if that's possible.

KASLIN FIELDS: Absolutely. I think that makes a lot of sense.

ANGELOS KOLAITIS: Don't be afraid to to join.

KASLIN FIELDS: Yeah, join us in open source Kubernetes. There are so many folks out there using the project. And we really want those voices in it as we start to build more and more of Kubernetes. Of course, we're trying to simplify as well, like we've been saying in this. And that's been kind of a theme, especially this year during the 10-year anniversary, where we've had a lot of conversations about how Kubernetes has gotten this far, having some really strong core functionalities.

And there's a lot that's been added on over the years, but a lot of our work now is going to go into simplifying it and making sure that we're delivering the right kinds of features that our users need. So we would love to see you in the project. I think that's a wonderful message to close on. Thank you so much for being on, Angelos.

ANGELOS KOLAITIS: Thank you, Kaslin, for having me. And thank you, all, for listening.

[MUSIC PLAYING]

ABDEL SGHIOUAR: All right. Well, thank you, Kaslin, for that interview. That was, as usual, pretty good and pretty interesting, actually.

KASLIN FIELDS: I mean, release episodes are always some of our best episodes. Right? It's nice to have that consistent checkpoint on the community and what's going on.

ABDEL SGHIOUAR: Yeah. And I'm very grateful for Angelos being pretty flexible, because we basically pinged him quite last minute. And we had to work through some hurdles to schedule that one to get it on the schedule.

KASLIN FIELDS: We've done worse.

ABDEL SGHIOUAR: Yeah.

KASLIN FIELDS: We have done release episodes, I think, on shorter schedules, but we're certainly getting better at it.

ABDEL SGHIOUAR: Yeah, we've done one. I think we've done one at KubeCon, right? I remember it was 1.30 or something.

KASLIN FIELDS: We did. Yeah.

ABDEL SGHIOUAR: Yeah, the one with Kat.

KASLIN FIELDS: It's always a little tricky with the releases because we want to make sure to get it out as close to the release as possible so that it's topical and on point, which means that we need to record it before the release is actually out. And you never know if it's going to be a little bit delayed, so you need to do it like at a point where the release is pretty much good to go-- things should be pretty stable--

ABDEL SGHIOUAR: And relevant.

KASLIN FIELDS: --but before the release. So it's always a little tricky to figure out the timing. But we've got removals and deprecations as like-- I think removals and deprecations are the most important thing to cover, probably, for releases because of the risk to our listeners who have to run systems that they have to upgrade.

So that blog actually came out well in advance of the release this time. So I was excited to get to talk to him about that, and especially because we've been talking about the removal of the in-tree cloud providers for multiple releases. And now it's really being complete.

ABDEL SGHIOUAR: Yeah. And the theme, Elli. What can you tell us about the theme?

KASLIN FIELDS: It is very cute. He sent me the picture of the release theme. It's not out yet at time of recording.

ABDEL SGHIOUAR: I hope it will be out by the time we publish this.

KASLIN FIELDS: Yeah, it should be out, hopefully. But, Abdel, I don't know if you saw it. I don't know if he it directly to me, but it is a very cute little dog.

ABDEL SGHIOUAR: He sent it to both of us. Right?

KASLIN FIELDS: I thought it was. OK.

ABDEL SGHIOUAR: Yeah, it's a little dog with a Helm and a little marine hat.

KASLIN FIELDS: Yeah, very cute. But I loved the way that he described it. That's why I always love talking to the release leads about the themes. Because even though they're very silly, there's always reasons behind it. And it's always about the hopes and the dreams of the people making the release. And I loved-- I think simplicity was the strongest point for me that he mentioned there.

He wanted something that called out to the simplicity in all of us. And this release has a lot of things in it that kind of lend to that theme, like removing all of those in-tree cloud providers. There's a couple of other in-tree provider removals. And so a lot of that lends to how we're trying to simplify Kubernetes for the future.

ABDEL SGHIOUAR: Yeah, make things simple. I think what's pretty interesting for me in this is Angelos is from Greece, and Kubernetes is arguably a Greek term. Right?

KASLIN FIELDS: That it is. Comes from the Greek word at least.

ABDEL SGHIOUAR: I guess I was expecting something different.

KASLIN FIELDS: That's a fair point.

ABDEL SGHIOUAR: I don't know what I was expecting. I was just expecting something different.

KASLIN FIELDS: Something Greek.

ABDEL SGHIOUAR: Something Greek, yeah. Plus, I think Kubernetes itself is still a complicated term for a lot of people to pronounce, so probably something simpler, like Elli, is easier.

KASLIN FIELDS: Yeah. One of my favorite things in Intro to Kubernetes talks that I give is the fun fact that Kubernetes comes from the Greek word for "helmsman," and it is the root of the English words "cybernetic" and "governor."

ABDEL SGHIOUAR: Oh, I did not know that second part, by the way. I did not know that. Cool. Well, you live and learn.

KASLIN FIELDS: Yeah.

ABDEL SGHIOUAR: Nice. Awesome. And then there was, I think, one last thing-- well, one thing I wanted to mention. You spent quite a lot of time talking about this dynamic resource allocation, which is mostly about stuff being done in Kubernetes towards supporting AI workloads with accelerators. And it feels like now every single time we talk about Kubernetes, we talk about AI, so bear with us. I find that very interesting. It's still a KEP. It's not there yet. I think just Angelos wanted to give a shout out to the community because they're doing some really good job there.

KASLIN FIELDS: Yeah, we'll see how much of that makes it in. It's probably a longer-term effort. There's a lot of these things that take a while to get fully integrated into the project. And one thing on the AI in Kubernetes thing-- of course, it's very topical, and everybody's talking about AI, and it's very frustrating in that way. But I also love how in our 10-year anniversary episodes, we showed how it's really calling back to the roots of Kubernetes because Borg itself was originally created to run batch workloads and AI-style workloads within Google.

And so it's really at the core of Kubernetes itself to run these kinds of workloads. So it's addressing a lot of the challenges from the early days of Kubernetes that just didn't make it in for a very long time. So I'm excited to see things like this dynamic resource allocation and ways that Kubernetes is going to better utilize hardware. At its root, it's a distributed computing platform. You have a whole lot of computers, a whole lot of hardware, and you got to run the stuff on them.

ABDEL SGHIOUAR: Yeah. And also back to the point you talked about the 10-year anniversary episodes-- and this overall topic of AI being-- I think that everybody is talking about. Fundamentally, it's still the very basic stuff that everybody needs to know. At the bottom of it, it's fundamentally the same problems we need to solve. It doesn't matter which workloads you're actually working on, I would say. So it still goes back to the same fundamentals of distributed computing anyway, so--

KASLIN FIELDS: One of my favorite things actually that I've learned as I've been studying AI-- I did a talk with Mofi, my teammate, who has been a guest host on the show a couple of times at KubeCon about AI workloads on Kubernetes. And the core of that talk was about how when you are sharing resources for a workload, you're not usually really sharing a piece of that resource. At least if you think about CPU, and you're giving some process on that machine x percentage of the CPU, or so many cycles, or however you want to describe the partitioning of the CPU, what you're actually doing is time.

You're distributing the time of the CPU. It'll do one thing, and then it'll do another thing. It's not actually multitasking, just like humans can't really multitask. It's doing one thing at a time, just very, very fast. And so when you look into the hardware considerations of Kubernetes, it's amazing how that comes into play at these higher levels of application management on the systems. You really have to get into the weeds of how the hardware is actually going to do the work in order to distribute it effectively. And so this is an opportunity that I haven't really had as deeply in my career to dive into the internals of how computers work.

ABDEL SGHIOUAR: I mean, as you said, to me, it just always goes back to this is the basics. It's stuff that we have done before. We just need to do them in a different way, but it's stuff that are not really changing that much. You are changing the way we're using Kubernetes, probably, but fundamentally, the problems will kind of remain the same.

There are probably some stuff specific to how you handle GPUs and how you handle GPU failure, which I think we're going to address at some point with one of our episodes, and we'll get an opportunity to dive into that. But it's pretty interesting. I was actually reading through that KEP, by the way, and I was like, well, that's actually a bunch of stuff that already existed with new ways of looking at things. So I'll be definitely keeping an eye on this one because it looks interesting.

KASLIN FIELDS: Yeah, that is a common theme, isn't it? It's like, these things have been around. We just haven't really been implementing them because they haven't been as important.

ABDEL SGHIOUAR: Exactly.

KASLIN FIELDS: But bring it back to 1.31-- so I think that's very descriptive of what the release has in it. We've got some simplification, we've got some removal of some of the in-tree providers. And definitely look into operators and custom resource definitions. I think we love those, at least I love those. They can get a little complicated, but I love the model of implementing those things outside of the tree of Kubernetes.

So definitely look into which ones are being removed if you might need to use those. For a lot of folks, it's going to be your cloud provider takes care of this stuff for you because it's removal of cloud provider code. So if you're using a managed service, like GKE, or EKS, or AKS, a lot of that is handled for you. So there shouldn't be a lot of breaking changes in 1.31, so I hope folks will be able to pick it up quickly. But check it out. I love how it simplifies Kubernetes a little bit by removing-- what was it-- a million lines of code?

ABDEL SGHIOUAR: Yeah, it's crazy. It's a lot. So yeah, definitely check it out. And there will be more blogs coming out, of course, talking about the specific features, and every detail, and every single update, or removal, or deprecation. So yeah, there will be a lot of details to dive into.

KASLIN FIELDS: Keep an eye on those features, and we'll update you again on the next release episode. Look forward to 1.32.

ABDEL SGHIOUAR: Awesome.

KASLIN FIELDS: Thank you.

[MUSIC PLAYING]

That brings us to the end of another episode. If you enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on social media @KubernetesPod, or reach us by email at <kubernetespodcast@google.com>.

You can also check out the website at kubernetespodcast.com, where you'll find transcripts, show notes, and links to subscribe. Please consider rating us in your podcast player so we can help more people find and enjoy the show. Thanks for listening, and we'll see you next time.

[MUSIC PLAYING]