Last Week in Kubernetes Development: 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 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 and 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


Original Source: