ABDEL SGHIOUAR: Hi, and welcome to the "Kubernetes Podcast" from Google. I'm your host, Abdel Sghiouar.

KASLIN FIELDS: And I'm Kaslin Fields.

[MUSIC PLAYING]

ABDEL SGHIOUAR: In this episode, we speak to Ryota Sawada. Ryota is a software engineer at Noontide and the release lead for Kubernetes 1.36, codenamed Haru. He has over a decade of experience, mainly in the financial industry, including working on cloud-native technologies. And outside of cloud native, he's been tinkering with Emacs and Nix.

KASLIN FIELDS: But first, let's get to the news. SIG etcd announced availability of the first beta of etcd 3.7.0. This new version comes with the long-requested range-stream feature. It also includes some refactoring and cleanup of multiple legacy components and interfaces. Version 3.7 will deliver improved security, better operational reliability, and an improved experience for working with large result sets.

ABDEL SGHIOUAR: Merge forward is a CNCF initiative aiming to secure the future of open source by solving the maintainer deficit through diversity. The community is home to seven underrepresented groups and provides safe spaces to help them contribute to and advance their careers. Check the link in the description for more information on how to join and help make the future of sustainable.

KASLIN FIELDS: True Positive is a CLI that helps link apps running in production to their source in GitHub. It tags all your infrastructure with Git metadata, like commit SHA, branch, and repo. It requires zero config and works with Terraform and AWS CloudFormation. And that's the news.

ABDEL SGHIOUAR: Ryota is a software engineer at Noontide and the release lead for Kubernetes 1.36, codenamed Haru. He has over a decade of experience, mainly in the financial industry, including working on cloud-native technologies, and outside of that, he's been tinkering with Emacs and Nix, which I'm going to ask him questions about. Welcome to the show, Ryota.

RYOTA SAWADA: Thank you very much for having me. Pleasure to be here.

ABDEL SGHIOUAR: All right. So in true "Kubernetes Podcast" fashion, we interview the release leads for each version. Usually we time it such a way that we have it at the day of release, but we couldn't make it happen this time, which is completely fine.

But the thing I think with the Kubernetes releases is that they come out, and then people start looking at them later. So I think regardless of what we're going to talk about, it's going to be useful anyway. And with that, I want to start first with the theme, Haru, and there is a cat. So what's the thinking process there?

RYOTA SAWADA: Absolutely. So I would go from bits by bits. So Haru is a Japanese word, and most commonly associated with the word, spring, and at the same time, it also captures [JAPANESE], which means sunny and clear skies, and haruka is for, far off and distant. So it's like three meanings in one. And I thought that's a nice addition of how it's not always one thing that you're looking at. It's more that there are so many ways to look at one thing.

And the name itself was decided towards the latter half, towards the end of the cycle. But the actual theme, the idea, was in inception, really, much earlier. And this release being 136, I thought of-- 36 is one keyword that I wanted to incorporate. And "Thirty-six Views of Mount Fuji" was just an easy segue, I guess, for me to find the reference with Kubernetes and 1.36 being one of the most important, at least for me, release. And also being my background of being Japanese and growing up there, I wanted to kind of collaborate and have the integration between the two.

So 36 meaning-- "Thirty-six Views of Mount Fuji" is probably the most famous artwork and the series of artwork from Hokusai. And most notable piece that you see around from that series is the "Great Wave off Kanagawa," which happens to be where I'm from. But I didn't want to do too much of a cliche, so I went to something slightly different.

And I wanted to have a bright theme. And that ties into the name, Haru, being spring. At the same time, the actual "Red Fuji" that the logo is based on is from early summer, close enough to spring. I think the timing of the release coming out in April was like, OK, that's a bit of a stretch, but I think that's OK.

And the release started in January when it was very gray and it was very cold. Especially at least in the UK. In London, it's not the greatest time to start the-- start anything, I guess. But at the same time, we knew that it would be a bright future ahead, a bright season ahead of us. So that's just idea about how the name came about and wanted to make sure that that Haru, the spring and the clear sky, translates to something that we can look forward to in the future. So, haruka, really fit nicely.

And it's similar in many releases. And as far as I'm aware, pretty much every release is essentially the same in an idea. There's a lot of collaboration and dedication from all fronts, obviously from release team, but not just release team, but it comes from many SIGs and contributors and maintainers and doc collaboration and translation. It's just so many people and so much effort from every front.

So I wanted to celebrate that the milestone of 1.36 is definitely something important for me as a release lead, but also it's not the end. It's definitely a passage. It's definitely something that we can celebrate as a milestone, and we can still look forward to what's to come in 1.37. And I just wanted to have a little bit of a cuteness to it. So I decided to introduce my own cats, Stella and Nacho, to the theme. So that's how that logo came about.

ABDEL SGHIOUAR: Awesome. I was about to ask you about the cats. So these are your cats. And then there is the mountain, Mount Fuji, in the background. And then the Kubernetes wheel. I mean, the logo looks amazing. Whoever designed it, good job. It's great.

RYOTA SAWADA: Yeah, I have to dedicate the praise to Natsuho, who was the designer and the creator of this amazing logo. We had dozens of iterations, so it's all for her dedication and great work. So yeah, thanks to her, it came out really nicely. And yeah, I can't wait to have the stickers and all the swags I will probably create myself and, yeah, hand it out to people if I see anyone around.

ABDEL SGHIOUAR: Awesome. Well, I have a spot on my laptop for a sticker. I'm always a sucker for a release sticker.

RYOTA SAWADA: Amazing. At some point, then.

ABDEL SGHIOUAR: Awesome. All right, so then let's go into it. So what's 1:36? Give us a little bit of an overview before we go a little bit into the details.

RYOTA SAWADA: Absolutely. So I would start with the number. So I have been around in the release team for a while, about a couple of years now. And the number of Kubernetes enhancement proposals caps is, as far as I'm aware-- is the highest in 1.36.

So it's over 70 in this release, and we've never hit 70 as a part of the actual release. We had over a hundred caps that were tracked originally when the release started or the SIGs contributions made-- contributors and maintainers were listing up all the caps that they wanted to integrate, to have it as a part of the 136, and it was over a hundred. That happened in 1.35 and 1.36.

So we can see a gradual increase and definite increase in the, I guess, interest and also the growth in the ecosystem. Although Kubernetes is definitely one of the most mature systems out there, it is still very relevant, and has so much interest from all fronts.

And it ended up with 70 caps, over 70 caps included as a release, which is a significant milestone for the release itself. But also, it's just a sign that it is not slowing down at all. It is still a significant release coming up. And I think 1.37 onwards will be a similar story. But yeah, it's one of the-- I guess the number tells us that it's definitely a story that we should still be following up on.

And in terms of the features, there are so many that I can't list all of them. One of the things that I was personally interested and personally glad to see happen was the user namespaces in pods. That was something that I was looking at for beta release. I think it was 1.33. And that was the time that I was heavily involved in the communication and blog write-up for the release team. So that's something that I had a lot of deep dive into. And 1.36 really landing it as a GA, general availability-- it's the stable release.

So that's one thing that I personally took it as, yes, this is a significant achievement, the milestone that we can celebrate on top of the other 70 or so caps.

ABDEL SGHIOUAR: Yeah, it's quite interesting. I was actually looking through the release notes, and there's clearly a couple of like trends, I would say, or a couple of themes. Like the username spaces in pods-- that's basically kind of aligned with this whole concept of isolation, which is becoming even more important now with agents, that you don't want random agents doing random stuff inside the cluster.

There's also some interesting things. I saw this new workload API which came out. I was talking with Lucy Sweet about it. We just released an episode with her about Uber using Kubernetes, and we plan to explore that as its own episodes. But there was two that jumped to mind for me. There is this new workload-aware scheduling, and honestly, I have no idea what it is. It just went alpha. And I heard people talking about it, but I don't know what it is. Did you have a rundown of what it is you can talk about?

RYOTA SAWADA: Yeah, absolutely. And that's definitely the highlight of the release, and rightly so. It's a part of the release announcement, and it's highlighted as one of the things that we picked up from this particular release. Out of 70 or so caps, we had three top picks, and one of them was-- although alpha, although still very early in the stage, it's still significant that this is something that Kubernetes supports natively.

So workload-aware scheduling, WAS-- some people may call it, "Waas." I'm not sure. So workload-aware scheduling introduces two APIs. One is workload, and another is port group. So before workload-aware scheduling, the scheduling was basically that it's eventual. You have deployment, StatefulSet whatever that may be. You have pods available. And it just starts up gradually. The gang scheduling is one that we introduced in the recent releases. I think it was 1.34 or 5.

ABDEL SGHIOUAR: 5 or something?

RYOTA SAWADA: I think it was 5, if I remember correctly. So gang scheduling is a way to make sure that you have 10 pods or however many pods that you need, all at once, or zero at all. So you have the control on the actual scheduling timing that is very relevant and important for the AI/ML inference and training heavy workloads that you want to have a full control over when scheduling actually happens.

And that really landed with the earlier release, 1.35. But also, it meant that it asks the question, is this the right format? Is this the right way that we want to actually manage the pods, the scheduling? And this workload API and also pod group API give us more control and more clarity as to workload API is the template that you can use, and pod group is the actual-- more towards the port scheduling.

So you can see in two different ways. Well, this is what I want as the template, as the thing that would happen if I were to deploy in the cluster, and pod group would be associated with workload API in a way that you can monitor how things are actually being deployed as group supports.

I think that clarity and that separation is a significant win, and also just gives us another foundation for further improvements and enhancements and also just integration in general that-- although this is an alpha, I think this is such a good stepping stone that it would evolve into something more significant and that can support more use cases that we currently need third-party solutions to use to be supported by Kubernetes natively.

ABDEL SGHIOUAR: Yeah. I was looking into it. And one of the-- I mean, you touched on it, which is AI workloads. One of the common use cases for AI workloads is when you shard a model across multiple pods, you want to be able to make sure that all these pods are either all running or not running because otherwise you might get inconsistent results when you're trying to query the pods or query the application inside the pod.

So it is clearly a new way of thinking about scheduling within Kubernetes, right? It's not the eventual consistent mechanism that we have today with deployments. It's a different input mechanism to the scheduler. And I think-- we have to be clear when we talk about this. This is not meant to replace deployments, right. This is just a new way of doing deployments.

RYOTA SAWADA: That's correct. And I think from my point of view and the previous experience that I had with Kubernetes, I never had the need of doing this port group, a transactional scheduling where you have 10 pods or zero pod. I never personally needed that for applications where I just needed some reliability. Then you just have three pods or five pods.

And then it doesn't matter when the scheduling actually happens. So that scenario shouldn't change. It really depends on what kind of use cases you have. And just the significance of this new alpha workload of our scheduling is to give us the control, the flexibility that we never really had as Kubernetes native support. So that just gives us-- maybe that depending on the use case, depending on the workload, depending on AI/ML inference, that may be the reason that you want to go with a port group way. Or it's possible that you just need a deployment or StatefulSet or DaemonSet, whatever that may be. That's really depending on your use case.

I think Kubernetes being able to support more use cases is definitely one win, and it doesn't take away anything that's been there. And that has been always the case with Kubernetes. Deprecations still happen, but in a way very safe, and still relevant workloads and relevant use cases are kept around so that you can rely on it as a production-ready system.

ABDEL SGHIOUAR: Yeah, and the fact that this have been in the spotlight of the key updates. There is three of them, and this is one. It just means that it's significant. From my perspective, it means it's significant.

RYOTA SAWADA: Absolutely.

ABDEL SGHIOUAR: And then I think-- that this is something we spoke about a lot. DRA going stable, dynamic resource allocation. I have had to explain this to people quite a lot of times. And I think that a lot of times people look at it, and they ignore the fact that it's all in the name. It's dynamic. The whole idea is, how dynamically do you associate hardware to pods? What's your thoughts? I'm curious to hear your thoughts about that.

RYOTA SAWADA: Yeah, so I think many people would have different ideas and opinions about this. And personally-- this is my personal take about the DRA. It is another-- similar to WAS, where you have more flexibility, more native support about the hardware that you have. And DRA is a significant chunk of work. It's not just that DRA going stable, everything is great, everything is ready to use. It's not exactly that. There are so much happening around DRA.

And the part of-- one significant part or a few areas of the DRA is going stable, meaning that it's a stable API that you can rely on. You can have your workloads, and you can have the hardware use cases covered by DRA. But also, in the release announcement, there are areas of the DRA features going beta, and DRA is a big chunk of work that is not everything is fully done. It's still that the evolution is happening around the observability, stability, ease of use and ease of management. I think that's still in its evolution right now.

So I think it is significant to get those hardware and use cases that require particularly GPU usages. I think DRA is really one of the top picks and top features that we have been highlighting in the release announcements for probably three or four releases. I remember writing about it quite a few times.

But at the same time, personally, do I have the use case for it? I personally do not own a hardware, beefy machine myself, so I don't really see myself using it at the moment. But it is going to be relevant for any future use cases related to AI/ML workloads perhaps. Or something that I do have a specific GPU or specific hardware use cases, I would definitely look at DRA and how I can actually integrate it into Kubernetes.

I think that's just one of the things that we can take it as such a nice gift to be able to open it up later if you really wanted to, but at the same time, you don't really have to open it if you don't really need the use of it. So yeah, I think in a way, I'm in the middle of-- I'm excited, but at the same time, do I need it? Personally not.

ABDEL SGHIOUAR: No. Yeah. I mean, you touch on a very interesting point about the DRA, that the API is one thing, but also, all the underlying integrations is a different thing. Just at KubeCon this year, we saw so Nvidia and Google releasing their drivers for GPU and TPUs. And then as we're going forward, there will be more stuff coming out.

I do have, however-- I'm going to talk about this briefly-- one use case which I find interesting, which is not even AI-related. It's just multi-NIC pods. Having a pod, being able to spin up and say, I want to have a network interface in this and these other networks within the cluster is something that actually DRA can be very useful for, assuming, of course, you have the driver that can support that under the hood.

I think that the way I explain it to people is think about it as the evolution of the storage API, which is that the storage API, as far as it's concerned-- you, as a developer, explain what you want, what your requirements for storage are. And then it's up to the cluster admin to provide you these requirements. But you don't really have to understand the underlying implementation. You don't really have to care what kind of storage device or what kind of storage system it is. You just say, oh, give me 10 gigabytes SSD, and that's it, right? So you are dynamically requiring storage, and then the cluster will provision that for you.

Of course, it's not exactly the same thing. It's not a 1-to-1 mapping. But it's kind of the same philosophy, right? Which is making Kubernetes a more dynamic system for requirements for pods, for the underlying infrastructure, whatever that underlying infrastructure is, right?

RYOTA SAWADA: Absolutely.

ABDEL SGHIOUAR: Yeah, and with this, I would refer back to an episode, actually, we did with Antonio about this, Antonio Ojea, where we explored this topic even further, which was-- we talked about DRA quite a lot, and he has a lot of opinions about that. Cool. So what has been your experience-- this is your first time as a release lead, right?

RYOTA SAWADA: That's correct.

ABDEL SGHIOUAR: But I assume you've been a release shadow before because that's kind of the evolution, right?

RYOTA SAWADA: Yeah, so I can definitely touch on that. But yeah, I have been around on the release team from 1.32 now. So it's been 4, 5-- 1.32, 3, 4, 5, 6. So quite a few releases so far.

ABDEL SGHIOUAR: All right. And so what have been your experience-- how have that been coming along? We ask this question often because everybody's experience is different, so I'm curious to hear how is yours.

RYOTA SAWADA: Yeah, absolutely. So I think it's difficult to put into a short sentence. But I think one word that sticks out is, exciting, and exciting in the sense that I get to work on things-- projects that I deeply care about and do use very often. Right now, I'm currently in between jobs, so I'm not, right now, using it, but I have been using Kubernetes, basically, all the time in the past several years.

So working on the release team really means about collaboration and making sure that everyone is aware of the release timeline and making sure that everything's stable to go out so that people can actually rely on with the production workloads to run on Kubernetes.

So it is such an exciting journey to be part of it, to actually produce something that's so significant as Kubernetes to the community, to the world. I think it's one of the largest open-source projects in the world. That itself is exciting. But at the same time, it's such a learning opportunity for me as well, to communicate and collaborate with other teams. It could be a release team, within the release team itself, and also, it could be other SIGs.

So you mentioned Antonio. I talked to him in KubeCon just earlier, about a month ago. That was really exciting, to actually see people who work so hard and so much on making this Kubernetes ecosystem and experience really a great thing, and to be able to actually do something from my end as well to make that kind of contribution and make it as just market as I worked on this.

And this is something that I deeply care about. I am proud that the team has produced the 1.36 milestone. As I said, it's definitely going to be just a stepping stone for 1.37 and onwards. But at the same time, it is something that we can celebrate. And I think the release team experience has been always that. It's such a nice team where everyone works on small, different pieces of the release process, but also, at the end, It's such a significant milestone that we can all celebrate. And that was exactly the same as a release lead-- shadow or shadow in general, and also release lead.

So it's not just an easy task of, oh, you just have to be a part of the team, and you just have your name there. It's more than that, obviously. But at the same time, it's such an engaging, exciting and rewarding experience that, yeah, i would definitely cherish and I would definitely recommend for people to check out.

ABDEL SGHIOUAR: Awesome. So I think I have one departure question for you. Why should people upgrade to 1.36?

RYOTA SAWADA: Yeah, it's a very difficult question, I have to say, to answer. And what I would say is that you do not have to upgrade to 1.36 right away. And it is something that Kubernetes really cares about, where when the release is made, like 1.36 or 37, it doesn't mean that the 1.5 is no longer available or deprecated or you should not be using it. It's more that it is a gated and also properly scheduled release each release.

So 1.336 came out in this April timeline, 1.5 towards the end of the year last year, 1.4 just around the summer time, and we can expect 1.37 to be in the summertime, 1.38 to be towards the end of the year. So three releases a year.

So three releases in a year also correlates to the three releases are the supported releases from the Kubernetes perspective. So if you're falling behind with 1.33 still lying around, obviously, you should look into 1.34 and 1.335 upgrades to make sure that you get the most up-to-date, perhaps, APIs, and some extra supports that you can get.

For instance, workload-aware scheduling that we talked about, or DRA-- those are definitely some of the tools that some people need and they want to upgrade right away as the release happens. But at the same time, you do want to make sure that you are kept up to date with the security enhancements and observability updates.

One of the things that I would say is 1.36 had quite a few observability-related changes and enhancements. One of the things that we highlighted at the top of the release announcement was the fine-grained API authorization that relates to observability and security. So obviously, the recent release has been trying to make sure that all the workloads and all the use cases are covered for the future workloads that we expect to happen around, perhaps, AI/ML or other areas.

So being on top of the latest release would give you that edge and also would give you the jumpstart into the new features and new use cases. But at the same time, there are nice-- more than nice-- great additions of security enhancement, observability enhancements, and just extra stability in general, reliability in general that just sets apart that you should be looking at upgrading when you can.

You still have some time. As I said, it's [? three ?] release is still supported, and we have the patch releases going out every so often for 1.34, 35, and 1.36 going forward. But 1.37 is to start in a week or so, so 1.37 will be, I think, scheduled to land around the summer time. So still some time to go. But definitely to keep eye on the 1.36 and the patch releases, making sure that your most up to date, making sure your workloads are secure, stable, reliable. And also, you get some nice tease around maybe workload-aware scheduling, maybe DRAs. So yeah, why not upgrade when you can?

ABDEL SGHIOUAR: Nice, awesome. Yeah, well, I'm definitely going to leave a link to the release details. And I noticed something also, that they are starting to write more and more articles on the Kubernetes blog about each of these key features that are coming out. So there's even more of them now, which is actually great because then you can go deep dive into each feature and figure out what it means. So definitely. Well, Ryota, thank you so much for your time. This was great.

RYOTA SAWADA: Thank you very much for having me. That was a pleasure to be here.

ABDEL SGHIOUAR: And we'll leave your links for social media on the show notes. Thank you for your time, and have a good day.

RYOTA SAWADA: Thank you. Cheers.

KASLIN FIELDS: 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 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]