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

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

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

Why Helm

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

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

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

1. Service，让外界能够访问到 MySQL。
   

2. Secret，定义 MySQL 的密码。
   

3. PersistentVolumeClaim，为 MySQL 申请持久化存储空间。
   

4. Deployment，部署 MySQL Pod，并使用上面的这些支持对象。
   

我们可以将上面这些配置保存到对象各自的文件中，或者集中写进一个配置文件，然后通过 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 的架构。

书籍：

1.《每天5分钟玩转Kubernetes》
https://item.jd.com/26225745440.html

2.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

3.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html