关于程序员:Helm-vs-Kustomize-深度比较

Helm 和 Kustomize 都是风行的 Kubernetes 集群部署管理工具，本文比拟了两者的优缺点，不便读者依据我的项目理论状况采纳适宜的计划。原文: Helm vs Kustomize: why, when, and how

挑战

开始探讨之前，先来看看为什么要应用 Helm 或 Kustomize。

这么多环境，这么多 YAML 文件！

Kubernetes 帮忙咱们非常容易的为不同用例创立不同的环境，能够在同一个集群甚至多个集群上应用命名空间，能够托管开发、测试、QA、UAT、预发、生产……等等不同的环境。但问题是：如何治理所有这些环境？

第一种也是最间接的办法是创立雷同 manifest 的正本，并为每个正本命名。也就是说，把源文件复制粘贴到每个环境上。

对于只需对每个环境做出极少改变的简略我的项目，上述办法可能很实用。例如，除了镜像外，所有 YAML 清单都完全相同。能够关上每个目录中的 deployment.yaml 文件进行更改，保留后运行 kubectl apply -f .，就功败垂成了。

然而，在大多数状况下，环境之间的差别并不那么简略。请看上面的例子：

• 开发环境通过某些容器命令参数进行调试，而这些参数在 QA 或生产环境中不可用。
• QA 部署了一些边车，用于运行测试，开发和生产环境不具备这种能力。
• 出于不言而喻的起因，生产环境的 RBAC 比其余两个环境的限制性更强。

还有其余更多的可能性：

• 利用变得越来越大，须要其余依赖服务。例如，MySQL 后端和 Redis 缓存服务器。每个服务都有本人的清单、配置设置和环境差别。
• 须要施行 CI/CD 流水线，将应用程序 (连同其依赖项) 测试、构建和部署到多个环境中。

如你所见，独自应用 kubectl 会变成一场噩梦，这就是咱们开始摸索更高级工具 (特指 Helm 和 Kustomize) 的起因。让咱们先来探讨一下它们各自是如何应答上述挑战的。

Helm

作为 Kubernetes 的包管理器，Helm 提供了一种以 ” 图表 (charts)” 模式打包、散发和管理应用程序的办法。Helm chart 由模板(template) 和值 (value) 文件汇合组成，其中模板定义 Kubernetes 资源(如 Deployment、Service、ConfigMap)，值文件容许自定义模板值。

这样就能够领有一组模板，为在不同部署 (或环境) 中发生变化的参数提供占位符。例如，上面是一个 Helm 部署模板，它从值文件中获取正本数量、镜像名称和标签、容器端口和容器启动参数：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{.Release.Name}}-deployment
spec:
  replicas: {{.Values.replicaCount}}
  selector:
    matchLabels:
      app: {{.Release.Name}}
  template:
    metadata:
      labels:
        app: {{.Release.Name}}
    spec:
      containers:
        - name: {{.Chart.Name}}
          image: {{.Values.image.repository}}:{{.Values.image.tag}}
          ports:
            - containerPort: {{.Values.containerPort}}
          args:
            - {{.Values.startupArguments}}

{{ 和 }} 之间的内容都是动静的。也就是说，在 chart 部署时，它们会被理论值取代。相应的值文件如下所示：

replicaCount: 3

image:
  repository: myapp/image
  tag: v1.0.0

containerPort: 8080

startupArguments: arg1 arg2 arg3

留神： .Release.Name 和 .Chart.Name 变量取自 Chart.yaml，可视为另一个参数起源，用于为集群中的 Kubernetes 组件赋予惟一的名称，这样咱们就能在同一个集群中部署同一 chart 的多个版本。

当 Helm 利用于集群时，Kubernetes API 服务器会收到这些信息：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp/image:v1.0.0
          ports:
            - containerPort: 8080
          args:
            - arg1
            - arg2
            - arg3

这样就能够为每种环境 / 用例设置不同的值文件。

对于整个环境的更改，只需批改一次源模板。而对于特定环境的更改，能够利用每个环境对应的值文件。

Kustomize

Kustomize 的指标是一样的，但不应用模板。相同，它在一个目录中保留 残缺 版本的 YAML 文件。依照常规，这个文件被称为 base，但也能够依据本人的爱好给它命名。而后能够为每个环境 / 场景 / 用例创立一个目录(或目录树)，每个目录都须要一个名为 kustomization.yaml 的 YAML 文件，该文件的目标是告知 Kustomize 应该思考哪些 manifest 文件，以及须要对这些文件进行哪些批改。上面通过例子来阐明这，看看如何应用 Kustomize 得出与 Helm 雷同的后果。

首先创立一个目录构造：

myapp/
├── kustomization.yaml
├── base
│   └── deployment.yaml
└── overlay
    └── deployment.yaml

myapp/kustomization.yaml 的内容如下：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - base/deployment.yaml

patchesStrategicMerge:
  - overlay/deployment.yaml

base/deployment.yaml 看起来像这样：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp
          image: myapp/image:v1.0.0
          ports:
            - containerPort: 8080

请留神，这是一个齐全无效的 YAML，如果须要，也能够按原样利用。

要更改该部署以适应环境需要，能够应用 overlay/deployment.yaml 文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  template:
    spec:
      containers:
        - name: myapp
          args:
            - arg1
            - arg2
            - arg3

这样，发送到 Kubernetes API 服务器的文件就变成了

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp
          image: myapp/image:v1.0.0
          ports:
            - containerPort: 8080
          args:
            - arg1
            - arg2
            - arg3

把同样的机制利用到三个环境中，目录构造能够是这样的：

myapp/
├── kustomization.yaml
├── base
│   └── deployment.yaml
├── overlays
│   ├── dev
│   │   └── kustomization.yaml
│   ├── qa
│   │   └── kustomization.yaml
│   └── prod
│       └── kustomization.yaml
└── patches
    └── deployment-patch.yaml

如果须要对整个环境进行更改，只需在 base/deployment 文件中进行一次更改，就会流传到所有中央。针对特定环境的更改在相应环境的自定义文件中实现。

当初咱们晓得了每种工具是如何应答挑战的，上面来看看其优缺点。

第 1 回合：装置和设置

须要在服务器上安装 Helm，请参阅 Five ways to install Helm。

尽管能够从 https://kubectl.docs.kubernetes.io/installation/kustomize/ 下载独自的 Kustomize 软件包，但从 1.14 版开始，就曾经与 kubectl 捆绑在一起了。因而，除非你的零碎中没有(或不须要)kubectl，否则只需运行 kubectl -k 即可调用 Kustomize。

优胜者：Kustomize

第 2 回合：软件包治理

因为 Helm 顾名思义是软件包管理器，它提供的软件仓库能够搜寻和下载特定版本的 chart，也能够在同一集群中同时装置多个版本的 chart。Kustomize 不会将文件打包成可部署的单元，不过咱们能够通过 Kustomize 手动实现同样的成果(Git 公布是其中一种抉择)。不过，Helm 提供了开箱即用的性能。

优胜者：Helm

第 3 回合：模板化能力

Helm 齐全依赖 Go 模板，此外还从 Sprig 库中借用了一些函数，使模板性能更加多样化。Kustomize 齐全不应用模板，而是在将 YAML 清单利用到集群之前，应用 overlay 和 patch 对其进行即时批改。

Go 是一种成熟的编程语言，提供了弱小的文本操作技术。例如

• 循环和条件式，如 (range) 和条件式(if、else、with)，这在生成反复资源或依据用户提供的值进行决策时十分有用。
• 模板性能通过 Sprig 库实现，该库提供了各种性能，如 default、pick、omit、trim、upper、lower、quote 等。

而 Kustomize 却无奈做到这一点。不过，它也有一些小技巧。例如

• ConfigMaps 和 Secrets 的生成器。这些都是申明式指定的，Kustomize 会在构建最终 YAML 时生成资源。
• Variants(变体)：Kustomize 应用 overlay 层来治理同一应用程序的不同变体，这有助于治理不同的环境(开发、预发、生产)。
• 用于更新资源字段的转换器(transformers)。常见的转换器包含为资源名称增加前缀 / 后缀、更新标签和正文以及更新命名空间。转换器能够有抉择的利用于不同的资源，从而提供高度的管制。

优胜者：不定(取决于所谋求的定制化水平)

第 4 回合：调试

很显著，在将 YAML 文件利用到群集之前，须要测试这些文件是否存在谬误。YAML 应用空格和缩进来定义对象、列表和其余组件，一个不正确的缩进可能会毁掉整个部署。Helm 和 Kustomize 都容许咱们在将 YAML 清单利用到群集之前就 ” 查看 ” 这些清单。

Kustomize 有 build 命令，在将所有 patch、overlay、转换器 (transformers) 等利用到一个蕴含整个无效负载的大文件后，会生成最终的清单。不过，也能够运行 kubectl apply -k --dry-run 来依赖 API 服务器验证 YAML 清单。

Helm 有几种办法能够做同样的事件：

能够应用 helm template 在 YAML 清单发送到 API 服务器之前对其进行渲染，还能够应用 helm lint 依据最佳实际查看 chart。

应用 helm install --dry-run (或 helm upgrade )还能够针对 API 服务器测试清单。也就是说，即便 YAML 在语法上是正确的，API 服务器也可能因为其余起因而拒绝接受(例如，短少 CRD 或接入控制器)。Helm 容许咱们在将无效负载利用到 Kubernetes 之前捕捉这些谬误，从而防止卸载和重新安装有问题的 chart。

优胜者：不定

第 5 回合：版本控制和回滚

如前所述，Helm 可能同时在同一集群中部署同一 chart 的多个版本。Helm 将部署版本称为revision(修订版)，并保留了部署到群集的 revision 版本历史记录，容许咱们在须要时回滚到之前的 revision 版本。尽管 Kustomize 也能够做同样的事件，但过程简单且容易出错。

优胜者：Helm

第 6 回合：Secrets 治理

许多状况下，咱们须要存储一些敏感信息，作为应用程序部署的一部分。比方 API 密钥、用户凭证、令牌等。在所有状况下，Kubernetes 都提供了 Secret 对象，能够在其中保留机密信息。让咱们看看每个工具是如何解决 Secret 创立的：

Helm

将隐衷数据存储在 values.yaml 文件中，并应用 b64enc 函数在 Secret YAML 清单中将其即时转换为 base64。例如

# values.yaml
database:
  username: admin
  password: secret

以及

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: {{.Values.database.username | b64enc}}
  password: {{.Values.database.password | b64enc}}

由此产生的 YAML 能够是这样的

---
# Source: my-chart/templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=
  password: c2VjcmV0

这里的问题不言而喻: 须要将 Values 文件 (其中蕴含纯文本证书) 提交到版本控制中。一个可行的解决方案是创立独自的 Values 文件来存储敏感信息，并通过将其增加到 .gitignore 文件来防止将其蕴含在 git 仓库中。不过这样须要治理多个 Values 文件，又减少了复杂性。

Kustomize

能够应用 Kustomize secretGenerator 主动从纯文件创建 Secret YAML。例如，能够创立如下凭证文件：

# Create the secret file
echo -n 'admin' > ./username.txt
echo -n 'secret' > ./password.txt

Kustomization 文件看起来会像这样：

# kustomization.yaml
secretGenerator:
- name: db-secret
  files:
  - username.txt
  - password.txt

由此产生的清单将是

apiVersion: v1
kind: Secret
metadata:
  name: db-secret-8h5h97g6k8
type: Opaque
data:
  username.txt: YWRtaW4=
  password.txt: c2VjcmV0

尽管 username.txt 和 password.txt 也会被增加到 .gitignore，但除非想批改凭据，否则无需在每次部署时都从新创立它们(在运行 git clone 或 git pull 后)。

显然，用 Base64 存储敏感信息和应用纯文本是一样的，因为 Base64 是一种编码格局，而不是加密办法。也就是说，任何人都能够应用命令行工具将 Base64 字符串转换为原始格局。因而，最佳实际要求咱们对 secret 数据进行加密。Helm 和 Kustomize 都能够应用第三方插件实现这一性能。

例如，如果应用 Kustomize，能够应用 kustomize-secret-generator 插件，它能让你从 Google Cloud Secret Manager、AWS Secrets Manager 或 HashiCorp 获取 secret。这样做的目标是将 secret 以加密模式存储在其中某个反对的平台中。须要时，用户能够依附插件获取 secret、解密并将其利用于群集。上面演示了 Kustomize 如何利用 HashiCorp 的 Vault 实现这一性能：

# kustomization.yaml
secretGenerator:
- name: db-secret
  kvSources:
  - pluginType: vault
    name: my-vault
    namespace: default
    path: secret/data/my-service
    key: db-password

尽管 Helm 有 Helm-Secrets 插件，但不提供从其余平台获取 secret 的本地反对。相同，它应用 Mozilla SOPS 进行加密。密钥自身能够存储在各种密钥管理系统中，如 AWS KMS、GCP KMS、Azure Key Vault 和 PGP。例如

helm secrets enc secrets.yaml

上述命令对 Secret 模板进行了动态加密，而后能够间接提交到 Git。当咱们在另一台机器上从新获取时，须要先解密，而后再将其利用到 Kubernetes：

helm secrets dec secrets.yaml

优胜者：Kustomize

第 7 回合：解决超大型应用程序

如果应用程序有数百个清单，蕴含数千行内容，那么应用 Helm 模板解决这些清单很快就会变得力不从心，这里 Kustomize 可能是更好的抉择。

例如驰名的基于 Kubernetes 的机器学习平台 Kubeflow，正在应用 Kustomize 作为部署工具。起因是该平台过于宏大，而且有许多依赖项须要按特定程序部署。为了解释的更分明，这是须要部署的资源的一个子集(咱们甚至还没有思考 patch 或 overlay)：

优胜者：Kustomize

第 8 回合：与 CI/CD 工具集成

Helm 已被宽泛采纳，被许多 CI/CD 工具所反对。对 Kustomize 的反对也在减少，但并不宽泛。

优胜者：Helm

第 9 回合(最初一轮)：次级组成部分和依赖关系

Helm 内置反对依赖关系解决。如果 chart 须要一些先决条件(数据库、缓存服务器、OAuth 服务等)，能够轻松的在 Chart.yaml 文件中将它们增加为dependencies(依赖项)。Helm 将确保在运行主 chart 前下载并提供这些先决条件，并且能够抉择所需版本。而 Kustomize 则齐全由用户手动解决。

优胜者：Helm

获胜者是

Helm!

不过，这里没有输赢之分。每种工具都有本人的优缺点，齐全取决于我的项目的指标、规模、须要部署的环境数量以及复杂程度。这场 ” 对决 ” 的目标只是展现这两种工具之间的区别，而不是宣扬其中一种优于另一种。

尽管如此，许多我的项目事实上会在同一个代码库中同时应用这两种工具。不过，本文篇幅过长，无奈探讨 Kustomize 的这一性能。不过，能够通过以下链接查看文档：https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md

论断

Helm 和 Kustomize 的指标是统一的：以 DevOps 的形式更轻松的部署蕴含许多相互依赖的 YAML 清单的大型应用程序。不过，每种工具都有其优于其余工具的用例。在本文中，咱们试图让这两种工具面对面比拟，看看它们的优缺点。在下一个我的项目中抉择应用 Helm 还是 Kustomize 很大水平上取决于多个因素，但咱们心愿本文能帮忙你做出正确的决定。

心愿这篇对于 Helm 和 Kustomize 的文章对你有所帮忙。如果深刻理解并精通 Helm，强烈推荐 Udemy 上的课程：Helm – Kubernetes 包管理器实际。该课程适宜各种程度的学习者，蕴含大量实际示例和精辟技巧。

你好，我是俞凡，在 Motorola 做过研发，当初在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。为了不便大家当前能第一工夫看到文章，请敌人们关注公众号 ”DeepNoMind”，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的反对和能源，激励我继续写下去，和大家独特成长提高！

本文由 mdnice 多平台公布