The Issue/PR triage workflow is changing in several ways on Sep. 30th. If you triage contributions to your SIG you’ll need to know the new commands. The new triage is to help make fewer issues “fall between the cracks.”
The Reliability WG is in the process of approval; this new working group plans to create ways of measuring reliability and detecting reliability breakage in order to stop breaking changes from getting into releases.
Evan Anderson submitted new Condition Guidance for custom controllers. After months of discussion, this document details some conventions for the project, to hopefully lead to controllers having the same general workflows and status information.
Next Deadline: Enhancements Freeze, October 6th
You have one week to file/update your enhancements to get them into 1.20. A lot of folks working on features for the 1.19 cycle that didn’t make it in haven’t spoken up yet, so this is your wake-up call.
In this 3rd week of the 1.20 cycle, the team has determined some dates, including Test Freeze on Nov. 23rd, and final release planned for December 8. More importantly, the 1.20 milestone restriction has been lifted, so you can do your normal early-release-cycle development.
The next set of patch releases is planned for Oct. 14, with a cherry-pick deadline of Oct. 9.
While the overall trend is to move the cloud controllers to independent projects owned by their respective cloud teams, this update to the legacy cloud-controller-manager adds three new annotations to customize AWS load balancer healthchecks:
This PR improves the handling of resuming watches after an API server restart. Normally the API server comes back up with an empty watch cache, which can result in bookmark-based resumptions targetting objects not yet known to the server. Using an improved callback mechanism with Etcd, the watch cache can now cope with this requests without a flood of reads. This should help with any large clusters that do in-place upgrades, especially those making heavy use of operators or other custom controllers. It is an alpha feature for now, behind a new
EfficientWatchResumption feature gate.
And finally a nice addition for any command-line scripting using
kubectl delete. This changes the
--cascade option from a simple boolean to taking named strategies (
foreground). The previous
--cascade=true/false options are still supported for now and are equivalent to
orphan respectively. Foreground deletes allow for maintenance scripts with fewer race conditions, consider using them any time you want to delete and recreate a set of objects.
An unrelated boon for kubectl scripting adds
delete-user config commands.
kubectl configgets user management commands
verifyRunAsNonRoottells you which container it’s unhappy about
kubeadm alpha kubeconfig userworks
--experimental-kustomizein favor of
Last Week In Kubernetes Development (LWKD) is a product of some members of the Kubernetes project, but is not an official publication of the Kubernetes project or the CNCF. 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.