Kubernetes 1.26: the one that you want?

I got chills, they're multiplying

Is there a lot of news left for the year?  Hard to say. There’s certainly a lot of weather. 

After we moved to Canada in 2007 and the snow came tumblin’ down, Fern and I were told “it’s not normally like this at all. This is the worst winter we’ve had in 50 years!” Of course, the winter in 2008 was every bit as bad, so in 2009 we became the first couple ever to move to London for better weather.

Having lived through a number of cold and wet Christmases, but precious few snowy ones, we set forth into the “why the hell did we do this, it’s so weird, I don’t like it” of festive sunshine and beaches Down Under¹. What we have now is the promise of a warm and wet Christmas. Thanks, weather.

Meanwhile, the UK celebrated its coldest day in 12 years, Knowing their luck², it will all have melted by the 25th, but on behalf of the loved ones we left behind I’ll set my jealousy aside and honestly hope you have a white Christmas. Don’t worry about us; I’m sure we’ll be there next year, and I’m sure the weather will be every bit as bad.

Let’s get to the news.

The power you’re supplying

Kubernetes 1.26 is out. The release, entitled “Electrifying”, rounds out 2022 with 37 enhancements: eleven moving to Stable, ten graduating to Beta, and sixteen entering at Alpha. There are also 12 deprecations or removals. Be aware that this version won’t be published to the legacy k8s.gcr.io container repository: you’ll only be able to get it from the mirror system at registry.k8s.io³.

One of the key changes isn’t so much to Kubernetes itself, but instead the build and release pipeline. The last two releases came with signed container images; 1.26 now extends signatures to all binary artifacts. All the client, server and source tarballs, Software Bills of Material (SBOMs) and the build provenance files are signed using sigstore’s cosign⁴. 

For information on the rest of the changes, check out the launch blog or ARMO’s “everything you should know” summary. If you want to dig into every detail, the enhancement tracker, KEPs and issues can be found on a flash new GitHub “I-can’t-believe-it’s-not-a-spreadsheet”.

Unless any of these features are earth-shattering enough for you to want to run a cluster the proverbial Hard Way, you’ll probably see them in the stable track of your Kubernetes provider in a few months.

The Kubernetes 1.26 release interview

Our first interview of a Kubernetes release lead was after version 1.11, not long after Adam and I started the old show back in 2018. Coverage was intermittent for a while after that, but for the last 9 releases on the trot, I’ve interviewed the release manager on the occasion of the launch. Unfortunately I don’t have a podcast any more⁵, so in the spirit of new traditions, please “welcome” Leo Pahlke, who led the release team for Kubernetes 1.26.

Congratulations on the launch.

Thank you, it was a ton of work for the last months but a great open source adventure! I was very lucky with my shadows and team leads, who all did an awesome job.

What things in this release are particularly meaningful to you?

The signing of release artifacts. We talked a lot about this in SIG Release for quite some time and it's great to see this KEP maturing from draft to Alpha to Beta.

The consistent advice from previous release team leads, including Cici Huang in 1.25, is “over-communicate”. Can you please share what you had for your last three breakfasts?

That’s right, communicating in open source projects is very important, and that was great advice by Cici. To your question, I don't eat a lot for breakfast; often just a bit of fruit or a cookie. 

What is in the envelope for the 1.27 release lead, Xander Grzywinski?

Every release lead mentions this, and I will too. It's a lot of work leading the Kubernetes release, and it's best to plan for it — it's full-time work just for the release team! I would also echo Cici’s advice to “over-communicate” and specify it a little; communicate over all channels available. Set up team meetings, 1:1 meetings, closed group meetings, message over DMs, group DMs, and open messages. Make sure that all relevant decisions, problems and ideas to the release are shared publicly. Take the time and grow into a team. Make sure the lead shadow can follow your work, and think about the next cycle in advance, to make improvements to the team.

Your focus is sustainable software engineering. How do you recommend we recycle used software engineers?

That's an interesting thought. In sustainable software engineering, we talk a lot about technology, energy and efficiency. But to me, that's only part of the pie, and I like to distinguish between Green Software Engineering and Sustainable Software Engineering. Green Software Engineering would be all of the things I mentioned earlier, power, technology, architecture patterns and so on, and Sustainable Software Engineering includes all of that, but follows a larger vision that includes more aspects. Depending on how you look at it, there are five aspects that need to be evaluated to stay in balance: the environmental aspect, the economic aspect, the social aspect, the technological aspect, and the individual aspect. Bringing these five aspects into balance is the utopia — the goal of sustainable software engineering.

I note for the record you did not answer the question, or offer up the obvious “Soylent Green Software Engineering”. Sascha Grunert recently removed 40,000 lines of code from Kubernetes. That would appear to be an excellent example of recycling. Could I paste those lines into Mesos, for example? I assume it needs some new code.

That's an interesting idea. Maybe software engineering will evolve more in that direction to allow code recycling; right now, that's not really the case. Maybe there are some snippets that can be copied over from the Kubernetes API implementation, but that's not part of the design phase where the API code is created in the first place. In a way, there is already code reuse in software engineering through the use of libraries. Since open source code can be used by everyone, it also has a potentially better sustainability aspect since others don't have to write it from scratch!

Between study, you work at Reply Group; their AWS division is called Storm Reply. I can see how Storm Reply follows from “cloud”. How does Liquid Reply follow from “Kubernetes”?  Is the liquid in question “bilge water”?

The Reply organisation sometimes comes up with names that don't make too much sense, and I think “Liquid” might be the case. Bilge water is certainly not the right image; maybe rather the ocean on which the Kubernetes and other Cloud Native ships sail 😛

Kubernetes 1.26 was pushed back by critical Go security releases. The same was true of 1.24. When can we expect the project to be rewritten in Rust?

It is true that this year we have postponed the release in two out of three cases due to version jumps of Go, but usually only by a few days. The postponement of version 1.24 by two weeks was rather the exception. We always point out that our release schedule is aspirational, and we do our best to meet it, but there are always dependencies that we have to coordinate with and sometimes we need to make some adjustments. Delaying the release by a few days is usually not a big deal. Rewriting Kubernetes is a fun and drastic idea, but not a solution to this problem.

News in brief

• You can now use Kubescape with GitHub Actions, and perform security and compliance checks on your manifests as part of a pull request.

• Monokle has released yet another YAML validator; a CLI derived from their YAML editing IDE

• Microsoft has published a third version of their MITRE ATT&CK-inspired Threat Matrix for Kubernetes, now living on its own web site.

• Transparency reports are out for the CNCF co-located events that were held alongside KubeCon NA in Detroit. The individual attendance numbers look low, but the sheer number of co-los means that almost 30% of the people who went to the conference in person paid extra to attend one. Upcoming changes to how co-los run for 2023 will no doubt increase these numbers: watch for an announcement tomorrow.

• New CNCF projects are also coming next week!

Oh, yes, indeed

Happy 50th anniversary to New Zealand folk-art-pop-rock-new-wave band Split Enz, and our commiserations to Celine Dion on her health issues. Video of the week is Adam Neely’s analysis of the most elegant key change in pop music, with a special hint of White Christmas.

We’ll see you next week.

1. Next time you see me, ask me about my “season zones” plan to move the Southern Hemisphere Christmas to June.

2. Are white Christmases earned by penalty shootout?

3. Do a lot of lazy people type “k8s”, or domain names charge by the character these days?

4. I think this means we’re almost back where we were with Debian in 2005? Far be it for me to go off on a tangent.

5. Next time you see me, ask me why I don’t have a podcast any more. (Or, encourage your friends to subscribe to this newsletter.)