为什么 Docker CMD 在 GKE 中作为 chronos 运行？答案

【问题标题】：Why is Docker CMD running as chronos in GKE?为什么 Docker CMD 在 GKE 中作为 chronos 运行？
【发布时间】：2021-09-11 13:14:02
【问题描述】：

我在 GKE 上运行了一个 pod 和 NodePort 服务。

在我的 pod 中容器的 Dockerfile 中，我使用 gosu 以特定用户身份运行命令：

startup.sh

exec /usr/local/bin/gosu mytestuser "$@"

Dockerfile

FROM ${DOCKER_HUB_PUBLIC}/opensuse/leap:latest

# Download and verify gosu
RUN gpg --batch --keyserver-options http-proxy=${env.HTTP_PROXY} --keyserver hkps://keys.openpgp.org \
      --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 && \
    curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64" && \
    curl -o /usr/local/bin/gosu.asc -SL "https://github.com/tianon/gosu/releases/download/1.12/gosu-amd64.asc" && \
    gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu && \
    chmod +x /usr/local/bin/gosu

# Add tini
ENV TINI_VERSION v0.18.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--", "/startup/startup.sh"]

# Add mytestuser
RUN useradd mytestuser

# Run startup.sh which will use gosu to execute following `CMD` as `mytestuser`
RUN /startup/startup.sh
CMD ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/helloworld.jar"]

我刚刚注意到，当我在 GKE 上登录容器并查看正在运行的进程时，我希望以 mytestuser 运行的 java 进程实际上是以 chronos 运行的：

me@gke-cluster-1-default-ool-1234 ~ $ ps aux | grep java
root        9551  0.0  0.0   4296   780 ?        Ss   09:43   0:00 /tini -- /startup/startup.sh java -Djava.security.egd=file:/dev/./urandom -jar /helloworld.jar
chronos     9566  0.6  3.5 3308988 144636 ?      Sl   09:43   0:12 java -Djava.security.egd=file:/dev/./urandom -jar /helloworld.jar

谁能解释发生了什么，即chronos 用户是谁，为什么我的进程没有以mytestuser 运行？

【问题讨论】：

标签： docker kubernetes google-kubernetes-engine gosu

【解决方案1】：

当您RUN adduser 时，它会在图像的 /etc/passwd 文件中分配一个用户 ID。您的脚本使用该数字用户 ID 启动进程。但是，当您随后从主机运行 ps 时，它会在 主机的 /etc/passwd 文件中查找该用户 ID，并得到不同的结果。

这种差异通常无关紧要。如果您要从主机绑定挂载目录，则只有数字用户 ID 对文件系统权限等事项很重要。出于安全考虑，数字用户 ID 不能为 0 很重要，但它被普遍命名为 root。

【讨论】：

【解决方案2】：

当您在容器内（或作为映像构建的一部分）运行 useradd 时，它会将 am 条目添加到容器内的 /etc/passwd。除非您启用用户命名空间，否则 uid/gid 将与主机共享命名空间。但是，这些 id 到名称的映射将特定于进程运行的文件系统命名空间。因此在这种情况下，容器内的 mytestuser 的 uid 恰好与宿主机上的 chronos 的 uid 相同。

【讨论】：