Why Helm? - 天天5分鐘玩轉 Docker 容器技術（160）

本章咱們將學習 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