本章我們将學習 Helm，Kubernetes 的包管理器。
每個成功的軟體平台都有一個優秀的打包系統，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 則是 Kubernetes 上的包管理器。
本章我們将讨論為什麼需要 Helm，它的架構群組件，以及如何使用 Helm。
Why Helm
Helm 到底解決了什麼問題？為什麼 Kubernetes 需要 Helm？
答案是：Kubernetes 能夠很好地組織和編排容器，但它缺少一個更高層次的應用打包工具，而 Helm 就是來幹這件事的。
先來看個例子。
比如對于一個 MySQL 服務， Kubernetes 需要部署下面這些對象：
- Service，讓外界能夠通路到 MySQL。
Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160） - Secret，定義 MySQL 的密碼。
Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160） - PersistentVolumeClaim，為 MySQL 申請持久化存儲空間。
Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160） - Deployment，部署 MySQL Pod，并使用上面的這些支援對象。
Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160）
我們可以将上面這些配置儲存到對象各自的檔案中，或者集中寫進一個配置檔案，然後通過
kubectl apply -f
部署。
到目前為止，Kubernetes 對服務的部署支援得都挺好，如果應用隻由一個或幾個這樣的服務組成，上面的部署方式完全足夠了。
但是，如果我們開發的是微服務架構的應用，組成應用的服務可能多達十個甚至幾十上百個，這種組織和管理應用的方式就不好使了：
- 很難管理、編輯和維護如此多的服務。每個服務都有若幹配置，缺乏一個更高層次的工具将這些配置組織起來。
- 不容易将這些服務作為一個整體統一釋出。部署人員需要首先了解應用都包含哪些服務，然後按照邏輯順序依次執行
kubectl apply
- 不能高效地共享和重用服務。比如兩個應用都要用到 MySQL 服務，但配置的參數不一樣，這兩個應用隻能分别拷貝一套标準的 MySQL 配置檔案，修改後通過
kubectl apply
- 不支援應用級别的版本管理。雖然可以通過
kubectl rollout undo
- 不支援對部署的應用狀态進行驗證。比如是否能通過預定義的賬号通路 MySQL。雖然 Kubernetes 有健康檢查，但那是針對單個容器，我們需要應用（服務）級别的健康檢查。
Helm 能夠解決上面這些問題，Helm 幫助 Kubernetes 成為微服務架構應用理想的部署平台。
下一節我們讨論 Helm 的架構。
書籍：
1.《每天5分鐘玩轉Kubernetes》
https://item.jd.com/26225745440.html2.《每天5分鐘玩轉Docker容器技術》
https://item.jd.com/16936307278.html3.《每天5分鐘玩轉OpenStack》
https://item.jd.com/12086376.html