← Kubernetes Podcast from Google
Kubernetes Podcast from Google
Kubernetes v1.31: "Elli", with Angelos Kolaitis
00:42:50
Guest is , Angelos is a senior Software 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 v1.26. Do you have...
Loading summary
Transcript96 lines
- [00:00]
Kaslan Fields
Hello and welcome to the Kubernetes podcast from Google. I'm your host, Kaslan Fields.
- [00:05]
Abdel Sigewar
And I am Abdel Sigewar.
- [00:17]
Kaslan 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.
- [00:32]
Abdel Sigewar
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's lighter weight enables it to be more cost effective in its resource utilization and to run on a wider variety of hardware.
- [00:51]
Kaslan Fields
AWS is discontinuing some services under its new leadership. The cloud providers stopped allowing new resources to be provisioned for products like CodeCommun, Cloud Search and Cloud9. Check out the link in the show notes for more information.
- [01:05]
Abdel Sigewar
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 Macs 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.
- [01:34]
Kaslan Fields
And that's the news. Welcome to our Kubernetes 1.31 release episode and I am excited today to be interviewing the Release lead for 1.31, Angelos Collaitis. 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.
- [02:00]
Angelos Kolaitis
Hi Kathleen. Hi everyone. Super glad to be here and talk about Kubernetes.
- [02:05]
Kaslan 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 notice 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?
- [02:23]
Angelos Kolaitis
Sure. So in general, the nice thing about the release team is that it has this shadow program where essentially everyone from the community is able to apply to become a shadow at the start of its release. So for me it started around 126 where I applied for a number of roles. I was very lucky to be selected as a shadow for the back triage team. So it was in 126 I was a shadow for that team. Then for 127 I was nominated to lead the team actually, which was, you know, to me already, it was actually like an honor. Yeah. Honestly. So from that then after that I thought most likely, yeah, okay, that was nice. Two releases that I helped the competitive team. Great, 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 okay, very exciting to me. So I was a release lead Shadow for three releases pretty much from 128 to 130, which was again, a very nice experience at lots of things about the project. You know, 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 to, you know, people see a Kubernetes release, they don't really see all of the making of the sausage, let's say. So it was a great experience, you know, to be part of this team and see how this thing comes to be. Yeah. At the end of 130, Catcos group, they released lead for 1:30. Basically we met at Kubecon and she said, hey, I wanted to ask you something. And I was like, okay, is everything okay? Do you need me, anything? Do you need anything? And she said, yeah, did you like to lead the 131 release? Which I said, okay, yeah, that sounds. That sounds great. You know, how much time is this going to take from me and from work? Nothing to worry about. You know, 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.
- [04:22]
Kaslan Fields
A very prudent question to ask when asked to take on new responsibility.
- [04:27]
Angelos Kolaitis
Right.
- [04:28]
Kaslan Fields
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, were you involved with Kubernetes at all?
- [04:43]
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. Right? So if we have a bug, we report the issue, we try to share production steps, or if we had the bug fix even, we would share it upstream. And it was a great experience for me. You know, 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, you know, brought this, let's say, spirit of contributing. So from that time it's not just open second Kubernetes, it's been more projects, even small projects on GitHub where, you know, some issue, 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, you know, accept the bug fix for that. And it's quite nice. And it's also, you know, in line with the spirit of open source in general, where, you know, 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's lots of discussions about, okay, what does it mean for a project to be open source? There is 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.
- [06:26]
Kaslan Fields
Wonderful. Of course, open source is one of the major topics of this podcast. We just had a really nice conversation, 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 in one word, I think.
- [06:54]
Angelos Kolaitis
I would start with a bit stressful. Being the release lead, there's probably quite a few things you have to be aware of. There's a 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 emeritus advisor that can help you in many ways, but there's also quite a few things that are left to your judgment. So as a 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, 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 and you know very well 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 where 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 you know, in the proper way. But we're able to deal with them and they never even got out of a small discussion of let's deal with that, let's find the solution for this and we were able to sort things out. So this honestly for me, I want to really say once again, I've been saying this in the release team meetings, I think for the past two or three weeks. I really want to repeat that. Thank you all for the release team. Thank you everyone. It's been a blessing to have you on the team.
- [08:42]
Kaslan Fields
I love the way that you highlight the leadership there.
- [08:46]
Angelos Kolaitis
Right. And the final thing is that I've also had myself like very good mentors. So the three previous release leads, Priyanka, Grace and Kath, they have been there for me since like they -10, before even the release 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 world, how has it been? It's been stressful but also very rewarding and very exciting.
- [09:18]
Kaslan Fields
Well, that's three words but you know, such as 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're 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.
- [10:04]
Angelos Kolaitis
Couldn't have said it better myself. Yeah.
- [10:09]
Kaslan 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?
- [10:21]
Angelos Kolaitis
The Release theme for 1.31 is a simple one. It's basically one word. Ellie. 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, Eli is a Greek name and it has a node. It basically means, you know, 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, you know, the nice caps that people volunteers in the. In the Kubecon stand 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. Simply is people tend to like simple things because it's easier to identify with them. It's a lot simpler to grasp. So the logo itself is like a very simple picture of, you know, a happy dog. Most people will probably have this mental image already in some way or another. So, you know, it's easy to see that and recognize that and why it's joyful. The other thing. So for me, since my first coupon, 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 caps that are added in. There is also lots 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, you know, thankless like tasks, as we usually call them. And even through that, you know, you go to a tube gun and you see, 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 coupon, really, for like five or six months. They're all very, let's say, prideful of, you know, what they do. And they're very happy to contribute to open source. They're very happy to, you know, like, help towards this direction. Just as a side note, you know, like, what is the value of open source itself? It's that you democratize access to technology, right? You make it possible so that everyone can benefit from something. So to be able to witness a big number and even bigger every coupon 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, you know, like to have the logo reflect for this release. And it's also what I've seen, you know, like 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.
- [13:36]
Kaslan 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 blogs 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.
- [14:27]
Angelos Kolaitis
Yeah, indeed. I think simply 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 most use cases, most common use cases. That's how Kubernetes appears to end users.
- [14:43]
Kaslan Fields
And we got to be ambitious with our releases. If we're going to go for simplicity, we got to go for it.
- [14:48]
Angelos Kolaitis
Exactly.
- [14:49]
Kaslan 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?
- [15:18]
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 entry cloud providers. So cloud providers were essentially added in Kubernetes at a very old time. It was probably 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 intra to out of three 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 core of Kubernetes. Have Kubernetes focus on the, you know, reconcile the state of my deployment with what I want it to be, the desired state, and pretty much leave all of the implementation of the extra source outside of it. Because I will justify Kubernetes says 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 that keep terminated both 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 sort of debugging tool where you might have some pods that are failing and they dismount some volumes and if the pod fails, you want 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, 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, you know, using them daily, let's say. But yeah, if you know what this is, you know the gist, 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're having in 131. Just a note for listeners, please go over the release notes to make sure that you are not affected by this.
- [18:55]
Kaslan 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 entry cloud providers. I'm a big fan of this work. We've had, I think, a couple of episodes where we've talked a little bit about entry versus out of tree code in Kubernetes and it's. It's one of the ways that we try to keep kubernetes simpler. One of the big issues with entry 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, right?
- [20:04]
Angelos Kolaitis
Exactly. And to add to 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 Intrigue providers. So it's also one of the, as you said, simplicity in the out of three providers themselves, because they can much more easily iterate and improve and support new features of the providers themselves.
- [20:41]
Kaslan 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 Intrigue 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 entry providers, 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 so like every release.
- [21:49]
Angelos Kolaitis
There'S new features that are being added. I think we are tracking around 44 to 45. I don't remember the exact number of caps 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, you know, other mediums. But in general the thing I would like to highlight is there is great work coming from signal for this release. In particular I would like to highlight DRA dynamic resource allocation. 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 would be accelerated networking hardware, that would be all kinds of things. So 1.31, 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 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 gain 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. You don't see how the service make sure that traffic is related to your healthy pods. You don't get to see how a 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'll 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, you know, I just want to highlight this because it's. It's maybe, you know, calling back to the thankless work that we talked about earlier, where no one is probably going to see this. People in the release notes will be probably skipping over that. But these will have. I think this will have great effects on, you know, like, so many deployments around the world. So kudos to the folks that are, you know, doing this work behind the scenes and making sure that Kubernetes is actually stable platform for people to run their workloads on.
- [24:56]
Kaslan 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?
- [26:17]
Angelos Kolaitis
Okay, well, to start with, please don't upgrade your clusters, because someone said so in a podcast. You know, as always, the procedure is absolutely, please go over the release notes, make sure that you're not using any of the deprecated or remote features, and make sure that, you know, you're following the right procedure to upgrade. But in general, you know, upgrades can be tough. But there's I think, one or two points for one step. One, specifically, as we said, there's 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 are 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 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 that 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 project 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 131, but precisely because 131 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.
- [28:30]
Kaslan 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 work 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.
- [29:09]
Angelos Kolaitis
And Matthew also adds 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 feedback and say, hey, the array is working well for us in these situations, or maybe this part of the design is not exactly what we 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 you're 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 save what the outcome will be. I would very much recommend that people take this route, if possible.
- [30:04]
Kaslan Fields
Absolutely. And with that, any final words for our listeners?
- [30:08]
Angelos Kolaitis
First of all, Kathleen, 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, you know, work on solutions across, you know, from the diversity, across different cultures, across different companies, across different vendors. You know, 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're interested, if you have ideas, if you have aspirations, if you want to actually, you know, like, 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, you know, give back to open source. Like, 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, you know, contribute a small piece here or a small piece there and, you know, make these others 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.
- [31:33]
Kaslan Fields
Absolutely. I think that makes a lot of sense.
- [31:35]
Angelos Kolaitis
Like, don't be afraid.
- [31:37]
Kaslan 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.
- [32:24]
Angelos Kolaitis
Thank you, Kathleen, for having me, and thank you all for listening.
- [32:29]
Abdel Sigewar
All right, well, thank you, Kathleen, for that interview. That was, as usual, pretty good and pretty interesting, actually.
- [32:34]
Kaslan Fields
I mean, release episodes are always some of our best episodes. Right. It's nice to have that kind of consistent checkpoint on the community and what's going on.
- [32:43]
Abdel Sigewar
Yeah. And I'm very grateful for Angelos being pretty flexible because we basically pinged him quite last minute and we kind of have had to work through some hurdles to schedule that one to get it on the schedule.
- [32:55]
Kaslan Fields
So we've done worse. Yeah, we have done release episodes, I think on shorter schedules, but we're certainly getting better at it.
- [33:05]
Abdel Sigewar
Yeah, we've done one. I think you've done one at Kubecon. Right. I remember it was 1:30 or something.
- [33:09]
Kaslan Fields
We did. Yeah, yeah.
- [33:10]
Abdel Sigewar
The one with Kat.
- [33:11]
Kaslan 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 like 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. Like, things should be pretty stable and relevant, but before the release. So it's always a little tricky to figure out the timing. Yeah. But we've got removals and deprecations as kind of 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 Intrigue cloud providers for like multiple releases.
- [34:10]
Abdel Sigewar
Exactly.
- [34:11]
Kaslan Fields
And now it's really being complete.
- [34:15]
Abdel Sigewar
Yeah. And the theme, Eli.
- [34:17]
Kaslan Fields
Yes.
- [34:18]
Abdel Sigewar
What can you tell us about the theme?
- [34:20]
Kaslan Fields
It is very cute. He sent me the picture of the release theme. It's not out yet at time of recording, so I hope it will be.
- [34:30]
Abdel Sigewar
Out by the time I publish this.
- [34:32]
Kaslan Fields
Yeah, it should be out, hopefully. So. But Abdel, I don't know if you saw it, I don't know if you sent it directly to me, but it is a very cute little dog.
- [34:41]
Abdel Sigewar
He sent it to both of us. Right.
- [34:42]
Kaslan Fields
I thought it was okay.
- [34:43]
Abdel Sigewar
Yeah, it's a little dog with a helm and a little marine hat.
- [34:49]
Kaslan 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 the 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 entry cloud providers. There's a couple of other entry provider removals. And so a lot of that kind of lends to how we're trying to simplify Kubernetes for the future.
- [35:35]
Abdel Sigewar
Yeah. Make things simple. I think what's pretty interesting for me in this is Angelus is from Greece and kubernetes is arguably a Greek term. Right.
- [35:43]
Kaslan Fields
So that it is. Comes from the Greek word at least.
- [35:47]
Abdel Sigewar
I guess I was expecting something different.
- [35:51]
Kaslan Fields
You know, That's a fair point.
- [35:52]
Abdel Sigewar
I don't know what I was expecting. I was just expecting something different.
- [35:55]
Kaslan Fields
Something Greek.
- [35:56]
Abdel Sigewar
Something Greek.
- [35:57]
Angelos Kolaitis
Yeah.
- [35:57]
Abdel Sigewar
But I think kubernetes itself is still a complicated term for a lot of people to pronounce, so probably something simpler like Ellie is easier.
- [36:05]
Kaslan 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.
- [36:19]
Abdel Sigewar
Oh, I did not know that second part, by the way. Yeah, I did not know that. Okay, cool. Well, you live and learn.
- [36:26]
Kaslan Fields
Yeah.
- [36:27]
Abdel Sigewar
Nice. Nice. Awesome. And then there was, I think, one last thing, one thing I want 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.
- [36:42]
Kaslan Fields
Right.
- [36:42]
Abdel Sigewar
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 cap. 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.
- [36:55]
Kaslan Fields
Yeah, we'll see how much of that makes it in. It's probably a longer term effort. You know, 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.
- [37:48]
Abdel Sigewar
Yes, yes.
- [37:49]
Kaslan Fields
At its root it's a distributed computing platform.
- [37:52]
Abdel Sigewar
Yes.
- [37:52]
Kaslan Fields
You have a whole lot of computers, a whole lot of hardware and you got to run the stuff on them. Yeah.
- [37:57]
Abdel Sigewar
And also back to the point, you Talked about the 10 years anniversary episodes and this overall topic of AI being a thing that everybody's talking about. Fundamentally, it's still the very basic stuff that everybody needs to know. Like 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.
- [38:19]
Kaslan Fields
Anyway, one of my favorite things actually that I've learned as I've been studying AI, I did a talk with Mophie, my teammate, who has been a guest host on the show a couple of times at Kubecon, about AI workloads on Kubernetes. And kind of 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 like if you think about CPU and you're giving some process on that machine, X percentage of the CPU or so many cycles or whatever. However you want to describe the partitioning of the cpu, what you're actually doing is time.
- [39:02]
Abdel Sigewar
Yes.
- [39:02]
Kaslan Fields
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 kind of really have to get into the weeds of how the hardware is actually going to do the work in order to distribute it effectively.
- [39:38]
Abdel Sigewar
Yes.
- [39:39]
Kaslan Fields
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.
- [39:47]
Abdel Sigewar
I mean, as you said, like, to me it just always goes back to like, this is the basics, right? Like, 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. We're 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 gonna 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 cap, 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.
- [40:32]
Kaslan 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.
- [40:39]
Abdel Sigewar
Exactly, exactly.
- [40:41]
Kaslan 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 entry 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 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 like if you're using a managed service like GKE or EKS or aks, a lot of that is kind of 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.
- [41:40]
Abdel Sigewar
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 in every single update or removal or deprecation. So yeah, there will be a lot of details to dive into.
- [41:55]
Kaslan Fields
Keep an eye on those features and we'll update you again on the next release episode. Look forward to 1.32.
- [42:03]
Abdel Sigewar
Awesome.
- [42:04]
Kaslan Fields
Thank you. 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 Kubernetes Pod or reach us by email@kubernetespodcastgoogle.com you can also check out the website@kubernetespodcast.com where you'll find transcripts, show notes and links. To subscribe, please consider writing 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.