前言
容器的出现，标志着云原生的到来，Docker 基于 Linux 隔离、虚拟化等能力封装了应用；Kubernetes 的出现，建立了云原生时代的技术基础设施，它基于对容器的编排封装了集群；Kubernetes 可以说是云原生的操作系统，它解决了容器之间隔离与协助的问题、解决了分布式系统可靠性的问题；而云原生发展的脚步并没有停下来，这就是 Helm，它封装了应用（Kubernetes 应用的定义、安装和升级）。
Kubernetes应用部署的挑战
通过 Kubernetes 部署一个应用，我们需要写很多的 yml 文件来描述服务，包括 Pod，Service，Volume，Namespace，ReplicaSet，Deployment，Job 等等。然后需要通过 Kubernetes 命令行工具 kubeclt 去逐个 apply。
在这个过程中，我们遇到了以下问题：
- 通常这些 yml 文件被维护在 git 仓库中，一般 kubectl apply 是在自己的主机上进行，没有纳入 CR 流程，git 仓库的更新也面临挑战。
- 这些 yml 配置无法复用
Helm 是什么？
Helm 是一个 Kubernetes package manager，Chart 是它定义的格式，类比 Linux 系统下的包管理工具，就像是 Debian 系统的 apt-get 命令与 dpkg 格式、REHL 系统的 yum 命令与 rpm 格式。
Chart的格式如下：
filebeat/
templates/
NOTES.txt
clusterrole.yaml
clusterrolebinding.yaml
configmap.yaml
daemonset.yaml
deployment.yaml
serviceaccount.yaml
Chart.yaml
requirements.yaml
values.yml
- Chart.yaml给出了应用自身的详细信息（名称、版本、许可证、自述、说明、图标，等等）
- requirements.yaml给出了应用的依赖关系，依赖项指向的是另一个应用的坐标（名称、版本、Repository地址）
- values.yaml给出了所有可配置项目的预定义值。
部署应用时，Helm会先将管理员设置的值覆盖到values.yaml的默认值上，然后以字符串替换的形式传递给templates目录的资源模板，最后生成要部署到Kubernetes的资源文件。由于Chart封装了足够丰富的信息，所以Helm除了支持命令行操作外，也能很容易地根据这些信息自动生成图形化的应用安装、参数设置界面。
Chart 定义统一的应用配置格式，并通过社区的力量号召大量开发者贡献常用应用的 Chart。并建立了类似 Docker hub
的 Chart 存储仓库，建立了应用发布者与使用者之间责任分明的关系。
应用发布者通过 Helm 打包应用到 Helm Hub 仓库。
使用者通过 Helm 下载应用并安装在 Kubernetes 上。
总结
Helm 的思想与 Docker 一致，通过封装与打包，隐藏与使用者无关的细节，解放使用者双手。但 Helm 也并非银弹，它无法很好的管理有状态服务的依赖关系。云原生还在继续~