Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160）
每個成功的軟件平臺都有一個優秀的打包系統，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 則是 Kubernetes 上的包管理器。
本章我們將討論為什麽需要 Helm，它的架構和組件，以及如何使用 Helm。
Why Helm
Helm 到底解決了什麽問題？為什麽 Kubernetes 需要 Helm？
答案是：Kubernetes 能夠很好地組織和編排容器，但它缺少一個更高層次的應用打包工具，而 Helm 就是來幹這件事的。
先來看個例子。
比如對於一個 MySQL 服務， Kubernetes 需要部署下面這些對象：
Service，讓外界能夠訪問到 MySQL。
Secret，定義 MySQL 的密碼。
PersistentVolumeClaim，為 MySQL 申請持久化存儲空間。
Deployment，部署 MySQL Pod，並使用上面的這些支持對象。
我們可以將上面這些配置保存到對象各自的文件中，或者集中寫進一個配置文件，然後通過 kubectl apply -f 部署。
到目前為止，Kubernetes 對服務的部署支持得都挺好，如果應用只由一個或幾個這樣的服務組成，上面的部署方式完全足夠了。
但是，如果我們開發的是微服務架構的應用，組成應用的服務可能多達十個甚至幾十上百個，這種組織和管理應用的方式就不好使了：
很難管理、編輯和維護如此多的服務。每個服務都有若幹配置，缺乏一個更高層次的工具將這些配置組織起來。
不容易將這些服務作為一個整體統一發布。部署人員需要首先理解應用都包含哪些服務，然後按照邏輯順序依次執行
kubectl apply。即缺少一種工具來定義應用與服務，以及服務與服務之間的依賴關系。不能高效地共享和重用服務。比如兩個應用都要用到 MySQL 服務，但配置的參數不一樣，這兩個應用只能分別拷貝一套標準的 MySQL 配置文件，修改後通過
kubectl apply部署。也就是說不支持參數化配置和多環境部署。不支持應用級別的版本管理。雖然可以通過
kubectl rollout undo進行回滾，但這只能針對單個 Deployment，不支持整個應用的回滾。不支持對部署的應用狀態進行驗證。比如是否能通過預定義的賬號訪問 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
Why Helm? - 每天5分鐘玩轉 Docker 容器技術（160）