Kustomize 与 Helm：有什么区别？

在管理和部署 Kubernetes 应用程序时，有两个工具始终脱颖而出：Kustomize 和 Helm。两者都简化了 Kubernetes 部署的复杂性，但它们采用了根本不同的方法来解决同一难题。

Helm 是 Kubernetes 的包管理器，它将应用程序所需的所有内容捆绑到一个名为 Helm 图表的可重复使用的包中。Kustomize 是一款 Kubernetes 原生工具，它采用声明式方法，通过使用补丁和覆盖来修改需要使用模板语言的基本配置。

在这些工具之间做出选择不仅仅是一种技术偏好，它直接影响开发团队的工作效率、运营成本以及可靠地扩展应用程序的能力。许多组织发现结合使用这两种工具具有重大价值，但了解何时以及为何选择每种方法对于构建有效、可扩展的 Kubernetes 部署和管理策略至关重要。

在研究 Kustomize 和 Helm 之前，先了解一下容器化是有帮助的，它是现代云原生应用程序的基础。

容器化将应用程序与运行所需的一切，包括代码、库和配置，打包成轻量级、可移植的单元，这称为容器，通常在基于 Linux 的系统上运行。该过程使软件能够在各种环境中持续运行，从开发人员笔记本电脑到生产云基础设施。

Kubernetes（又称“k8s”或“kube”）通过跨机械聚类自动化部署、扩展和资源管理来大规模编排容器（通常基于 Docker）。

根据云原生计算基金会 (CNCF) 2024 年的一项调查，在受访的组织中，云原生的采用率达到 89% 的历史新高，其中 93% 的受访组织正在使用、试用或评估 Kubernetes。¹

随着组织从简单的应用程序转移到复杂的多服务架构，管理 Kubernetes 部署所需的配置文件变得越来越复杂。典型的企业应用程序可能需要数十个配置文件，每个文件都需要针对不同的环境（开发、暂存和生产）进行定制。

这种复杂性带来了若干业务挑战：

• 难以维持跨环境的一致性

• 运营费用增加

• 缺乏部署自动化，就会导致人为错误

• 新功能上市时间更长

Kustomize 和 Helm 都是为了应对这些挑战而创建的，但它们采用的方法截然不同。Helm 率先进入市场，当时是由 Deis（后来被 Microsoft 收购）作为旨在简化 Kubernetes 应用程序管理的最早期工具之一推出的。Deis 于 2018 年将其捐赠给 CNCF 时，该项目进一步获得了可信度，并于 2020 年获得了 CNCF 完全毕业状态。

与此同时，Kubernetes 采取了不同的方式，在 2019 年发布 Kubernetes 1.14 时将 Kustomize 直接集成到 kubectl 命令行界面 (CLI) 中。

Kustomize 采用声明式配置管理方法。DevOps 开发运维和其他团队并不编写脚本来描述如何实现特定状态，而是描述他们希望最终配置是什么样子。

该工具采用“基础和叠加”方法。团队负责维护标准化基础配置，以捕获其应用程序的核心特征。然后，团队会针对各个环境或变量，创建仅指定特定情境所需差异的叠加。

考虑一个基本配置，它定义了一个具有标准资源要求和基本网络设置的 Web 应用程序。开发覆盖可能会减少资源限制和副本以节省成本，而生产覆盖可能会增加安全设置并添加监控组件。Kustomize 合并这些配置以生成最终部署 Kubernetes 清单（YAML 或 JSON 文件），描述 Kubernetes 资源的所需状态。

Kustomize 可直接兼容原生 YAML 清单文件（例如 deployment.yaml），该文件中包含标准 Kubernetes 字段（如 apiVersion）。这一方法可消除团队对模板语言的需求以确保其轻松应用，而无需学习标准 Kustomize YAML 配置之外的其他编码语法。借此，团队可以快速实施复杂的配置管理，同时使用其熟悉的 Kubernetes YAML 语法。

Helm 是市场上最受欢迎的 Kubernetes 软件包管理器，本质上充当 Kubernetes 应用程序的应用程序商店，支持轻松管理和安装预打包的应用程序。根据 CNCF 最近的调查，Helm 是首选 Kubernetes 包管理器，在运行 Kubernetes 的组织中采用率为 75%。²

Helm 将应用程序打包到“Helm 图表”中；“Helm 图表”是预配置的 Kubernetes 资源的集合，团队可以将这些资源作为一个单元进行安装、升级和管理。各 Chart 都包含配置文件（如 chart.yaml）并使用 Go 模板根据输入值实现动态配置。

Helm 的优势在于其模板引擎和包管理能力。借助 Helm，团队无需维护相似配置的多个版本，而是使用占位符创建图表并使用单独的值文件（例如 values.yaml）在部署期间填充这些占位符。在将最终呈现的配置应用于 Kubernetes 集群之前，团队可以使用 helm 模板进行预览。

除了模板之外，Helm 还提供全面的生命周期管理功能，包括回滚部署、管理发布和跟踪部署历史记录的功能。这些功能使得 Helm 对于组织管理复杂应用程序组合来说很有价值，因为编排和回滚功能至关重要。

例如，一家电子商务公司可以为其在线商店使用一个图表，但可以针对不同的环境（用于测试的服务器较少，用于生产的服务器较多）对其进行定制，而无需创建单独的配置文件。

团队需要使用 helm install 来部署这些图表，这会通过 Kubernetes 应用程序编程接口 (API) 自动将所有资源应用到目标 Kubernetes 集群。Helm 自动处理版本控制和依赖项管理，确保部署的一致性和可靠性

如何在 Kustomize 和 Helm 之间做出选择，取决于具体的部署挑战和业务目标。面向不同环境定制同一应用程序的组织通常可从 Kustomize 中获益。而对于管理多个应用程序或需要复杂部署控制的组织，Helm 则更为合适。

下文将详细介绍每种解决方案的最佳适用场景。

大多数组织需要在开发、暂存和生产环境中部署相同的应用程序，这些环境之间存在细微但重要的差异。Kustomize 在这种情况下表现出色，它允许团队在应用特定于环境的修改的同时维护单一可信信息源。

开发环境可能需要减少资源限制以节省成本，而生产环境则需要增强的安全设置、不同的 ConfigMap 和监视组件。Kustomize 使组织能够定义这些差异，而无需复制整个配置文件。

不同的部署情况通常需要不同的安全策略或合规措施。Kustomize 允许团队将这些需求叠加到基本配置上，而无需创建完全独立的配置集。这一能力对于在监管要求各不相同的多个地区或行业中开展业务的组织而言非常有价值。

在大型应用程序组合中推出配置更改时，Kustomize 使团队能够在不中断整个配置结构的情况下进行增量修改。这种方法降低了风险，并且更容易识别和修复配置错误或部署失败等问题。

Helm 的主要优点之一是其打包功能，这对构建平台或寻求实现跨团队的应用程序部署标准化的组织尤其有利。

团队可以创建可重复使用的图表，以记录最佳实践和组织标准，然后在整个企业中分发。

需要复杂部署编排的应用程序，例如多步推出、依赖项管理和回滚能力，非常适合 Helm 的发布管理功能。如果出现问题，Helm 可以立即恢复到之前的工作版本，从而减少对用户的影响。

当集成流行的开源应用程序或供应商解决方案时，Helm 的全面图表存储库能提供预构建的包，从而显著缩短实施时间。

团队可以充分利用社区维护的数据库图表、监控系统持续集成或持续交付 (CI/CD) 管道和其他标准 IT 基础设施组件，而无需从头开始构建配置。

SaaS 平台通常使用 Helm 来管理客户特定的应用程序部署，在不同的命名空间中使用不同的配置多次部署同一个应用程序。这种方法提供了多租户架构所需的隔离和定制。

Kustomize 在 Kubernetes 配置管理方面具备多种优势，包括：

组织选择 Helm 的原因，正是基于这些优势。

许多组织并不将 Kustomize 和 Helm 视为相互竞争的解决方案，而是认为将这两种工具结合使用具有重大价值。这种混合方法发挥了每种工具的优势，同时减轻了它们的局限性。

以下是部分常见用例：

• 初始部署和环境定制

• 具有自定义配置的第三方应用程序

• 多团队环境

典型的联合使用模式包括实施 Helm 进行初始应用程序打包和部署，然后使用 Kustomize 应用特定于环境的定制。这种方法提供了 Helm 的包管理和发布功能的优点，同时保持了 Kustomize 对持续配置管理的简单性和透明度。

例如，组织可能会使用 Helm 图表来部署微服务应用程序及其所有依赖项。下一步是使用 Kustomize 覆盖来为生产添加安全策略或为暂存配置不同的 Kubernetes 入口规则。

组织通常采用 Helm 基于其广泛的 Chart 存储库部署第三方应用程序，同时使用 Kustomize 部署自定义应用程序，从而更直接地控制配置管理。

这种组合使团队能够将社区维护的图表用于常用工具（例如监控系统或消息队列），同时保持对其专有应用程序的完全控制。

在拥有多个开发团队的大型组织中，平台团队通常会创建标准化 Helm Chart，其中包含组织最佳实践和合规要求。这些 Chart 可与基础设施即代码 (IaC)（如 Terraform）工具协同使用，以管理整个部署管道。

然后，各开发团队使用 Kustomize 为其特定应用程序和环境定制这些图表，而无需修改基本图表。这种方法创建了一种清晰的分隔，可以与 ArgoCD 等 GitOps 工具无缝集成，实现自动化工作流。

有效的 Kubernetes 配置管理需要灵活的战略，以适应不断变化的应用需求。

理解 Helm 和 Kustomize 之间的差异，并了解如何有效地集成它们，有助于降低复杂性并保持一致性。这种战略组合最终带来更具可维护性和可扩展的 Kubernetes 环境。