LWKD logo

Last Week in Kubernetes Development

Stay up-to-date on Kubernetes development in 15 minutes a week.

Subscribe
Twitter
RSS

View LWKD on GitHub

Week Ending January 23, 2022

Developer News

Abdullah Gharaibeh has proposed a new API for job queueing, replacing the earlier Job Management proposal for your commenting pleasure.

Now that most Kubernetes components are using structured logging, SIG-Instrumentation would like to talk about contextual logging as a feature. Like structured logging, this will affect a lot of components across the project.

We had a storm of spam on the mailing lists last week, so many Kubernetes lists are now moderated-first-post. Be patient with the delay when you first join a list.

Release Schedule

Next Deadline: PRR heads-ups due, January 27th

It’s Week 3 of 1.24! Your initial info to the Production Readiness team is due this week, and Enhancements Freeze will follow a week later.

Enjoy the relatively benign CI Signal Report for Week 3. Getting close to fixing all the tests that broke with the dockershim removal.

Patch Releases: 1.20.15, 1.21.9, 1.22.6, and 1.23.2 are out. This release mostly fixes various crash and performance bugs discovered since December.

This is the last update for 1.20, so schedule that upgrade now, eh?

#107688: Fix regression pruning array fields with x-kubernetes-preserve-unknown-fields: true

An unfortunate regression in 1.23 has lead to a behavior change with x-kubernetes-preserve-unknown-fields on arrays. This will be resolved in 1.23.3 to be released shortly. If you make use of this feature in any of your operators or other out-of-tree controllers, it is recommended you hold off on upgrading until 1.23.3 is available.

As a workaround if you’ve already upgraded, you can set x-kubernetes-preserve-unknown-fields on the array items as well as the array itself:

type: array
x-kubernetes-preserve-unknown-fields: true
items:
  type: object
  x-kubernetes-preserve-unknown-fields: true

#104620: Update CRI-API Capabilities to include a field that allows us to set ambient capabilities

Running containers (and everything else) with minimum privileges has always been an important best practice. With Linux, one part of that security hardening is dropping unneeded process capabilities. Most of our applications need none of capability flags and so a simple drop: [ALL] does the trick. But when needing to keep one or two of them, while also running the process as a non-root user as well should be, things get more complicated. While there have been a number of complex workarounds involving build-time file capabilities, it hasn’t been as easy and data-driven as the rest of our security policy settings. Linux 4.3, released back in 2015, added a new feature to help mediate this called “ambient capabilities”. These are set at the process exec in a similar way to the normal capabilities but are preserved across a UID change (subject to some safety rules).

This PR starts the plumbing for supporting ambient capabilities in CRI and then in Kubernetes. Containerd already has a PR up to support the new CRI field and CRI-O will be adding it shortly. The exact implementation in the PodSpec side are still being discussed, please reach out to SIG-Security with any feedback.

#107456: apf: change controller to use SSA for patches

A much smaller PR, this is great example of how easy it can be to upgrade a controller from using a merge patch to Server Side Apply. Moving to SSA gives improved field tracking, better integration with other API writers, and generally makes the controller benefit from all future bug fixes in SSA. If you’ve got a controller, in-tree or external, that hasn’t yet upgraded, now is a great time to think about it.

Other Merges

Version Updates

Last Week In Kubernetes Development (LWKD) is a product of multiple contributors participating in Kubernetes SIG Contributor Experience. All original content is licensed Creative Commons Share-Alike, although linked content and images may be differently licensed. LWKD does collect some information on readers, see our privacy notice for details.

You may contribute to LWKD by submitting pull requests or issues on the LWKD github repo.