LWKD logo

Last Week in Kubernetes Development

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


View LWKD on GitHub

Week Ending September 3, 2023

Developer News

The Kubernetes legacy Linux package repositories, apt.kubernetes.io and yum.kubernetes.io, have been deprecated and will be frozen on September 13, 2023. Use the new Kubernetes community-owned package repository at pkgs.k8s.io.

Kubernetes Contributor Summit Shanghai will take place on Sept. 26. Registration is open, as is the CfP for team meetings and discussions.


Release Schedule

Next Deadline: Production Readiness Review Freeze, September 28th

We are now officially in the 1.29 cycle, and Release Lead Priyanka Saggu has a “sneak peek” for you. That also means that Enhancements deadlines are coming soon (PRR: 28 September, Enhancements: 6 October).

The entire tentative schedule for the 1.29 release can now be found at GitHub - Kubernetes SIG Release. Weekly meetings for the 1.29 release will start from Wednesday, September 6, 2023. You can find details, meeting links, and agendas here.

Cherry Pick deadline for the next set of patch releases is this Friday.

#119157: WebSocket Client and V5 RemoteCommand Subprotocol

Since their addition in the pre-history of Kubernetes, the streaming APIs have used the SPDY (“speedy” to its friends) protocol. While SPDY was intended more for general web usage, the broader internet quickly centered around HTTP/2 as a better successor protocol. But our APIs for things like kubectl exec required bidirectional communication features that HTTP/2 didn’t inherit from its predecessor. So despite being effectively unsupported by web browsers and general purpose web servers, we’ve continued to use this SPDY plumbing for many years. This is mostly fine, but it does create some difficulties as things like proxy servers and firewalls don’t natively understand SPDY traffic anymore.

Fortunately there is a replacement protocol in common usage across the internet, WebSockets. While mostly used for bidirectional data communications with browser-based JavaScript, the WebSockets protocol is flexible enough to take over all our SPDY-based APIs. This effort has been ongoing for a while, as it became clear that SPDY was a dead-end technology, and this PR is another big leap forward towards the future. It adds an official client which can later be used from things like kubectl, as well as another iteration of a WS-based API for kubectl exec.

#117503: [KEP-2395] Phase 4 - Disabling In-Tree Providers

A big push over the past few releases has been the expunge the last bits of in-tree providers for things like cloud servers and storage. While these drivers were really convenient in the early days of Kubernetes, when we were a small community and most vendors didn’t even know what containers were, let alone have dedicated support tooling for us. As we’ve grown both as a piece of software and as a community, they started to hold us back. Vendors wanted to get “quick fixes” in patch releases, or to support advanced or in-development features that the core team couldn’t test against. So we decided to push vendor-specific and situational drivers into their own projects, some still owned by us but many managed by the underlying vendors.

This PR is very close to the end of the migration for cloud controllers, all in-tree cloud providers are now disabled by default and require a feature flag to turn them back on. The final nail in the coffin will making this flag mandatory, which isn’t happening yet, but hopefully soon. If you’ve been putting off your CCM migration, be sure to prepare for it before upgrading to 1.29!

KEP of the Week

KEP-4009: Add CDI devices to device plugin API

This KEP proposes extending the Device Plugin API in Kubernetes to include a field for specifying Container Device Interface (CDI) device IDs in the AllocateResponse. This addition allows device plugin implementations to uniquely specify devices using their fully-qualified CDI device names, simplifying the process of injecting devices into containers.

The motivation behind this change is to align Kubernetes with the CDI standard, which provides a standardized way for device vendors to describe resource requirements and access to specific devices. The CDI device IDs are included in the response from the device plugin and forwarded to the CRI runtimes for container execution.

This KEP outlines the design details, test plan, graduation criteria, and production readiness review for this enhancement, with a focus on ensuring compatibility and minimal impact on existing components. The goal is to enable device plugin authors to leverage CDI for device injection without necessitating a shift to Dynamic Resource Allocation (DRA) based implementations.

This KEP was created by Evan Lezar and received the alpha milestone in v1.28.

Other Merges



Version Updates

Subprojects and Dependency 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.