Priyanka Saggu of ContribEx has announced some changes to Org Membership requirements, mainly letting memberships expire after 1 year of inactivity. If you have submitted multiple PRs to Kubernetes, consider becoming an Org Member today. Please reach out to ContribEx on Slack or anywhere if you have any questions about the new guidelines or on becoming a member.
Next Deadline: CODE FREEZE July 18th/19th
Code Freeze starts tonight (for folks in North America) or tomorrow morning (for everyone else). Is everything checked in? This is followed by the regular release countdown: open docs PRs by Thursday, publish deprecations blog on Thursday, test freeze and finalize docs next week. As always, once we’re in Code Freeze, please respond to test failure issues with alacrity.
As if that weren’t enough, patch releases are due out Wednesday, including a Go version bump. This will be the last patch for 1.24.
As we’ve covered over many releases, CEL support in our API is big and growing feature in Kubernetes. As more functionality has been exposed, and folks try more complex use-cases, performance has become more of a concern. One very common pattern in CEL-driven validations is reusing the same chunk of expression code in multiple places, such as in both the validator expression and the error message to provide direct feedback about the rejected field. The naive way to approach this is to just duplicate the code in both places but we are programmers and that makes us all sad so now we have a better approach: variables. Much like variables in any other programming environment, you can set one to a value and then it will only need to be evaluated once and can be reused in other contexts.
As this is still declarative code we have to set up variables in our YAML:
variables: - name: envVarNames expression: spec.template.spec.containers.env.map(e, e.name) validations: - expression: variables.envVarNames.all(n, n.startWith("MYAPP_")) - expression: variables.envVarName.indexOf("UNSAFE") == -1
Variables can refer to other variables and can be used anywhere in the same CEL scope. This should allow for both improved performance of expression evaluation and more maintainable CEL code through de-duplication.
Two separate PRs but both adding the same feature for each type: exposing the pod’s index as a label. For a while now, indexed Jobs have supported exposing it as an annotation so it could be read by the Downward API but as we all know, annotations can’t be searched on which was a frequent request. And on the StatefulSet side the only option was to parse the pod name which is never very fun. Now both support similar labels:
batch.kubernetes.io/job-completion-index. As with the annotation, these can be exposed down to the pod via Downward API volumes or environment variables, or used in label selectors in all the usual places.
And while we’re on the topic of indexed Jobs, #118009 and #119294 have also landed providing the ability to control the failure handling on a per-index basis rather than only for the job as a whole. This mirrors similar workflow control features in other job-runner frameworks.
sync_proxy_rules_iptables_total, encryption hot reloads, replace
apiserver_storage_size_bytes, count all pod deletion activity
kubectl delete -i
pvc.Status.AllocatedResourceStatusis the new
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.