阅读本篇需要了解 Kustomization 和 Helm 相关知识。

上篇介绍了网关基于 YAML 的部署方式，本篇我们探讨这种部署方式可能遇到的问题，以及有哪些方法解题。

问题

在企业级研发流程中，发布一个应用的流程会更复杂。为了保证产品质量和开发、测试、运维等不同职能协作，一般研发流程在环境部分，包括：Dev、Test、 Staging 和 Prod 环境。

以网关部署的配置文件为例，一个 YAML 部署文件包括Deployment、Service 等内容，假设一个应用有4个环境组成，那么 YAML 文件的重复配置是非常多的。因为4个环境，除了 Pod 副本数量、namespace、limit 不同，其他都是相同的。如此，造成 YAML 后期维护难度增加、容易出错等风险。

解题思路

围绕 Kubernetes 生态，敏锐的开发者已经捕捉到这个机会，可能的方案譬如：Helm、Kustomization 。

Helm

Helm 提供了一套 Kubernetes 包管理的解决方案。Helm 3 是基于 Helm 2 的基础之上，Helm 3 的内部实现相较于 Helm 2 发生了很大变化。最明显的变化是删除 Tiller 。

从架构图上可以看出，Helm 有几个新的概念：

• Repository
  Repository 是存储 Helm Chart 的仓库，可以在 Client 检索，也可以获取 Chart 并进行后续操作。
• Client
  客户端工具，可以搜索 Chart 项目、安装 Chart、构建 Chart。也可以把 Chart 渲染为 Kubernetes 需要的 YAML 文件。
• Tiller
  负责接收来自客户端的指令，完成对集群内应用生命周期的控制。
• Chat
  Chat 是 YAML 文件的集合，生成Kubernetes应用程序所需的大量 Kubernetes 资源。一个典型的 Chat 目录文件结构如下：

Kustomization

Kustomization 是一个轻量级的解决方案，没有 Helm 诸多新的概念，基本遵从 Kubernetes 原生的模式。在 Kubernetes 1.14 之后，甚至直接集成到 kubectl ，成为其中的一部分。他有两部分组成：

• Base
  Base 是包含 YAML 文件的目录结构，是对基础资源配置的申明。若基础部分有改动，只需改这个目录即可，提升可维护性。

• Overlay
  Overlay 是一个目录结构，可以包含各个环境的个性化配置，其他基础配置继承 Base 即可。一个完整的Kustomization 目录配置如下：

方案

我们选用轻量级的 Kustomization 方案，以网关为例，目录如下，进入到 pro 目录，执行 kustomize build 目录获得完整 YAML 文件。使用 kustomize build | kubectl apply -f - 部署应用。在 v1.14 中，使用 kubectl 通过 -k 标志部署即可。源码：https://github.com/Tony-Hangzhou/mvp-samples/tree/master/kustomize/gateway 。

Kustomization 可以在运行时编辑资源，使用 edit 命令即可，请参考官网。

总结

本篇我们探讨了原生 YAML 部署遇到的问题，以及使用 Kustomization 提升可维护性。