Voting has begun for the Kubernetes Steering election; cast your ballot on the election site, which also tells you if you’re eligible or not. If you’re not, and should be, then request an exception. With 11 candidates for four seats, this will be a tough one, so give yourself some time.
CVE-2023-3676, CVE-2023-3955, and CVE-2023-3893 were reported for Kubernetes on Windows, and are patched in the current update releases. These are high-risk security issues, and all Windows users should upgrade as soon as possible.
The #kubernetes-contributors Slack channel has been split into #kubernetes-new-contributors and #kubernetes-org-members. The former will be the channel for introductions, getting started and mentorship requests, whereas org-members will be for established contributor communications.
The SIG-Contribex mailing list will be migrated to a project-controlled Google Group on September 1. This is the first of many mailing list migrations.
Han Kang started a discussion on replumbing Kubernetes for safer upgrades.
Next Deadline: 1.29 Begins, September 5th
We are in the interval between releases, but if you wanted to be part of the 1.29 release team, there is still time to apply.
Patch releases 1.28.1, 1.27.5, 1.26.8, 1.25.13 came out last week. These include important security patches for Kubernetes on Windows. 1.24 is now EOL, and users of 1.24 need to upgrade or look at their ecosystem support options.
registry.k8s.io/kubectl container image is one of the release artifacts put out with every version of Kubernetes. Like our other images, it has been built as minimally as possible, using the
distroless base image and only containing the
kubectl binary and files required for it to run. While this minimalism makes sense for our daemon images, is the same true for a CLI tool? This PR swaps out the base image to a minimal debian and installs a suite of basic CLI support tools including bash, sed, awk, grep, diff, and jq. However concerns have been raised that the improved UX isn’t worth the greater risk to users due to those extra tools needing security updates, a task we aren’t well set up for. A revert has been proposed pending feedback from the relevant SIGs. If you have thoughts one way or the other about this change, now is the time to make them known!
Currently the communication involving bi-directional streaming between Kubernetes clients and the API server is done through SPDY/3.1 protocol. These include several
kubectl commands like
kubectl cp (built on top of
kubectl exec primitives),
kubectl port-forward and
kubectl attach. This KEP transitions the bi-directional communication protocol used from SPDY to WebSockets, since SPDY was deprecated in 2015. WebSockets on the other hand is a standardized protocol and provides compatibility with software and programming languages.
As of now, the bidirectional streaming is initiated from the Kubernetes clients, proxied by the API server and kubelet, and terminated in the container runtime. This KEP proposes to modify
kubectl to request a WebSocket connection, and to modify the API server proxy to translate the
kubectl WebSocket data stream into to a SPDY upstream connection. This way everything upstream the API server need not be changed in the initial implementation. This KEP is in alpha in v1.28.
--image-repositoryin kubeadm commands
Testing Updates: PV and PVC Endpoints
node.kubernetes.io/out-of-servicetaint when nodes are shutdown so that the pods can be forcefully deleted
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.