Kaniko可在非root Kubernetes Pod中安全构建推送镜像，关键在于强制配置runAsNonRoot: true、runAsUser: 1001、fsGroup: 1001，配合initContainer预处理权限、Secret挂载registry认证、ConfigMap挂载私有CA证书，并启用缓存与资源限制。
可以直接在非 root 的 Kubernetes Pod 里用 Kaniko 构建并推送镜像，关键不是“能不能”，而是“怎么配才不报错、不被拒绝、不拉不到基础镜像”。核心是让 Kaniko 以 uid 1001 运行，同时确保它能读源码、写缓存、连仓库、验证书——全部都不依赖 root 权限。
Pod 安全上下文必须显式锁定非特权身份
Kaniko 官方镜像默认以 UID 1001 启动，所以你的 Pod 不能靠默认行为，必须强制约束：
- runAsNonRoot: true —— 禁止容器以 root 启动，哪怕镜像里写了 USER root 也会失败
- runAsUser: 1001 —— 明确指定运行用户，避免因默认 UID 不一致导致文件权限拒绝（比如挂载的 emptyDir 属主是 root，1001 就写不了）
- fsGroup: 1001（配合 emptyDir 使用）—— 让挂载卷自动把属组设为 1001，保证 initContainer 克隆的代码能被主容器读取
- 禁用 privileged: true 和所有 capabilities —— 即使 Kaniko 不需要，也别留空子
源码和 Dockerfile 要能被 UID 1001 正常访问
不能直接挂 hostPath 或 configMap 到 /workspace 就完事。Kaniko 需要读写构建上下文，而 configMap 默认只读、hostPath 权限不可控。
- 推荐用 initContainer + emptyDir：用 alpine/git 拉代码，然后 chown -R 1001:1001 /workspace，再退出
- 如果必须用 configMap 存 Dockerfile，加 defaultMode: 0644 到 volumeMounts，并确保内容不带 root-only 字段（如 COPY --from=0 /app /app 要求多阶段基础镜像本身可拉取）
- 避免把整个项目打包进镜像再运行 Kaniko —— 那就失去“动态构建”意义，也绕不开镜像体积膨胀问题
私有仓库认证与 TLS 信任要分两层处理
很多人只配了 ~/.docker/config.json，结果卡在 拉基础镜像（FROM）失败，因为 Kaniko 拉 base image 和推最终镜像走的是两套校验逻辑。
- 推镜像认证：把 docker config.json 打包成 Secret，挂载到 /kaniko/.docker/config.json，Kaniko 自动识别
-
拉基础镜像认证：若 base image 在私有 Harbor 且用了自签名证书，仅 --insecure 不够，必须：
① 把 CA 证书（ca.crt）用 ConfigMap 挂载到容器内（如 /etc/ssl/certs/ca.crt）
② 启动参数加 --certificate-dir=/etc/ssl/certs
③ 若 registry 是 HTTP 地址（非 HTTPS），额外加 --insecure-registry harbor.example.com
二次构建场景下建议启用缓存并限制资源
所谓“二次构建”，通常指基于已有镜像做增量修改（例如 patch config、替换二进制、打 label）。这时缓存能显著提速，但没配好反而会污染或冲突。
- 用 --cache=true --cache-repo=harbor.example.com/kaniko-cache，缓存镜像也走同一套认证和证书配置
- 给容器设 resources.requests/limits（比如 2Gi 内存），Kaniko 解压 base image+快照比对很吃内存，OOMKill 是静默失败最常见原因
- 加 --reproducible 参数，去掉时间戳和随机 ID，让相同输入产出完全一致的 digest，方便验证二次构建是否真的只改了想改的部分
