Deployment cover Dockerfile

deployment vs docker file

核心

• [x] 需要注意的是 Dockerfile 中的内容在镜像构建时已经固化进入镜像。Deployment 只是在运行时进一步覆盖这些设置

在 Kubernetes Deployment 中定义的容器 spec.containers 参数会覆盖 Dockerfile 中定义的一样参数。

• 主要的覆盖情况包括:
• image: Deployment 中指定的镜像会覆盖 Dockerfile 的 FROM 指令指定的镜像。
• ports: Deployment 的 ports 会覆盖 Dockerfile 中的 EXPOSE 指令。
• environment: Deployment 中的 env 会覆盖 Dockerfile 中的 ENV 指令设置的环境变量。
• commands: Deployment 的 commands 会覆盖 Dockerfile 中的 CMD 指令。
• args: Deployment 的 args 会被附加到 Dockerfile 中 CMD 指令的参数后面。
• workingDir: Deployment 的工作目录会覆盖 Dockerfile 的 WORKDIR 指令。 另外,Deployment 中的资源限制如 cpu、memory 也会覆盖 Dockerfile 中的参数。 Deployment 的设定优先级高于 Dockerfile。所以在部署时,必定要确认 Deployment 的参数是否符合预期,尤其是与镜像内容有关的参数要仔细核对。

控制容器内的用户和用户组

GKE 容器的安全上下文主要有 3 个选项可以控制容器内的用户和用户组:

fsGroup:设置 pod 中容器的文件系统组,即运行容器进程的组 ID。这个组会拥有容器内新建文件的所有权。

runAsUser:设置 pod 中容器的运行用户 ID。容器进程会以这个 UID 运行。

runAsGroup:设置 pod 中容器的主要组 ID。容器进程会加入这个组。

这 3 个选项的区别和关系如下:

fsGroup 控制文件系统权限,用于容器内新建文件的组ownership。 runAsUser 和 runAsGroup 组合控制运行容器进程的用户和主组。 一般来说,fsGroup 需要和 runAsUser 保持一致,以避免文件权限问题。

runAsUser 控制容器进程的用户 ID。runAsGroup 控制进程的主组 ID。一个进程同时也会有多个附加组。

所以为了容器内文件和进程权限的一致性,最佳实践是:

设置 runAsUser 为某 UID 设置 runAsGroup 为和 runAsUser 一样的 GID 设置 fsGroup 也为这个 GID 这样容器进程用户和主组就能和文件系统组保持一致,避免权限问题。

总结一下:

fsGroup – 文件系统组 runAsUser – 进程用户ID runAsGroup – 进程主组ID fsGroup 要与 runAsUser 和 runAsGroup 设置为同一个 ID 才能保证文件系统权限正常。

选项是否必须

配置 GKE 容器安全上下文中的 fsGroup、runAsUser 和 runAsGroup 这几个选项不是必须的。

如果不指定这些选项,GKE 会使用一些默认设置:

不指定 runAsUser 和 runAsGroup,默认会使用容器镜像内配置的用户,一般是 root。

不指定 fsGroup,默认文件系统组会使用 runAsGroup,如果 runAsGroup 也没有指定,则使用 root 组。

如果指定了 runAsUser 但没有指定 runAsGroup,runAsGroup 会默认设置为和 runAsUser 一样的 UID。

如果只指定了 fsGroup 没有指定 runAsUser 和 runAsGroup,进程用户和组依旧是默认的 root。

所以这些选项都是可选的,主要作用是在需要为容器进程和文件系统设置特定的用户和组时使用。

一些常见的使用场景:

设置非 root 用户来提高安全性 让容器进程与宿主机上的用户保持一致 多容器间文件共享需要用到 fsGroup 如果没有这些特殊需要,可以不设置安全上下文,GKE 会使用默认的 root 用户运行容器。