GID定义为；“用户”；在Dockerfile中，在Pod的容器中不工作

发生了什么： 在Dockerfile中添加“USER 999:999”，将默认uid和gid添加到容器映像中，然后在Pod中启动容器，其uid为999，但其gid为0

在Docker启动的容器中，ID是正确的

docker run --entrypoint /bin/bash -it test

bash-5.0$ id
uid=9999 gid=9999 groups=9999

但从Pod开始，gid为0

kubectl exec -it test /bin/bash
bash-5.0$ id
uid=9999 gid=0(root) groups=0(root)
bash-5.0$

bash-5.0$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin 
systemd-coredump:x:200:200:systemd Core Dumper:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
systemd-resolve:x:193:193:systemd Resolver:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin

如果Dockerfile运行额外的“useradd”命令，那么Pod中的gid似乎是正常的

RUN useradd -r -u 9999 -d /dev/null -s /sbin/nologin abc 
USER 9999:9999 

那么Pod容器中的ID与Dockerfile中设置的ID相同

bash-5.0$ id uid=9999(abc) gid=9999(abc) groups=9999(abc) 

您期望发生的情况：Pod中容器的GID也应为999

如何复制（尽可能少且精确）： Dockerfile添加“用户999:999” 然后启动吊舱中的容器

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: test
      imagePullPolicy: Never
      command: ["/bin/sh", "-c", "trap : TERM INT; sleep infinity & wait"]

环境：

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

OS (e.g: cat /etc/os-release): Fedora release 30 (Thirty)

docker版本 客户： 版本：18.09.9 API版本：1.39 Go版本：go1.11.13 Git提交：039a7df9ba 建成日期：2019年9月4日星期三16:52:09 OS/Arch:linux/amd64 实验性：错误

服务器：Docker引擎-社区 发动机： 版本：18.09.9 API版本：1.39（最低版本1.12） Go版本：go1.11.13 Git提交：039a7df 建造时间：2019年9月4日星期三16:22:32 OS/Arch:linux/amd64

---

实验性：false

我意识到这不是您所要求的，但由于我不知道

USER

指令为何不被遵守，我将指出您通过

spec:
securityContext：
runAsUser:999
runAsGroup:999
容器：
- ...

我看到您正在使用

：最新的
和
从不
的
PullPolicy
；你确定这张照片就是你认为的那样吗？使用its可以很好地验证是的，我使用docker build在本地环境中创建映像只是为了测试。本地构建#docker inspect--format='{{.repodgests}}'abc:latest[]很有趣，所以您运行的是minikube还是什么？或者直接在节点上构建映像？在问题中，我直接在节点上构建测试。但实际上使用从存储库中提取的图像也有相同的结果。我已经在上面的问题中更新了Docker版本。我使用的Kubernets可以部署为多个节点，所以我认为它不是minikube。我将与工具专家确认它是什么。如何看到它是什么？你也可以试一下你的环境吗？我想可能会有同样的结果。你能用runAsGroup在Pod的容器中显示
cat/etc/passwd
吗。也许这是kubernetes的一个缺陷或一个限制？这肯定不是kubernetes的一个限制或缺陷，有无数图像以非根运行（elasticsearch是我能想到的最著名的一个）；这就是为什么我一直在问你的情况——对你来说有一些奇怪的事情会导致这种行为，我猜你正在运行的图像不是你认为你正在运行的图像对不起，我写了错误的图像名称，但我在测试中使用了相同的图像。你也可以试着复制一下吗。我认为其他人没有问题是因为他们使用runAsGroup。他们不使用docker“用户”设置的UID和GID。