Kaniko 和 Buildah 更安全，因其无需 Docker Daemon 和 root 权限，不挂载 /var/run/docker.sock，避免节点级逃逸；均以非 root 运行，不支持 --privileged，天然规避特权容器风险。
为什么 Kaniko 和 Buildah 在集群内构建比 Docker Daemon 更安全
Docker Daemon 必须以 root 权限运行，且暴露 /var/run/docker.sock 给构建容器时，等于把宿主机的容器控制权交出去——哪怕只跑一个构建任务，也等同于给 Pod 赋予了集群节点级逃逸能力。Kaniko 和 Buildah 都是无守护进程（daemonless）工具，不依赖 dockerd，也不需要挂载 /var/run/docker.sock；它们直接解析 Dockerfile、拉取基础镜像、执行指令、生成层并推送到 registry，整个过程在普通用户权限下完成。
- Kaniko 默认以非 root 用户（UID 1001）运行，支持通过
--skip-tls-verify-pull、--registry-mirror等参数控制镜像拉取行为 - Buildah 更底层，可精细控制命名空间（如
--isolation=chroot）、用户命名空间映射（--userns-uid-map），但默认不自动 drop capabilities - 两者都不支持
docker build --privileged这类危险模式，天然规避了绝大多数因特权容器导致的逃逸路径
如何让 Kaniko 在 Kubernetes 中真正以非 root 运行
Kaniko 镜像虽声明了 USER 1001，但若 PodSpec 中未显式约束，Kubernetes 可能因 SecurityContext 缺失或 PSP/PSA 配置宽松而回退到 root。常见错误现象是日志里出现 permission denied on /workspace 或构建时突然报 mkdir /kaniko/.docker: permission denied——这往往不是 Kaniko 本身问题，而是它试图写入被拒绝的路径。
- 在 Pod 的
securityContext中必须设置：runAsNonRoot: true、runAsUser: 1001、fsGroup: 1001 - 挂载的
emptyDir或 PVC 必须允许 group-writable（Buildah 尤其敏感），否则buildah bud会卡在 layer commit 阶段 - 若使用私有 registry，凭证不要硬编码进镜像，应通过
imagePullSecrets或挂载/kaniko/.docker/config.json（注意该文件权限需为0600，否则 Kaniko 拒绝读取）
Buildah 构建时为何突然失败：error creating overlay mount
这个错误几乎都指向底层存储驱动不兼容或权限失控。Buildah 默认用 overlay 存储驱动，但在容器中运行时，若宿主机内核不支持 overlayfs（如某些旧版 CentOS 或启用了 overlay2 但未开启 overlay 模块），或者容器运行时（如 containerd）未正确传递 mount propagation，就会触发该错误。
- 不要在 Docker Desktop 或 kind 集群上直接复用本地 Buildah 配置；集群内务必用
buildah --storage-driver=vfs回退到 vfs（性能差但最稳） - 若坚持用 overlay，需确保节点已加载
overlay内核模块（modprobe overlay），且容器 runtime 允许shared挂载传播（Pod 中加volumeMounts[].mountPropagation: "HostToContainer"） -
buildah from拉取镜像时若遇 TLS 错误，别急着关验证，先确认节点时间是否同步——很多私有 registry 的证书因系统时间偏差被拒，表现为 “x509: certificate has expired or is not yet valid”
Kaniko 构建缓存失效的三个隐性原因
Kaniko 支持 --cache=true --cache-repo=xxx 复用远程层，但缓存命中率低常不是配置错，而是构建上下文或指令写法触发了“不可复用”的语义变更。
-
COPY . /app后接RUN npm install：只要工作目录下任意文件变动（包括.git/、node_modules/），整个 COPY 层哈希就变，后续所有 RUN 都无法复用——应改用COPY package*.json ./+RUN npm ci分离依赖与源码 - 使用
--snapshot-mode=redo（默认）时，Kaniko 对文件 mtime 敏感；若 CI 系统统一设置了源码文件时间为 epoch 0，会导致相同内容产生不同快照——可改用--snapshot-mode=hardlink或time模式 - 缓存 registry 若启用了
immutable tags（如 ECR 的 image immutability），Kaniko 推送缓存层时会静默失败，日志只显示 “failed to push layer”，需提前确认 registry 是否允许覆盖同 digest 的 blob
实际部署时，最易被忽略的是节点层：Kaniko 和 Buildah 都依赖 glibc 和内核特性，比如在基于 Alpine 的最小镜像中运行 Kaniko，可能因缺少 libseccomp 导致 syscall 过滤异常；而 Buildah 在 RHEL 8+ 节点上若未安装 skopeo，buildah push 到某些 registry 会因缺少 auth 插件失败。这些都不是文档里写的“支持”，而是运行时才暴露的毛细血管级依赖。
