Loading summary
Transcript47 lines
- [00:00]
A
Hi and welcome to the Kubernetes podcast from Google. I'm your host Abdel Sighiwar.
- [00:05]
B
And I'm Kazlen Fields.
- [00:16]
A
In this episode we speak to Ryota Sawada. Ryota is a software engineer at Noomtide and the release lead for Kubernetes 1.36 codename 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,
- [00:36]
B
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.
- [01:06]
A
MergeForward 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 OSS and advance their careers. Check the link in the description for more information on how to join and help make the future of oss and sustainable.
- [01:27]
B
TruePositive 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 cloud formation. And that's the news.
- [01:47]
A
Ryota is a software engineer at Noomtide and the release lead for Kubernetes 1.36 codename 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.
- [02:06]
C
Thank you very much for having me. Pleasure to be here.
- [02:09]
A
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 the release, but we couldn't make it happen this time, which is completely fine. But the thing I think with 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 in a way. And with that I want to start first with the theme Haru. And there is a cat. So what's the thinking process there?
- [02:38]
C
Absolutely. So I would go from bit by bit. So haru is a Japanese word and most commonly associated with the word spring. And at the same time it also captures, 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 like 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 and towards the end of the cycle. But the actual theme, the idea was in Inception really much earlier. And this release being 1.36, I thought of 36 is one keyword that I wanted to incorporate. And 36 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, have the integration between the two. So 36, meaning 36 views of Mount Fuji is probably the most famous artwork and kind of the series of artwork from Hokusai. And most notable piece that you see around from that series is the Great Wave of Kanagawa, which happens to be where I'm from. But I didn't want to do too much of a cliche, so went to something slightly different. And I wanted to have a kind of bright theme and that kind of ties into the name Haru being spring. And at the same time, the actual red Fuji that the logo is based on is from early summer, close enough this spring. I think the timing of the release coming out in April was like, okay, that's a bit of a stretch, but I think that's okay.
- [04:31]
A
Awesome.
- [04:32]
C
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 anything, I guess. But at the same time, we knew that it would be a bright future ahead, bright season ahead of us. So that's just kind of idea about Haru. 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 kind of similar in many releases. And as far as I'm aware, pretty much every release is essentially the same in 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. 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 the logo came about.
- [06:01]
A
Awesome. I was about to ask you about the cats. So these are your cats. And then there is the. The mountain, Mount Fuji in the background and then the kind of Kubernetes wheel. I mean, the logo looks amazing. Whoever designed it, good job. It's great.
- [06:15]
C
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 hand it out people if I see anyone around.
- [06:40]
A
Awesome. Well, I have a spot on my laptop for a sticker. I'm always a sucker for a release sticker.
- [06:45]
C
Amazing. At some point then.
- [06:47]
A
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 details.
- [06:54]
C
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 kept is, as far as I'm aware, is the highest in 136. So it's over 70 in this release and we've never hit 70 as a part of the actual release. We had over 100 Keps that were tracked originally when the release started. All the SIGs, contributors and maintainers were listing up all the keps that they wanted to integrate to have it as a part of the 136. And it was over 100. That happened in 135 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 is 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 a 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 and 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 kind of deep dive into and 1.36 really landing it as a GA general availability, 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.
- [09:11]
A
Yeah, it's quite interesting. I was actually looking through the release notes and there is clearly a couple of trends, I would say, or a couple of themes like the. 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 of Kubernetes and we plan to explore that as its own episodes. But there was like two that kind of 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 like kind of like a rundown of what it is you can talk about?
- [09:59]
C
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 kept, we had three topics 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 was. I'm not sure, but. 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 ports available and it just kind of starts up gradually. The gang scheduling is one that we introduced in the recent releases. I think it was 134.
- [10:57]
A
55 or something.
- [10:58]
C
I think it was 5 if I remember correctly.
- [11:00]
A
Yeah.
- [11:01]
C
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 the scheduling actually happens. And that really landed with the earlier release 1.35. But also it meant that it asked the question, is this the right format? Is this the right way that we want to actually manage the ports that the scheduling and this workload API and also portgroup API give us more control and more clarity as to workload API is the template that you can use and port group is the actual more towards the port scheduling. So you can see in the 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 will 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 a third party solutions to use to be supported by Kubernetes natively.
- [12:43]
A
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 the 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 can. You might get like inconsistent results when you're trying to query the pods. Right. 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 kind of 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.
- [13:23]
C
That's correct. And I think from my point of view, in the previous experience that I had with Kubernetes, I never had the need of doing this port group kind of a transactional scheduling where you have 10 ports or zero port. I never personally needed that for applications where I just needed some reliability. Then you just have three ports or five ports 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 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 deployments or statefulset or daemonset, whatever that may be. That's really depending on your 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.
- [14:49]
A
Yeah. And the fact that this have been in the spotlight of the key updates, there is like three of them and this is one. It just means that it's significant. From my perspective, it means it's significant.
- [14:58]
C
Absolutely.
- [14:59]
A
And then I think this is something we spoke about a lot. DRA going stable, like 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 like how dynamically do you associate hardware to pods? What's your thoughts? I'm curious to hear your thoughts about that.
- [15:23]
C
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 hardwares that you have and DRA is a significant chunk of work. It's not just that a DRA going stable, everything is great, everything is ready to use. It's not exactly that there are so much much happening around DRA and the part of one significant part or a few areas of the DRA is going stable and 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, easy kind of ease of use and ease of management. I think that's still kind of 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, 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 like a hardware like 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 AIML 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 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.
- [17:45]
A
Yeah, I mean there is. I mean you touched on a very interesting point about dra that the API is one thing, but also all the underlying integrations is a different thing. Right? Like just at Kubecon this year we saw Nvidia and Google releasing their drivers for GPU and GPUs 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 nick pods. Right. Having a pod being able to spin up and say I want to have a network interface in this and this 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 as the Storage API as far as it's concerned. You as developer explain what you want, what are 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 one to one 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.
- [19:06]
C
Right, Absolutely, yeah.
- [19:08]
A
And with this I would refer back to an episode actually we did with Antonio about this Antonio Gea where we explored this topic even further, which was we touch about DRA quite a lot and he has a lot of opinions about that.
- [19:19]
C
Cool.
- [19:19]
A
So what have been your experience? This is your first time as a release lead, right?
- [19:23]
C
That's correct.
- [19:24]
A
But I assume you've been release Shadow before because that's kind of like the evolution, right?
- [19:29]
C
Yeah, so I can definitely touch on that. But yeah, I've been around on the release team for from 132 now. So it's been 451-323-456. So quite a few releases so far.
- [19:41]
A
All right. And so what have been your experience? Like 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?
- [19:51]
C
Yeah, absolutely. So I think it's difficult to put into, you know, a short sentence, but I think one word that sticks out is exciting and exciting in a sense that I get to work on things like projects that I deeply care about and do use very often right now. Like 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 kind of making sure that everyone is aware of the release timeline and making sure that everything is 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, that's 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 like 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 a just kind of 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. I think 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 a 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.
- [22:24]
A
Awesome. Awesome. So I think I have one departing question for you. Why should people upgrade to 1.36?
- [22:31]
C
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 120 when the release is made like 1.36 or 37. It doesn't mean that the 1.35 is no longer available or deprecated that you should not be using it. It's more that it is a gated and also properly scheduled release each release. So 136 came out in this April timeline, 135 towards the end of the year last year 134 just around the summertime and and we can expect 137 to be in the summertime, 138 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.35 upgrades to make sure that you get the most up to date PAPs APIs and some extra supports that you can get. For instance workload away 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 as 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 kind of jump start 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 1.3 releases still supported and we have the patch releases going out every so often for 1.34 and 136 going forward by 1.37 is to start in a week or so. So 137 will be I think the schedule to land around the summertime so still some time to go but definitely to keep an eye on the 136 and the patch releases, making sure that you're most up to date, making sure your workloads are secure, stable, reliable and also you get some nice teeth around maybe workload of your scheduling maybe DRAs. So yeah, why not upgrade when you can. Nice.
- [25:38]
A
Awesome. Yeah, we're 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 like key features that are coming out. So there's like even more of them now, which is actually great because then you can go deep dive into each kind of feature and figure out what it means. So definitely. Well Ryota, thank you so much for your time. This was great.
- [26:01]
C
Thank you very much for having me. That was a pleasure to be here.
- [26:04]
A
And we'll leave your links for social media on the show notes. Thank you for your time and have a good day.
- [26:08]
C
Thank you. Cheers.
- [26:12]
B
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 Ubernetespod or reach us by email at kubernetespodcastgoogle.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.