本章我们将学习 Helm，Kubernetes 的包管理器。

每个成功的软件平台都有一个优秀的打包系统，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 则是 Kubernetes 上的包管理器。

本章我们将讨论为什么需要 Helm，它的架构和组件，以及如何使用 Helm。

## Why Helm

Helm 到底解决了什么问题？为什么 Kubernetes 需要 Helm？

答案是：Kubernetes 能够很好地组织和编排容器，但它缺少一个更高层次的应用打包工具，而 Helm 就是来干这件事的。

先来看个例子。   
比如对于一个 MySQL 服务， Kubernetes 需要部署下面这些对象：

1. Service，让外界能够访问到 MySQL。
![782.png](https://steemitimages.com/DQmYJYJSj4izH61YKhTWrrirHMLG6xcLzcckQBAK2WMfdfQ/782.png)

2. Secret，定义 MySQL 的密码。
![783.png](https://steemitimages.com/DQmZi6KLiB3KenAjp5VCBHJoFL6edqrrCoMqqiNgM6x3WnA/783.png)

3. PersistentVolumeClaim，为 MySQL 申请持久化存储空间。
![784.png](https://steemitimages.com/DQmeBuXC5AD5cqnQzeKBeoCTQWbYrY1NNu92vdN8o92KmSc/784.png)

4. Deployment，部署 MySQL Pod，并使用上面的这些支持对象。
![785.png](https://steemitimages.com/DQmbjfFLzPrhY3fpd3Lrffa4Wmarv7sHX3zQQFnYj7LCQSB/785.png)

我们可以将上面这些配置保存到对象各自的文件中，或者集中写进一个配置文件，然后通过 `kubectl apply -f` 部署。

到目前为止，Kubernetes 对服务的部署支持得都挺好，如果应用只由一个或几个这样的服务组成，上面的部署方式完全足够了。

但是，如果我们开发的是微服务架构的应用，组成应用的服务可能多达十个甚至几十上百个，这种组织和管理应用的方式就不好使了：

1. 很难管理、编辑和维护如此多的服务。每个服务都有若干配置，缺乏一个更高层次的工具将这些配置组织起来。

2. 不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务，然后按照逻辑顺序依次执行 `kubectl apply`。即缺少一种工具来定义应用与服务，以及服务与服务之间的依赖关系。

3. 不能高效地共享和重用服务。比如两个应用都要用到 MySQL 服务，但配置的参数不一样，这两个应用只能分别拷贝一套标准的 MySQL 配置文件，修改后通过 `kubectl apply` 部署。也就是说不支持参数化配置和多环境部署。

4. 不支持应用级别的版本管理。虽然可以通过 `kubectl rollout undo` 进行回滚，但这只能针对单个 Deployment，不支持整个应用的回滚。

5. 不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问 MySQL。虽然 Kubernetes 有健康检查，但那是针对单个容器，我们需要应用（服务）级别的健康检查。

Helm 能够解决上面这些问题，Helm 帮助 Kubernetes 成为微服务架构应用理想的部署平台。

下一节我们讨论 Helm 的架构。