Kaniko 曾经回答的是一个清楚的 CI 问题：怎样在 Kubernetes 里面，从 Dockerfile 构建 container image，同时不把 Docker daemon 或 privileged container 交给构建任务？它的 README 把价值说得很直接：Kaniko 在 container 或 Kubernetes cluster 里构建，不依赖 Docker daemon，并且在 userspace 执行 Dockerfile 命令，因此可以运行在难以暴露 daemon 或暴露 daemon 会带来风险的环境中。[1]

这条技术论证今天仍然容易理解。发生变化的是治理论证。2025 年 6 月 3 日，GoogleContainerTools/kaniko 被归档并设为 read-only。仓库页面现在说明，这个项目已经“no longer developed or maintained”，代码保留给历史用途。[1] 到 2026 年，真正有用的问题已经从“Kaniko 是否能解决无守护进程构建”变成“继续使用 Kaniko 时，你实际采用的是哪一份维护契约？”

截至 2026-05-31T12:36:10Z UTC，原始仓库仍然保留着过去的公开规模信号：一个已归档仓库上大约有 15.8k stars、1.5k forks、707 个 open issues，以及 53 个 open pull requests。[1] 这是一种异常可见的基础设施余生。上游停止之后，用户群没有消失。项目转而分裂成历史上游、Chainguard 维护的 fork、社区 fork，以及正在决定是否迁移离开的下游平台。[2][3][4][6][7]

配图说明：题图使用 2014 年 Wikimedia Commons 上 Google 第一台生产服务器机架在 Googleplex 的真实照片。[8] 它不是 Kaniko 截图或 logo。这个选择是有意的：本文讨论的是一类基础设施，它的有用性会超过第一任拥有者的管理周期；当一层旧而广泛使用的系统变成别人的责任，维护负担也随之显形。

原始架构解决了真实的构建运行器问题

Kaniko 的核心设计从来不神秘，这也正是它得以传播的一部分原因。executor image 会解开 base image filesystem，运行 Dockerfile 命令，在 userspace 中于每一步之后对 filesystem 做 snapshot，把变化的文件追加成 layers，并更新 image metadata。[1] 这让 Kubernetes-native 构建任务能够生成 OCI-style image，同时不用挂载 /var/run/docker.sock，也不用运行嵌套 Docker daemon。

受支持的 context 模型进一步强化了这种 CI 形态。原始 README 列出的 build contexts 来自 GCS、S3、Azure Blob Storage、local directories、local tar files、standard input 和 Git repositories。[1] 它也记录了面向 Docker Hub、GCR、ECR、Azure Container Registry、JFrog 以及其他目的地的 registry push 路径。[1] 也就是说，Kaniko 不只是一个巧妙的 executor binary。它变成了连接 source context、Kubernetes job isolation、registry credentials、layer caching 与 multi-cloud CI runners 的胶水层。

这也是归档真正重要的原因。一个工具越像胶水，项目越难把维护当成可有可无的附属事项。每一次 dependency update、registry API change、base-image behavior 变化、CI runner convention 调整，都能变成团队发布路径上的故障，因为这些团队已经把构建工具写进了 release path。

归档把规模变成负债

原始仓库自己的文字现在就是最强的治理信号：“archived”、“read-only”、“no longer developed or maintained”。[1] 对一个会运行构建指令并处理 registry credentials 的工具来说，这不是小注脚。它意味着旧文档、旧 images、旧 issue threads 与旧安装示例，都应被当成历史材料阅读，除非团队已经选择了一个受维护的继任路径。

归档 README 里的安全章节同样重要，因为它阻止了一种常见的过度主张。Kaniko “by itself does not make it safe to run untrusted builds”，并依赖 container runtime 的安全特性来提供构建安全。[1] 这在归档之前就成立，归档之后含义更尖锐。无守护进程构建工具减少了一类风险：对 Docker daemon 或 privileged container 的直接依赖。它没有取消隔离构建任务、理解 Dockerfile trust、保护 credentials、持续修补 builder image 的需要。[1]

维护陷阱就在这里。许多团队采用 Kaniko，是把它当成优于 Docker-in-Docker 的安全改进。归档之后，同一套安全叙事取决于 patches、images 与 support 现在来自哪里。如果没有人承担这些部分，旧的“比暴露 Docker 更安全”这一论证就会开始衰减。

各个 fork 给出的契约并不相同

Chainguard 的 fork 给出了最明确的连续性主张。它的仓库说明，自己是原始 Google 仓库的 supported replacement，是在 2025 年 6 月归档之后创建的，目的在于通过 security patches 与 maintenance 延续维护；它同时说明 no major feature work is planned。[2] 这是一份刻意收窄的契约。它表达的含义更接近一条维护承诺：这个广泛使用的构建工具会继续获得维护注意力。

同一份 README 还画出一条重要的制品边界。它说明 releases 是 source repository 上的 tags，而旧的 gcr.io/kaniko-project/executor 与 gcr.io/kaniko-project/warmer images 已经 unmaintained 且不再更新。用户必须自行构建制品，或者作为客户使用 Chainguard container images。[2] Chainguard 的 image directory 随后补充了自己的供应链姿态：打包 image 包含 SBOM 与 provenance visibility，并被描述为符合 SLSA Level 3。[3]

社区的 osscontainertools/kaniko fork 给出的是另一种承诺。它的 README 说明，这是一个 supported replacement，重点是让 dependencies 保持最新、修复 bugs、改善 performance，并通过 Docker Hub 与 ghcr.io/osscontainertools/kaniko:latest 提供 images。[4] 对需要公开可消费 images 的团队来说，这条路径有吸引力，但它仍然是不同于已归档 Google 项目、也不同于 Chainguard 商业 image 通道的一项信任决策。[2][3][4]

治理信号并不是某个 fork 自动正确。真正的信号在于，“我们使用 Kaniko”已经停止成为精确表述。到 2026 年，团队必须说清 source repository、image registry、patch policy、release verification path 与 fallback plan。

下游文档已经用迁移投票

GitLab 当前文档是一条强独立信号，因为 GitLab 长期是许多人在实践中遇到 Kaniko 的地方。已经移除的 Kaniko 页面现在说明，Kaniko 不再受维护，并引导用户转向 Docker、Buildah、Podman，或在 Kubernetes 上结合 GitLab Runner 使用 Podman。[6] GitLab 的 BuildKit 页面走得更远，它把 BuildKit rootless 列为安全替代方案，并把它定位为 Kaniko 的 replacement。[7]

这并不意味着每一套 Kaniko 存量系统都应立刻迁移。一个 regulated organization 如果拥有正常工作的 jobs、范围收窄的 Dockerfile inputs、经过测试的 runner isolation，并已经选择受维护的 fork，继续保留这一模式可以是理性的。The New Stack 在 2025 年 6 月的报道捕捉到了原因：Google 归档项目后，Chainguard 为那些在 CI/CD pipelines 中依赖它的组织 fork 了 Kaniko，报道还点名 financial services 与 defense 等受影响领域。[5]

但下游文档改变推荐方向仍然构成证据。它说明主要平台维护者已经不再把 Kaniko 当成受限 image builds 的默认答案。他们正在要求用户重新考虑构建工具选择本身。[6][7]

这个信号对仍在使用 Kaniko 的团队意味着什么

实际决策树比围绕它的讨论要短。如果你还在使用 gcr.io/kaniko-project/executor，应把它当成紧急 inventory item，因为旧 images 已经不再沿着原始项目线更新。[2] 如果迁移到 Chainguard fork，需要判断商业 image 模型与 maintenance-only 范围是否符合组织需求。[2][3] 如果使用社区 fork，需要记录这个 fork 的 release 与 artifact path 为什么满足补丁和 provenance 要求。[4] 如果这些契约都不合适，就应在最初让 Kaniko 具备吸引力的同一组 runner constraints 下，测试 BuildKit rootless、Buildah、Podman 或其他构建工具。[6][7]

最重要的教训并不是 Kaniko 失败了。它解决了真实问题，并且重要到归档之后会引发生态位移。[1][2][5] 教训在于，构建工具属于供应链的一部分，不是可以随手替换的 CI 管线配件。无守护进程构建工具仍然需要无守护进程维护：patches、images、provenance、docs、migration guidance，以及当旧路径停止前进时清楚负责的人。

因此，Kaniko 在 2026 年的故事是一条带有架构后果的治理信号。构建模式仍然有用。原始所有权契约已经消失。每个仍在使用它的团队，都必须把这个差异写清楚。[1][2][3][4][6][7]

来源

1. GitHub，GoogleContainerTools/kaniko 已归档仓库——归档日期、原始 README、无守护进程 userspace 构建模型、snapshotting、context support、registry push paths、known issues 与 security caveats。
2. GitHub，chainguard-forks/kaniko——supported replacement statement、2025 年 6 月归档背景、no-major-feature-work note、release artifact boundary 与 unmaintained old image warning。
3. Chainguard Containers，“kaniko” image listing——packaged-image posture、SBOM/provenance claims、SLSA Level 3 compliance statement 与相关 Chainguard artifact options。
4. GitHub，osscontainertools/kaniko——社区 fork 定位、维护重点、image locations 与当前 README guidance。
5. Darryl K. Taft，The New Stack，“Kaniko Lives On: Chainguard Forks Google's Dumped Tool”——关于归档、Chainguard fork，以及依赖组织连续性论证的独立报道。
6. GitLab Docs，“Use kaniko to build Docker images (removed)”——已移除的 Kaniko 指引，以及当前改用其他构建方法的推荐。
7. GitLab Docs，“Build Docker images with BuildKit”——BuildKit rootless 作为安全替代方案及 Kaniko replacement 的定位。
8. Wikimedia Commons，“Computer History Museum Google First Production Server”——本文更清晰的真实摄影题图来源页，图中是 Google 第一台生产服务器机架。