The Kubernetes legacy Linux package repositories,
yum.kubernetes.io, have been deprecated and will be frozen on September 13, 2023. Use the new Kubernetes community-owned package repository at
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.
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.
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!
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
kubectl eventsto filter events by group and version for resource with full name
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.