[V2] Upgrade Kubernetes version to 1.34 in demo and dev environments#7190
Draft
[V2] Upgrade Kubernetes version to 1.34 in demo and dev environments#7190
Conversation
Signed-off-by: Kevin Su <pingsutw@apache.org>
The k3s v1.34 base image ships a busybox build without the xargs applet, which caused the cgroupv2 fix script to fail silently and then the sed write to cgroup.subtree_control to fail, exiting the container before k3s could start and write the kubeconfig. Use the standalone /bin/xargs (present in the image) instead of busybox xargs. Signed-off-by: Kevin Su <pingsutw@apache.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why are the changes needed?
The demo/sandbox environment was using Kubernetes 1.29 (k3s
v1.29.0-k3s1), which is outdated. Upgrading to 1.34 brings security patches, performance improvements, and access to newer Kubernetes features.What changes were proposed in this pull request?
v1.29.0-k3s1tov1.34.6-k3s1indocker/demo-bundled/Dockerfile.v1.26.0tov1.34.0inexecutor/DEVELOPMENT.mdanddataproxy/DEVELOPMENT.md.docker/demo-bundled/bin/k3d-entrypoint-cgroupv2.shby replacingbusybox xargswith the standalonexargs.Why the cgroupv2 script change is needed
After bumping to
rancher/k3s:v1.34.6-k3s1,make sandbox-runhung atWaiting for kubeconfig...because the container exited with code 1 before k3s ever started. Root cause:/bin/k3d-entrypoint-cgroupv2.shbefore launching k3s. That script (copy-pasted from moby/moby's dind helper) callsbusybox xargs -rn1 < /sys/fs/cgroup/cgroup.procs > /sys/fs/cgroup/init/cgroup.procs || :to evacuate processes from the root cgroup into/initso that writing tocgroup.subtree_controldoes not fail withEBUSY.rancher/k3s:v1.34.6-k3s1was built without thexargsapplet, sobusybox xargsfails withxargs: applet not found. The|| :swallows the error, so the script appears to continue.sed ... > /sys/fs/cgroup/cgroup.subtree_control— fails withsed: write error(EBUSY).set -o errexitis in effect, so the entrypoint exits 1. k3s never starts, the kubeconfig is never written, andmake sandbox-runwaits forever./bin/xargsbinary does exist in the k3s v1.34 image, so simply dropping thebusyboxprefix is enough — the cgroup evacuation then works and k3s boots normally.Entrypoint log captured from the failing container before the fix:
How was this patch tested?
Rebuilt the demo image locally and ran
make sandbox-run:Cluster comes up on
v1.34.6+k3s1, kubeconfig is written and merged into~/.kube/config, and all demo workloads schedule normally.Labels
Check all the applicable boxes
main