mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-11-02 11:18:16 +00:00
b600533794
Automatic merge from submit-queue CRI: Support string user name. https://github.com/kubernetes/kubernetes/pull/33239 and https://github.com/kubernetes/kubernetes/pull/34811 combined together broke the cri e2e test. https://k8s-testgrid.appspot.com/google-gce#gci-gce-cri The reason is that: 1) In dockershim and dockertools, we assume that `Image.Config.User` should be an integer. However, sometimes when user build the image with `USER nobody:nobody` or `USER root:root`, the field will become `nobody:nobody` and `root:root`. This makes dockershim to always return error. 2) The new kube-dns-autoscaler image is using `USER nobody:nobody`. (See https://github.com/kubernetes-incubator/cluster-proportional-autoscaler/blob/master/Dockerfile.in#L21) This doesn't break the normal e2e test, because in dockertools [we only inspect image uid if `RunAsNonRoot` is set](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/dockertools/docker_manager.go#L2333-L2338), which is just a coincidence. However, in kuberuntime, [we always inspect image uid first](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/kuberuntime_container.go#L141). This PR adds literal `root` and `nobody` support. One problem is that `nobody` is not quite the same in different OS distros. Usually it should be `65534`, but some os distro doesn't follow that. For example, Fedora is using `99`. (See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5GCKZ7Q7PAUQW66EV7IBJGSRJWYXBBH/?sort=date) Possible solution: * Option 1: ~~Just use `65534`. This is fine because currently we only need to know whether the user is root or not.~~ Actually, we need to pass the user id to runtime when creating a container. * Option 2: Return the uid as string in CRI, and let kuberuntime handle the string directly. This PR is using option 1. @yujuhong @feiskyer /cc @kubernetes/sig-node /cc @MrHohn