kustom Kustomize 和 Helm 之间，我为什么选择了 Kustomize？

在本文中，我们将记录我们为什么选择Kustomize作为Kubernetes应用程序的部署工具，而不是Helm。

在使用各种项目管理之前

先说之前的痛点。虽然我们不是大公司，但是代码打的越来越多，服务越来越全。要管理的项目有十几个。然后我们还有多个部署环境:内网环境、生产前环境和生产环境。那么几乎每个环境都必须有一套库本内特斯的YAML文件，但每一个都只是略有不同。

然后我们自己的配置项是将构建的Docker映像放入注册表。

然后，每次更新映像时，都会手动部署它。在大多数情况下，图像的标签会被修改。但是，由于每个环境的YAML略有不同，如果我需要在不同的环境之间切换，我需要来回修改这些YAML文件。如果不小心写错了，只能怪手。但是，这种部署模式虽然只是为了改变库本内特斯下的YAML，但感觉还是很原始的。

希望有什么改进

仔细想想，你的需求只是几个:

有一个统一的模板可以管理一个项目的 Kubernetes 部署结构。有某种方式可以管理不同环境之间微小的差异。每次更新基本就是修改镜像的标签然后部署，那么有没有什么简单的办法实现之，而不是让我每次都去修改 YAML 文件。针对 Helm 的调研

既然说Helm是Kubernetes的包管理工具，那我就先试试Helm。

Helm是Deis为Kubernetes应用开发的包管理工具，主要用于管理图表。类似于Ubuntu中的APT或者CentOS中的YUM。

赫尔姆图是一系列YAML文件，用于封装库本内特本地应用程序。您可以在部署应用程序时自定义应用程序的一些元数据，以便于应用程序的分发。

对于应用发布者来说，可以通过Helm对应用进行打包，管理应用依赖关系，管理应用版本，将应用发布到软件仓库。

对于用户来说，使用Helm后不需要编写复杂的应用部署文件，可以简单的在Kubernetes上查找、安装、升级、回滚、卸载应用。

更多关于Helm的介绍，请参考文章《Helm入门指南》。

简单看一下，Helm给我的感觉就是大而无用:它真的是一个包管理工具，复杂的Go Template系统和需要单独存储的Charts让我觉得更适合Ubuntu的APT或者macOS的Brew。更像是提供一个复杂的软件发布包，可以根据各种配置信息生成，适合不同的环境，而不是用于我们的轻量级部署配置管理。于是我放弃了使用Helm。

Kustomize调查

这时我想起了Github Trending之前看到的另一个工具Kustomize，用户用来配置Kubernetes。简而言之，这是一个简化库本内斯·YAML写作的工具。它提供了正好满足我需求的两个重要功能。

Kustomize是新玩家，只有一个CLI工具。在Kubernetes 1.14之后，甚至这个唯一的工具也成为了kubectl的一部分。

Kustomize放弃了模板的要求，用Base+Overlay派生出了原来的YAML。叠加，顾名思义，就是叠加。Kustomize的叠加可以基于资源、生成器、变压器等的定义形成新的应用定义。无论是基础还是叠加，都可以通过kustomize构建生成有效的YAML。

Kustomize 的特色功能简单清晰，kubectl 直接支持。不考虑派生，仅作为应用的 YAML 组织方式也很有帮助。自身支持插件。继承和 Patch

Kustomize可以设置以下级别:

├── base │ ├── deployment.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays └── stg ├── ingress.yaml └── kustomization.yaml

其中base存储每个环境base/kustomization.yaml的所有公共配置:

resources: - deployment.yaml - service.yaml

然后可以在overlays中定义子环境overlays/stg/kustomization . YAML:

bases: - ../../base

资源:-intrusion . YAML