Helm - K8s的包管理器

11.1 Why Helm

　　K8s能夠很好的組織和編排容器，但它缺少一個更高層次的應用打包工具，Helm就是幹這個的。

　　比如對於一個MySQL服務，K8s需要部署如下物件：

　　（1）Service，讓外界能訪問MySQL

　　（2）Secret，定義MySQL的密碼

　　（3）PersisentVolumeClaim,為MySQL申請持久化儲存空間。

　　（4）Deployment，部署MySQL Pod，並使用上面的這些支援物件。

可以將上面這些配置儲存到檔案中，或幾種寫進一個檔案，然後通過kubectl apply -f 部署。

　　如果服務少，這樣問題也不大，但是如果是微服務架構，服務多達數十個甚至上百個，這種組織和管理應用的方式就不好使了：

　　（1）很難管理、編輯和維護如此多的服務。每個服務有若干個配置，缺乏更高層次的工具將這些配置組織起來。

　　（2）不容易將這些服務作為一個整體統一發布。部署人員需要首先理解應用都包含哪些服務，然後按照邏輯順序依次執行kubectl apply, 缺少一種工具定義應用與服務，已經服務之間的依賴。

　　（3）不能高效的共享和重用服務。比如兩個應用都用到MySQL服務，但是配置引數不一樣，這兩個應用只能分別複製一套標準MySQL配置檔案，修改後通過kubectl apply部署。也就是不支援引數化配置和多環境部署。

　　（4）不支援應用級別的版本管理。雖然可以通過kubectl rollout undo進行回滾，但這隻針對單個deployment，不支援整個應用的的回滾。

　　（5）不支援對部署的應用狀態進行驗證。比如是否能通過預定義賬號訪問MySQL。雖然K8s有健康檢查，但那時針對單個容器，我們需要應用（服務）級別的健康檢查。

　　Helm能夠解決上面這些問題。

11.2 Helm架構

　　Helm有兩個重要概念：chart和release

• chart: 是建立一個應用的資訊集合，包括各種k8s物件的配置模板、引數定義、依賴關係、文件說明等。chart是應用部署的自包含邏輯單元。可以將char想象成apt、yum中的軟體安裝包。
• release: 是chart的執行例項，代表了一個正在執行的應用。當chart被安裝到k8s叢集，就生成一個release
  。chart能夠多次安裝到同一個叢集，每次安裝都是一個release。