Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Kubelet broken uids #78178
…ng container startup" This reverts commit 5769863. The reverted commit breaks uid detection and images which are using a different uid than 0 will run as root (0). E.g. in my case many things just were broken because I like to use pod security policies and all the non-root-images did not start after the update to v1.14.2 with the error message Error: container has runAsNonRoot and image will run as root Workaround is to use a Security Context which defines the uid to use so that pods don't depend on the USER defined in the images.
Keywords which can automatically close issues and at(@) mentions are not allowed in commit messages.
The list of commits with invalid commit messages:
Hi @aholler. Thanks for your PR.
I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with
Once the patch is verified, the new status will be reflected by the
I understand the commands that are listed here.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: aholler
If they are not already assigned, you can assign the PR to them by writing
The full list of commands accepted by this bot can be found here.
The pull request process is described here
This is not a cherry-pick.
This is just a revert of the commit which caused the breakage in 1,14.2.
As said before, just by looking at the little commit which caused the breakage in 1.14.2, I can't say if it also causes the same breakage in the master. And I don't have a cluster > 1.14.2 to test.
I've tested and using a kubelet 1.14.2 with the reverted commit and it works, but besides that I can't comment on what happens in the master.
Thanks for the additional info @aholler! My understanding is that if we decide to move forward with this change, we'd want to first verify whether its currently broken on master, and if yes, start by merging a fix into master and then cherry-picking it.
I'm happy to do this investigation re the current state of master if you'd like :) I could create a pr for master and then contact you when its time for the cherry-pick to 1.14?
Besides that I thought the author (tallclair) might see right out of the box what the real problem is and if it might be already fixed in the master.
Just to add some note, kubelet 1.14.2 will currently break almost any (1.14) cluster where Pod Security Policies are used.