Zarf：为 Kubernetes 离线环境设计的声明式打包工具

离线交付的痛点与 Zarf 的定位

在完全断网的 Kubernetes 集群里部署应用，通常要手动搬运镜像、Helm chart 和 Git 仓库。这个过程中最容易出错的是镜像引用：应用部署清单里写死的镜像地址，在离线环境里根本拉不到。Zarf 的解法是把这些依赖打包成一个单文件，同时内置一个镜像仓库和 Git 服务器，在目标集群里自动重建拉取环境。它面向的是 DevSecOps 团队，尤其是那些需要把应用从联网的开发环境转移到隔离的生产环境的场景。README 明确说它支持边缘计算、嵌入式系统和安全云环境，但也不排除本地开发。本质上，Zarf 不是要替代 Helm，而是把 Helm chart 连同其依赖一起封装，让离线部署变成一条命令的事。

打包、发布与部署：Zarf 的核心循环

Zarf 的工作流分为三个阶段：打包、发布、部署。打包阶段，开发者在一个联网环境中定义 zarf.yaml 文件，声明组件、镜像、Git 仓库和 Helm chart。Zarf 会拉取这些资源，生成一个压缩的单一文件，同时自动生成 SBOM。发布阶段，这个包可以被推送到 OCI registry，或者直接拷贝到离线机器。部署阶段，在目标集群中执行 zarf package deploy，Zarf 会启动内置的 Docker registry 和 Gitea 实例，重写部署清单中的镜像路径，指向本地 registry。这个机制的关键在于镜像重写：它通过 mutating webhook 自动更新 pod 的镜像路径和 pull secret，也处理 Flux GitRepository 的 URL。这意味着，只要你的应用清单遵循标准镜像引用，Zarf 就能在离线环境中无缝替换。但如果你有硬编码的绝对镜像地址，或者应用在运行时动态构造镜像名，这个机制就会失效。

一条命令跑通：从安装到部署

根据官方文档，安装 Zarf 只需下载静态编译的 CLI 二进制，它没有任何运行时依赖。初始化一个集群需要执行 zarf init，这个命令会部署内置的镜像仓库、Git 服务器和日志组件。对于完全离线的集群，Zarf 支持用 K3s 直接创建新集群，或者通过 kubeconfig 接入现有集群。创建包用 zarf package create，部署用 zarf package deploy。如果你使用 GitHub Actions，官方提供了 setup-zarf action，可以安装任意版本的 Zarf 及其 init 包，同样零依赖。一个典型的流程是：开发者在联网机器上执行 zarf package create，生成 tarball；然后通过移动介质或安全网络传到离线环境；最后执行 zarf package deploy。整个过程不需要手动导入镜像或克隆仓库，因为 Zarf 已经把 Git 仓库和镜像都塞进了包内。

内置组件：不只是包管理器

Zarf 的定位远超一个打包工具。它内置了 Gitea 作为 Git 服务器，内置 Docker registry，还附带 K9s 仪表盘，用于在终端管理集群。这意味着，离线环境中的开发人员不仅可以用 Zarf 部署应用，还能在断网状态下继续使用 Git 和容器镜像。另外，Zarf 提供 zarf connect 命令，通过隧道连接到 Kubernetes 资源，无需配置网络路由、DNS 或 Ingress。这在网络受限的环境中非常实用，因为你不必为每个服务暴露端口。但内置组件也意味着额外的资源占用，如果你的集群资源紧张，这些组件可能会成为负担。README 中也提到，Zarf 支持继承遗留代码，你可以把旧应用打包进去，部署到现代 DevSecOps 环境。

安全与供应链：SBOM 与签名

Zarf 在打包时自动生成软件物料清单（SBOM），并提供 Web 仪表盘来查看这些 SBOM 输出。这对于需要满足合规要求的组织来说是一个加分项。同时，Zarf 支持使用 cosign 对包进行签名和验证。这意味着，你可以确保离线环境中部署的包没有被篡改。但要注意，SBOM 的准确性取决于打包时对依赖的扫描，如果应用使用了动态加载的插件或外部依赖，SBOM 可能不完整。签名机制也要求你在构建流程中管理 cosign 密钥，这增加了额外的运维复杂度。根据 README，Zarf 的早期研究与美国海军研究生院合作，这暗示其设计考虑了军事和政府环境的安全需求，但这不是一个功能保证，只是背景信息。

限制与失败模式：何时不该用 Zarf

Zarf 不是万能的。首先，它假设你的应用镜像可以通过重写路径来适应内置 registry。如果你的应用使用私有镜像仓库且不遵循标准命名，或者镜像标签在运行时被修改，Zarf 的 mutating webhook 可能无法正确重写。其次，Zarf 的打包过程需要访问互联网来拉取依赖，这意味着你必须在联网环境中构建包，这违背了“完全离线”的初衷，但这是所有类似工具的共性。第三，Zarf 内置的 Git 服务器和镜像仓库会占用集群资源，并且你需要维护这些组件的版本。最后，如果你已经有一个成熟的私有镜像仓库和 Git 服务器，Zarf 可能会显得多余，因为你可以手动配置离线环境，但那样会失去声明式部署的便利。一个具体的失败案例是：如果 Helm chart 中包含 initContainer 脚本，它动态拼接镜像地址，Zarf 的重写机制就无能为力。

替代方案：Helm 与 K3s 的原始组合

如果你不想引入 Zarf，最简单的替代方案是手动使用 Helm 和 K3s。K3s 自带嵌入式 registry，但你需要手动导出和导入所有镜像，并手动修改每个部署的镜像地址。Helm chart 可以打包应用，但无法处理镜像传输。另一个替代方案是使用开源的 Harbor 作为镜像仓库，配合 Git 镜像工具如 GitLab 的 Geo 或 Gitea 的镜像功能，但你需要自己编写脚本同步依赖。Zarf 的差异在于它把这些步骤自动化，并通过声明式配置文件统一管理。相比之下，Zarf 更“重”，但更可控。如果你只是偶尔离线部署，手动方案可能更快；如果你需要频繁且可靠地交付，Zarf 的自动化优势明显。

维护成本与许可证

Zarf 采用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，甚至用于商业用途，但需要保留版权声明和许可文本。维护成本方面，Zarf 的发布节奏较快，最近的版本 v0.84.0 于 2026 年 8 月发布，v0.83.0 在 8 月初，这表明项目活跃，但你需要跟上版本更新，因为 API 可能变化。文档提供了架构图和“Nerd Notes”，但学习曲线依然存在，尤其是理解 zarf.yaml 的组件依赖和 actions 机制。另外，Zarf 的文档明确提到 OS 支持矩阵“即将推出”，这意味着跨平台兼容性尚未完全明确，你在非 Linux 环境使用前需要自行验证。升级 Zarf 时，你需要同时更新 CLI 和 init 包，因为两者必须匹配，这可能会增加操作步骤。

编辑结论

Zarf 适合那些需要在完全断网或半连接环境中交付 Kubernetes 应用，且愿意接受打包流程前期投入的团队。它不适合仅偶尔离线、或对镜像和 Git 仓库有严格私有化要求的场景。采用前应先验证三件事：其一，确认你的目标集群支持 Zarf 的 init 包，尤其是 K3s 部署模式；其二，检查你的 Helm chart 和镜像是否包含动态拉取地址，这会绕过 Zarf 的镜像重写机制；其三，评估 OCI registry 的可用性，因为发布和拉取功能依赖它。Zarf 的最终价值在于把“联网构建、离线部署”变成一条可重复的流水线，但这条流水线需要你为每个组件显式声明依赖，没有捷径。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes