Stay up-to-date on Kubernetes development in 15 minutes a week.
The Steering Committee Election ends on 27th September. If you think you should be eligible, you can file for an exception before 24th September 11:59:59 UTC.
Next Deadline: Production Readiness Review Freeze, September 28th
Patch releases 1.28.2, 1.27.6, 1.26.9 and 1.25.14 came out last week. These includes bug fixes for CEL expressions in CRD validation rules incorrectly computing high estimated cost for functions returning strings, lists or maps. Also, Kubernetes is now built with Go 1.20.8.
The Call for Enhancements is still open. Make sure to opt-in well before the Production Readiness Review Freeze on September 28th to ensure adequate time for reviews.
At long last a refresh for kube-apiserver’s authorization controls. While we’ve long had the ability to configure multiple authorization webhooks via the API objects ValidatingWebhookConfiguration
and MutatingWebhookConfiguration
, this same ability has not extended to the “at startup” options. There is a webhook, configured via the --authorization-webhook-*
options but by the nature of the command line flags it’s a singleton. While this limitation hasn’t been very notable to folks with only one or two clusters, after all you can just do all the setup in-band after it’s all up and running, it’s much bigger problem for admins in charge of dozens or hundreds of clusters who really need things safe and controlled from the moment the API starts taking requests. And so we have StructuredAuthorizationConfiguration, a new configuration mechanism for the startup-time authorization providers and front and center is an upgraded webhook subsystem in it. This not only brings multiple hooks to the party, it also allows using all the same bells and whistles as the in-band API like CEL expressions for request matching and controlling the schema version sent to the hook.
While this PR sets up the core plumbing for the feature, a bit more work is needed before you can actually try it out so subscribe to that ticket if you want to give it a shot as soon as possible.
Implement maxUnavailable in StatefulSet
This KEP implements maxUnavailable for StatefulSets during RollingUpdate. Currently if the updateStrategy is set to RollingUpdate
, the StatefulSet controller will terminate and recreate each Pod in the StatefulSet. Currently the updating of each Pod happens one at a time. Once this KEP adds support for maxUnavailable
, the updating will proceed maxUnavailable
number of pods at a time. This also makes it easier to track the revisions of a rolling update. Deployment does this with ReplicaSets.
This KEP hit its alpha milestone in the 1.24 release, and is tracked to graduate to beta in the upcoming 1.29 release. It has been authored by Mayank Kumar
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.