Helm 4 Is Here. So, Now What? - Andrew Block, Red Hat; Scott Rigby, Replicated; Robert Sirchia, SUSE

This talk focuses on the release of Helm 4, a significant update in the popular Kubernetes package manager that introduces several new features and improvements. The speakers discuss the new Wasm-based plugin engine that coexists with the existing plugin structure, server-side apply capabilities, and the implementation of chart status. They clarify that there are no breaking changes to chart V2, ensuring backward compatibility while paving the way for future enhancements with chart V3. Audience participation highlights the ongoing interest in contributing to Helm's development through its improvement proposal process (HIPs). The session also covers advancements in OCI support, including better credential management and functionalities tailored for enterprise settings, ultimately enhancing Helm's usability and integration within Kubernetes ecosystems.

All right, so I'll guess we'll get started. First of all, welcome. This is our talk on Helm 4 is here. So now what? Um I don't have the clicker. Sorry. How do I just click click it? Sorry, technical issues. So who are we? Um I'll start off. My name is Robert Sarchea, um marketing director at SUSE. And this is Yeah, Scott Rigby. I work at Replicated. Hello.

Uh Andrew Block, distinguished architect at Red Hat. Yes, there's a SUSE person and a Red Hat person on stage. I want to make sure people know we we enough space between us. Yes, we keep a distance. All right, so what is Helm? I if I really have to talk about it, I will, but I'm going to be brief with what is Helm. It is a package manager

for Kubernetes, all right? If you don't know, we can talk about this later. It's been around for 10 years plus, but Helm in a nutshell, we have Helm charts, we have values or your configs. We have the SDK, CLI that puts everything, packages it up, and delivers it nicely to Kubernetes. This is our project today. We're uh we're we're pretty proud of this. Um there's a yellow

there at the bottom for organizational dependency, um but we're working on that. But we have strived and worked very hard to get greens across the board here. Um even though you heard something slightly different in the project lightning talks yesterday, we were actually greener than what they were putting on. So thank you. we marked our 10 years with the release of Helm 4. Helm 4 was our

first release in 6 years. Um But we'll go on with what is in Helm 4. My favorite is the Wasm-based plugin engine. This did not replace our current plugin engine, so the plugins you have still work. I've gotten tweets about this, people have asked. So yes, it still works, but we are encouraging people to convert their current plug-ins, move it over. Server-side apply, this is a big

one. Um it took up forever to do the PR on this one. We were testing, testing, testing, but we finally got it in. The implementation of chart status, that was big. Chart address chart cache, that was another one that I did not touch, but we got that in as well. But one thing I want to say here is chart V2 is unchanged. There's a misconception that we

changed and broke charts. We didn't. There's a difference between chart version and the helm version. And we'll talk about that here in a moment. So I want to make sure I set the stage for what Scott's going to talk about, that when I say there's we didn't break you, we didn't. So what did we What it wasn't It wasn't a rewrite. We didn't start from the ground

up and rewrite it, and no, it's not written in Rust, so please don't ask. I know, there's like people are like, "Did you guys do it in Rust?" I'm like, "No." All right. Does include implementation of chart V3. We did the We took the time to do the scaffolding of building the abilities to deploy chart V3, but we did it in a way where it's not tied

to a big release. We can implement it slowly, and we can go on it, but I don't want to take Scott's thunder. Where's this? Oh yeah, thank you. Uh thanks Robert for that. Um yeah, it's probably good to mention uh what that meant about shipping the scaffolding for chart V3 in Helm 4. Mainly what we did was we reorganize the so that we could implement chart V3

fully, um the next API version of charts um and future versions um without breaking backwards compatibility. So we can add add that and additional things um in a way that we can roll forward with that. We won't have to wait for Helm 5, let's say, to make more changes. So So yeah, so um I don't know if you all know wait a second, did we Can I

go back? Okay, yeah, I think you might have handed it off to me a little too soon, but I'm happy to do this part too. the I don't know if you all know how how you contribute to Helm major major changes. We follow a a process we the acronym is hips. I really wanted to play that Shakira Hips Don't Lie song at this slide, but didn't have

didn't get to it. But basically they're modeled off of Python's peps if some of you might have been thinking that if you didn't know what the hips were. They were Helm improvement proposals and it's an RFC process. It's just it allows transparency as someone makes suggestions core maintainers and other community members can say, hey wait a second, that doesn't make sense or did you think about that

and so on and it just allows for everyone to get involved. well, it's pretty much exactly what I just said. So this is the slide for that and so yeah, so basically I'm going to describe what we're thinking about like why we even are looking at a new major version excuse me, a new API version for charts. Just curious the audience who is a Helm user here?

Most people. Okay, cool. So every chart yeah, I think like I think every hand yeah, so every chart that you see the manifest for the chart.yaml file has an API version V2 at the top. That's what we're talking about with charts V3. And as Robert said, it's independent of Helm's major For example, if you were Oh my gosh. Uh so who used Helm 2? Yeah, like a

pretty decent number back before even Helm 3. So, you know that Helm 2 supported API version 1, charts API version 1, and API version 2. And then when we moved to Helm uh 3, um we dropped uh support for API version 1 for We are not planning on doing that right now um for charts V2. We don't have a date for that. So, don't worry. As Robert

said, um your charts will keep working and just everything should be fine. Um but um but we are adding support for V3 just as we did with V1 and V2 in Helm as you all know, there are major There are features that people have been asking for in charts V2 but that we couldn't do. Um for example, um sequencing resources. This has been a request for years

and we just There just wasn't a easy way to do that because of how charts version 2 works, all resources are collected together and sent to the kube API in one sandbox. If we changed that in charts V2, it could cause major breaking changes for existing charts. So, we couldn't do it. Um for example, uh people also asked, you know, okay, who does not Who both perhaps

likes Well, let's say Who doesn't like Go template? Or has a problem with Go A fairly decent number of you, okay? Not as many hands as Helm users, but um when you start doing you start wanting validation against something that isn't really a valid language. When you There's a lot of reasons why Go template causes problems. Um people want new new render engines. And with charts V3

and the new plugin system, according to the current hips, um you will be having this. You'll have the ability to deploy your charts with template engines. Yes. Um, it's not here yet, but it is we have a working reference implementation. So, you can actually look at the hip for that and see in action. Um, the ability to pass values to sub charts in and modify your values

between a parent and sub chart. We can't really do that today. We don't have a step for that in charts V2, but we are adding a plug in there is a hip to add a plug in type for that in charts V3. there is a long standing uh, well anyway, feature request to for helm ignore to work the same as get ignore. you may have run into

issues with this. They are edge cases, but it doesn't do that today and we can't do that because of backwards compatibility. Uh, that's one of the reasons why, sorry, I need some water. That's one of the we are moving to a new API version for So, that we can make changes that would be considered, excuse me, backwards incompatible. Um, if you were to apply those to your

existing V2 charts, it just means that charts that move from V2 to V3 will have to make some changes when they do that. here are the hips just it's just a quick list. I'll go through them very quickly. I mentioned a few of these things. Um, basically the very first one that I'm the most excited about is chart defined plugins. If you saw the maintainers track talk

either in person or a recording of it that Robert and Matt Farina gave at KubeCon North America, um, they got into the new plugin system for Helm 4. Uh, Robert just mentioned that it supports was a runtime and there's a lot of things that a lot of benefits that come with the new plugin system. But, I think the real benefits or the benefits that most, excuse me,

end users will really feel, Uh, um, in chart authors is when charts are able to define their own plugins. so, uh, the goal of this is, you know, if you try to deploy a chart that depends on other charts, you'll be told run a Helm dependency update in order to build the correct version of the those charts or pull the correct versions down, um, of the sub-charts,

and then you can install it, right? Well, the idea is that will be the same for plugins. Um, you'll be able to do they will be considered another dependency of charts if they're defined in the chart.yaml in charts V3. That's what this top hip is about. Um, if you have any thoughts about it, um, whether you just want to cheer it on and give like, you know,

high-five emojis on there or whether you have actual like other thoughts to comment, please do. and then there are additional, um, there are additional hips to, um, to essentially extend that idea. So, um, the first one comes with, um, a render, um, a render V1, hip, excuse me, um, plugin type and a, um, a getter plugin type. That's very similar to what the getter plugins types do

now, you just have to install them globally. Um, and what that means is you might have remembered downloader plugins, it's just a different name for it because the package was always called getter, so we just named it that in in Helm 4. and uh, the these other hips, uh, that are mentioned on this list are, um, I I kind of alluded to them earlier, but, um, uh,

specifically like the ability to transform values and the ability to have different rendering engines, like say you want your chart to render in Q or, yeah, I don't know, YAML script or whatever, you can you will have plugins to do that. And then the last one that I didn't mention is, um, the signer plugin. Um, that'll transition to what Andy will be talking about, but um, the

goal for that is to allow other signing mechanisms than PGP. So, who signs their charts or verifies charts here? I'm guessing, yeah, like maybe three hands, right? Um, there's a reason for that because PGP, although it always was only pretty good, um, it also isn't pretty good for users, right? It kind of sucks. It's prohibitive in a way. You sort of have to explain to people how

to do it. Um, it's In short, it's very annoying. So, the idea of having additional signing mechanisms, for example, cosign, um, is much easier to use. A lot of projects and a lot of people probably here use that. Um, that will be one of the signing mechanisms, um, SSH keys, anchor, you know, um, current modern, um, signing mechanisms. So, that'll be exciting. And um, and yeah, so

today you can you can actually explore this right now. Um, you can't really do a whole lot with this now, but you can turn on the experimental flag like we've had various experimental flags over the years. Um, and you can go ahead and create a chart API a version three chart. You can't do anything with it yet. Um, you can install it, um, because we still have

some changes to make in, um, uh, in the release release versioning and so on, but we are stepping toward that and there is a, um, there's a link at the end of this, I think, that shows how you can track that. There's a tracking issue in Helm. Um, and uh, yeah, check it out. If if you're interested in the details of it, please take a look. Um,

if you're just interested in following it, please just check out that tracking issue. You'll you'll be able to see, um, when that's coming. So, uh, yeah, um, just to reiterate what Robert was mentioning before, V2 charts, you have nothing to worry about. Um the reason that we split the packages apart um before the release of Helm 4 was exactly for that reason. So that um you know,

as we make changes to charts V3, it will not um impact your existing charts. We won't be introducing bugs to them, for example. Not that there couldn't be bugs, but it won't be for that reason. So um yeah, and the other thing is that like, you know, when you're ready to experiment, well, actually, when they're ready for you to, but then when you're ready to experiment with

or to upgrade your charts to V3, um you can do that at your own pace because existing releases that are out there, um they're not going to have to say be torn down and then re-added. You'll be able to actually update to the next the V3 version of that chart with existing resources for a release. And uh yeah. I guess that's it for that section. Um just,

you know, let us know if you have any questions and please get involved in the hips. Thanks, Carl. Yeah. So an area near and dear to my heart is OCI support. So how many of you have transitioned your chart storage to OCI? Good. That's great. There's some limitations when it comes to OCI, and that's really what we're going to be looking at focusing on is to strengthen

a lot of the OCI support around a lot of the tooling that's provided by the containers tools project. Containers tools project is a CNCF um space that contains tools like Podman, for example. There's a lot of functionality that's found within the containers tools that help close a lot of the gaps that are currently found within the Helm's way of how we handle the referencing of credentials, how

we go ahead and handle a lot of the details around uh OCI content, or just cont- or just capabilities that aren't available now. For example, uh we can now leverage the registries.conf paradigm for us to be able to manage credentials more appropriately. So, if you are using quay.io and you want to reference multiple repositories, you can use different credentials. There's no functionality for that. You can then

store your credentials in a different format that's a lot easier using auth.config, but also most importantly is the ability to use policy.json, which allows you to either accept or reject certain registries based on policy within your organization. So, if you want to block certain registries like docker.io for your enterprise container registry, you can now do that at the client level. So, you no longer have to worry

about consuming that chart that's stored in locations that your organization or you may not approve. it a lot of these capabilities really um help to address a lot of the limitations that's really found in the existing Docker implementation. Docker has a lot of lineage that has come that we've kind of inherited over the years, and we're looking to break away from those limitations and provide new capabilities

that you'll be able to leverage. Now, good news is some of these features are already part of the ORAS library. Uh ORAS is the OCI library that we're currently leveraging within Helm. ORAS itself is a sandbox project within the CNCF. Then we're also working and partnering with their teams to also see if we can get their functionality that they've now put into their project into the Helm

project. So, really this is a good collaboration between multiple CNCF projects together. Helm has been a great advocate of Helm and just shows how by working together these communities can get stronger. Oh, Andy, a quick Yes. quick note. Uh one other feature of the registries.config is um I know it's on the slide, but I don't know if you mentioned it, but registry mirroring. Yes. Air gap. Uh

you want to change your you know, you say you have your your charts dependencies have an OCI. Yeah. You want to mention? Yeah, so good call, Scott. So registry mirroring is used in enterprise environments a lot. One of the limitations right now is that you basically are limited by the either your dependencies and they're hard coded within the chart. What a registry mirror allows you to do

is to basically flip the location of where those charts happen to be located. So if I have a docker.io location, I can then mirror that content to my enterprise registry and have it transparently redirect to your enterprise registry instead of going and trying to retrieve it to a public source. This is incredibly important any enterprise environment cuz most enterprises aren't going to allow access to these public

sources. They want to curate, they want to bring them into the organization so only the charts and other content that they want to trust is brought in. So thank you, Scott, for mentioning that. Uh streamlining the release process, that's another area that we're looking at really looking at. Uh we want to be able to really have a good Helm release cadence and get those changes in to

the for V4. We want to improve additional tooling and automation for the release Uh this is a challenge that many many projects within the CNCF currently face is handling releases. Uh there's an entire white paper that is being brought in as part of uh tag app sustainability right now that really talks about the release process. We're trying to and we're actually I talked on it's part of

the maintainer summit on Sunday about how the Helm project adheres to a lot of these capabilities and a lot of the best practices. However, we realize that our own processes aren't perfect and we're looking to move our process that we currently have forward to make it simpler for our release engineers to be able to release the project. Plus also getting more folks on the Helm project to

be able to perform the releases. Robert, I think you did a release or two uh not too long ago. So we're trying to get more and more of the team involved, so we don't have a single dependency and single point of failure for managing these projects. And then most importantly for you all, we want to improve the contributor experience. We want to make it easier for you

to understand how to contribute and be able to do so effectively. That's why I'm sure you're all here. You probably want to know how you can actually make an impactful change on the now that you know where Helm is going, Review the HIPs. You know, as we mentioned earlier, really a lot of these features and capabilities is all driven through the Helm Improvement Proposal process. Understanding what

HIPs are out there and trying to figure out exactly if you see something, see a gap in the project, and you see a feature that you'd love to propose, we want to see that as a HIP. Go through and understand how HIPs work. Go ahead and propose it, but also comment on existing HIPs. Does it Does an existing HIP solve your use case? Or is there a

gap that you need to go ahead and get solved through that HIP? Or go ahead and create a new HIP of your own. Another way to collaborate is on Slack. We're not on CNCF Slack, we're on Kubernetes Slack. It's mainly because Helm was a Kubernetes project before the CNCF even even existed. So, that's why we're still over on the on the Helm on the Kubernetes side of

things. We are on the Helm users for just general usage, but if you want to get really into the into the weeds and learn about developing Helm, go ahead and join the Helm Dev channel. Uh every week the every week at Thursdays at 9:30 Pacific time, we have a weekly developer meeting. So, that's a great way for you to collaborate with the community, learn more about what's

going on in the project, how to get involved, and just share your experience. If you uh if you actually go to the Helm website, we have the link on where to go for that. We didn't link it here, but on the Helm website, you scroll to to the absolute bottom, and it says join the the developer meeting. We encourage you to be there. We're the three of

us are always there, so I would notice we didn't put that in there. We're sorry. Yeah. And then finally, if you want to learn more about just cracking the Helm V3 charts implementation, you can go ahead and view that issue and learn more about how you can make an impactful change and start testing out a lot of the changes that Scott mentioned earlier when it comes to

Helm V3. That's it, folks. Thank you very much. We will take some questions, kind of. we have a big audience here. We'd love to get your feedback and answer as many questions as we can in the amount of time we have left. So, I have no idea how we would do this, but if you want to just come up, we'll just take it one at a time.

Otherwise, it's a big crowd. Otherwise, come on up and we'll answer any questions you have. So, we asked with the sequencing.