每個成功的軟件平台都有一個優秀的打包系統，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 則是 Kubernetes 上的包管理器。
本章我們將討論為什么需要 Helm，它的架構和組件，以及如何使用 Helm。
1.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 對服務的部署支持得都挺好，如果應用只由一個或幾個這樣的服務組成，上面的部署方式完全足夠了。
但是，如果我們開發的是微服務架構的應用，組成應用的服務可能多達十個甚至幾十上百個，這種組織和管理應用的方式就不好使了：
-
很難管理、編輯和維護如此多的服務。每個服務都有若干配置，缺乏一個更高層次的工具將這些配置組織起來。
-
不容易將這些服務作為一個整體統一發布。部署人員需要首先理解應用都包含哪些服務，然后按照邏輯順序依次執行
kubectl apply。即缺少一種工具來定義應用與服務，以及服務與服務之間的依賴關系。 -
不能高效地共享和重用服務。比如兩個應用都要用到 MySQL 服務，但配置的參數不一樣，這兩個應用只能分別拷貝一套標准的 MySQL 配置文件，修改后通過
kubectl apply部署。也就是說不支持參數化配置和多環境部署。 -
不支持應用級別的版本管理。雖然可以通過
kubectl rollout undo進行回滾，但這只能針對單個 Deployment，不支持整個應用的回滾。 -
不支持對部署的應用狀態進行驗證。比如是否能通過預定義的賬號訪問 MySQL。雖然 Kubernetes 有健康檢查，但那是針對單個容器，我們需要應用（服務）級別的健康檢查。
Helm 能夠解決上面這些問題，Helm 幫助 Kubernetes 成為微服務架構應用理想的部署平台。
2.Helm架構
Helm 有兩個重要的概念：chart 和 release。
chart 是創建一個應用的信息集合，包括各種 Kubernetes 對象的配置模板、參數定義、依賴關系、文檔說明等。chart 是應用部署的自包含邏輯單元。可以將 chart 想象成 apt、yum 中的軟件安裝包。
release 是 chart 的運行實例，代表了一個正在運行的應用。當 chart 被安裝到 Kubernetes 集群，就生成一個 release。chart 能夠多次安裝到同一個集群，每次安裝都是一個 release。
Helm 是包管理工具，這里的包就是指的 chart。Helm 能夠：
-
從零創建新 chart。
-
與存儲 chart 的倉庫交互，拉取、保存和更新 chart。
-
在 Kubernetes 集群中安裝和卸載 release。
-
更新、回滾和測試 release。
Helm 包含兩個組件：Helm 客戶端 和 Tiller 服務器。
Helm 客戶端是終端用戶使用的命令行工具，用戶可以：
-
在本地開發 chart。
-
管理 chart 倉庫。
-
與 Tiller 服務器交互。
-
在遠程 Kubernetes 集群上安裝 chart。
-
查看 release 信息。
-
升級或卸載已有的 release。
Tiller 服務器運行在 Kubernetes 集群中，它會處理 Helm 客戶端的請求，與 Kubernetes API Server 交互。Tiller 服務器負責：
-
監聽來自 Helm 客戶端的請求。
-
通過 chart 構建 release。
-
在 Kubernetes 中安裝 chart，並跟蹤 release 的狀態。
-
通過 API Server 升級或卸載已有的 release。
簡單的講：Helm 客戶端負責管理 chart；Tiller 服務器負責管理 release。
3.Helm的部署
3.1Helm 客戶端
通常，我們將 Helm 客戶端安裝在能夠執行 kubectl 命令的節點上，只需要下面一條命令：(需要翻牆)
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash
執行 helm version 驗證。
[root@k8s-master app]# mv linux-amd64/helm /usr/local/bin/helm
目前只能查看到客戶端的版本，服務器還沒有安裝。
3.2Tiller 服務器
Tiller 服務器安裝非常簡單，只需要執行 helm init：
Tiller 本身也是作為容器化應用運行在 Kubernetes Cluster 中的：
查看日志
kubectl describe pod --namespace=kube-system
沒法翻牆鏡像pull失敗，於是在網上找了個鏡像壓縮包
根據日志tiller需要版本v2.11.0而現在我們這個是v2.9.0需要改一下tag
docker tag gcr.io/kubernetes-helm/tiller:v2.9.0 gcr.io/kubernetes-helm/tiller:v2.11.0
將鏡像打包 分發給工作節點node1 和node2
docker save gcr.io/kubernetes-helm/tiller：v2.11.0 tiller-v2.11.0.tar
可以看到 Tiller 的 Service、Deployment 和 Pod。
現在， helm version 已經能夠查看到服務器的版本信息了。
Helm 部署完畢,能科學上網的最好用科學上網 下載最新的，不然在使用的時候版本不一致會出現問題。
4.Helm的使用
Helm 安裝成功后，可執行 helm search 查看當前可安裝的 chart。
這個列表很長，這里只截取了一部分。大家不禁會問，這些 chart 都是從哪里來的？
前面說過，Helm 可以像 apt 和 yum 管理軟件包一樣管理 chart。apt 和 yum 的軟件包存放在倉庫中，同樣的，Helm 也有倉庫。
Helm 安裝時已經默認配置好了兩個倉庫：stable 和 local。stable 是官方倉庫，local 是用戶存放自己開發的 chart 的本地倉庫。
helm search 會顯示 chart 位於哪個倉庫，比如 local/cool-chart 和 stable/acs-engine-autoscaler。
用戶可以通過 helm repo add 添加更多的倉庫，比如企業的私有倉庫，倉庫的管理和維護方法請參考官網文檔 https://docs.helm.sh
與 apt 和 yum 一樣，helm 也支持關鍵字搜索：
包括 DESCRIPTION 在內的所有信息，只要跟關鍵字匹配，都會顯示在結果列表中。
安裝 chart 也很簡單，執行如下命令可以安裝 MySQL。
helm install stable/mysql
如果看到如下報錯，通常是因為 Tiller 服務器的權限不足。
執行如下命名添加權限：
kubectl create serviceaccount --namespace kube-system tiller kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
需要添加倉庫
helm repo list #列出所有源，當前還沒有添加源 # 添加一個國內可以訪問的阿里源，不過好像最近不更新了 helm repo add ali https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts 如果能連外網，可以加google，f8 helm repo add google https://kubernetes-charts.storage.googleapis.com helm repo add fabric8 https://fabric8.io/helm # 更新源 helm repo update
無法科學上網，只好老實的加一條阿里的倉庫
輸出分為三部分：
① chart 本次部署的描述信息：
NAME 是 release 的名字，因為我們沒用 -n 參數指定，Helm 隨機生成了一個，這里是 piquant-parrot。
NAMESPACE 是 release 部署的 namespace，默認是 default，也可以通過 --namespace 指定。
STATUS 為 DEPLOYED，表示已經將 chart 部署到集群。
② 當前 release 包含的資源：Service、Deployment、Secret 和 PersistentVolumeClaim，其名字都是 fun-zorse-mysql，命名的格式為 ReleasName-ChartName。
③ NOTES 部分顯示的是 release 的使用方法。比如如何訪問 Service，如何獲取數據庫密碼，以及如何連接數據庫等。
通過 kubectl get 可以查看組成 release 的各個對象
因為我們還沒有准備 PersistentVolume，當前 release 還不可用。
helm list 顯示已經部署的 release，helm delete 可以刪除 release