Week Ending July 5, 2020

Developer News

There was a Steering Committee meeting this week. Election officers for the SC election have been selected, and we are setting up nominations for the CoC Committee (who turn over in August). We are reducing the SIG/WG community meeting requirement to once a year, because that’s the reality (see schedule). SIG leads will get to take Unconsious Bias training to make sure we’re treating everyone fairly.

Also, invite calendar@kubernetes.io to your public SIG/WG meetings so that your events get added to the community calendar.

Release Schedule

Next Deadline: CODE FREEZE July 9th

That’s right, it’s time to finish up your changes for 1.19 and get ready to pass E2E and conformance tests. We’ll have a couple weeks of code freeze, followed by code thaw on the 21st, at which point you can start work on 1.20.

The next set of patch releases has a cherry-pick deadline this Friday, and should be released the following Tuesday.

Featured PRs

#90454: add conditions to metav1

The .status.conditions array has become a common fixture of many Kubernetes API objects, and that pattern has now been solidified into a metav1.Condition struct which can be used directly as a Conditions []metav1.Condition in future API objects or operators. As before, the specifics of condition strings are still left up to each use case to determine, but adhering to the standard struct and formatting can allow for shared code over time. If you work on an out-of-tree controller, definitely consider replacing homebrew status condition structs with this.

#92667:Admission webhook warnings

Admission webhooks can now expose non-fatal warnings to the client making the request. On the webhook side this is by passing back an arrays of strings under a warnings key in the AdmissionResponse. The apiserver collects and combines these and returns them in a Warning HTTP response header.

In the future this will be used to show warnings on deprecated APIs used from Kubectl or other clients. Check out the KEP for more information on the planned client side implementations.

#91381: seccomp GA - Add new seccomp fields and update kubelet to use them

Support for setting specific seccomp profiles on containers has reached GA status. With this comes a new seccompProfile substruct on both contain security contexts (to set for just one container) and pod security contexts (to set for all containers in a pod). With this change, the container.seccomp.security.alpha.kubernetes.io and seccomp.security.alpha.kubernetes.io annotations are deprecated.

This change makes concrete the previous annotation-based protocol and lays the groundwork to manage the actual profile distribution itself in a future version. For now profile distribution can be handled via tools like seccomp config, openshift’s machine config operator, or seccomp operator.

Other Merges

kubelet, scheduler, and controller-manager all get --logging-format to support the structured log changes, and you can disable the /logs endpoint in kubelet
Ask your devices what they want (what they really really want) via GetPreferredAllocation() (for smarter hardware topology)
To Kill a Kubelet That Is Waiting For a Cert
PodSchedulingDuration metric includes number of attempts so you can do averages
Improve IPVS performance by cutting EnsureDummyInterface runs
Let pods get pre-empted if their nodes have gone AWOL
Allow disabling the kubeconfig lock if you’re set up for concurrent editing
CRDs will warn you about deprecations
EndPointSlices on Windows
kubeadm upgrade plan prints component config states
Have CSI node expansion calls include all fields

Deprecated

kubeadm config view is deprecated, being replaced by reading the configmap for kubeadm
kubeadm --experimental-patches is the new kubeadm --experimental-kustomize

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.