Helm 入門學習
概念：helm是什麼？Helm 是Kubernetes的包管理器。包管理器類似於在Ubuntu中使用的apt，能快速查找、下載和安裝軟件包。Helm由客戶端組件helm和服務端組件Tiller組成, 能夠將一組K8S資源打包統一管理, 是查找、共享和使用爲Kubernetes構建的軟件的最佳方式。因爲在Kubernetes中部署一個可以使用的應用，需要涉及到很多的 Kubernetes 資源的共同協作。而這些k8s資源過於分散，不方便進行管理，直接通過 kubectl 來管理一個應用，十分麻煩。所以使用helm就可以解決1）如何統一管理、配置和更新這些分散的 k8s 的應用資源文件，2）如何分發和複用一套應用模板。3）如何將應用的一系列資源當做一個軟件包管理。
原理：Helm的幾個關鍵組件 Helm（客戶端）、Tiller（服務器）、Repository（Chart 軟件倉庫）、Chart（軟件包）。helm之間的通信時helm client通過grpc協議消息傳到helm的服務器端Tiller，Tiller與k8s API交互。而helm的整體架構如下圖：
組件：1）helm 是一個命令行工具，用於本地開發及管理chart，chart倉庫管理等；2）Tiller 是 Helm 的服務端。Tiller 負責接收 Helm 的請求，與 k8s 的 apiserver 交互，根據chart 來生成一個 release 並管理 release；3）chart Helm的打包格式叫做chart，所謂chart就是一系列文件, 它描述了一組相關的 k8s 集羣資源；4）release 使用 helm install 命令在 Kubernetes 集羣中部署的 Chart 稱爲 Release；5）Repoistory Helm chart 的倉庫，Helm 客戶端通過 HTTP 協議來訪問存儲庫中 chart 的索引文件和壓縮包。具體的工作流程如下：
創建release：1）helm 客戶端從指定的目錄或本地tar文件或遠程repo倉庫解析出chart的結構信息； 2）helm客戶端指定的chart 結構和values信息通過 gRPC 傳遞給Tiller；3）Tiller 服務端根據 chart 和 values 生成一個 release； 4）Tiller 將install release請求直接傳遞給 kube-apiserver。同理刪除release：1）helm 客戶端從指定的目錄或本地tar文件或遠程repo倉庫解析出chart的結構信息；2）helm 客戶端指定的 chart 結構和 values 信息通過 gRPC 傳遞給 Tiller； 3）Tiller 服務端根據 chart 和 values 生成一個 release；4）Tiller 將delete release請求直接傳遞給 kube-apiserver。更新release：1）helm 客戶端將需要更新的 chart 的 release 名稱 chart 結構和 value 信息傳給 Tiller；2）Tiller 將收到的信息生成新的 release，並同時更新這個 release 的 history；3）Tiller 將新的 release 傳遞給 kube-apiserver 進行更新。
安裝前提：以下是成功和安全使用Helm的前提條件。1）一個Kubernetes集羣或有一個可訪問的集羣；2）決定將哪些安全配置應用於安裝（如果有的話）3）安裝和配置Helm和Tiller（集羣端服務）。你必須安裝Kubernetes。對於Helm的最新版本推薦Kubernetes的最新穩定版本，它在大多數情況下是第二個最新的次要版本，還應該有一個本地配置的kubectl。注：Kubernetes v1.6之前的版本對基於角色的訪問控制（RBAC）支持有限或不支持。Helm將通過讀取Kubernetes配置文件（通常爲 $HOME/ .kube/config）找到安裝Tiller的位置。這與kubectl使用的同一個文件。要找到Tiller要安裝到哪個集羣，可以運行kubectl config current-context或kubectl cluster-info。
安裝：Helm客戶端可以從源代碼安裝，也可以從預先構建的二進制版本安裝。1）使用二進制版本：Helm的每個版本都爲各種操作系統提供了相應的二進制版本。這些二進制版本可以手動下載和安裝。1）下載你需要的版本；2）解壓（tar -zxvf helm-v2.0.0-linux-amd64.tgz）；3）在解壓的目錄中找到helm二進制文件，將其移至合適的地方（mv linux-amd64/helm /usr/local/bin/helm）在那裏，你應該能夠運行客戶端：helm help。Helm現在有一個安裝腳本，可以自動獲取最新版本的Helm客戶端並在本地安裝。你可以獲取該腳本，然後在本地執行它。它有很好的文檔記錄，因此你可以在運行它之前通讀它並瞭解它在做什麼。$ curl -LO https://git.io/get_helm.sh $ chmod 700 get_helm.sh $ ./get_helm.sh 你還可以curl -L https://git.io/get_helm.sh | bash ，Tiller是Helm的服務端部分，通常運行在Kubernetes集羣內部。但對於開發，它也可以在本地運行，並配置爲與遠程Kubernetes集羣通信。
大多數雲提供商都支持一個稱爲基於角色的訪問控制的特性——簡稱RBAC。如果你的雲提供商啓用了此功能，你將需要爲Tiller創建一個服務賬戶，該帳戶具有訪問資源的正確角色和權限。在集羣中安裝tiller的最簡單方法是運行helm init。這將驗證Helm的本地環境是否正確設置（並在必要時進行設置）。然後它將默認連接到kubectl連接的集羣（kubectl config view）。一旦連接，它將把tiller安裝到kube-system命名空間中。helm init之後，你應該可以運行 kubectl get pods --namespace kube-system，並可以看到Tiller正在運行。一旦安裝了Tiller，運行helm version應該同時顯示客戶端和服務端版本。如果它只顯示客戶端版本，則helm還沒有連接到服務端。使用kubectl查看是否有tiller pod正在運行。Helm將在kube-system命名空間中查找Tiller，除非設置了--tiller-namespace 選項或 TILLER_NAMESPACE環境變量。對於開發，有時本地運行Tiller更加方便，並將其配置爲連接到遠程Kubernetes集羣。一但 tiller構建好了，只需要簡單地啓動它：$ bin/tiller Tiller running on :44134 當Tiller在本地運行時，它將嘗試連接到由kubectl配置的Kubernetes集羣。（運行kubectl config view，查看連接的是哪個集羣。）你必須告訴helm連接到這個本地Tiller主機，而不是連接到集羣中的一個Tiller主機。有兩種方法可以做到這一點。第一種方法是在命令行上指定--host選項。第二個是設置$HELM_HOST環境變量。$ export HELM_HOST=localhost:44134 $ helm version # Should connect to localhost。重要的是，即使在本地運行時，Tiller也會將發佈配置存儲在Kubernetes內部的ConfigMap中。
升級Tiller從Helm v2.2.0開始，Tiller可以使用 helm init --upgrade進行升級。對於舊版本的Helm，需要手動升級，你可以使用k8s修改Tiller的鏡像：$ export TILLER_TAG=v2.0.0-beta.1 # Or whatever version you want $ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG 設置TILLER_TAG=canary將獲得master分支的最新快照。刪除或重新安裝Tiller：因爲Tiller將其數據存儲在Kubernetes ConfigMap中，所以你可以安全地刪除和重新安裝Tiller，而不必擔心丟失任何數據。推薦的刪除Tiller的方式是使用kubectl delete deployment tiller-deploy --namespace kube-system，或者更簡潔一些：helm reset。然後可以使用以下命令從客戶端重新安裝Tiller：$ helm init helm init提供了額外的選項，用於在安裝Tiller的部署清單之前修改它。使用--node-selectors選項允許我們指定調度Tiller pod所需的節點標籤。下面的示例將在nodeSelector屬性下創建指定的標籤。helm init --node-selectors "bata.kubernetes.io /os" = "linux"; 使用--override 它允許你指定Tiller的部署清單的屬性。
與Helm中的--set選項不同helm init override操作最終清單的指定屬性（沒有“values”文件）。因此，你可以爲部署清單中的任何有效屬性指定任何有效值。使用--output output選項允許我們跳過Tiller的部署清單的安裝，直接以JSON或YAML格式將部署清單輸出到標準輸出。然後可以使用jq等工具修改輸出，並使用kubectl手動安裝。執行helm init時指定--output json選項。helm init --output json跳過了Tiller安裝，清單以JSON格式輸出到標準輸出。默認情況下，tiller將ConfigMap中的發佈信息存儲在它運行的名稱空間中。secret的存儲後端，在Helm v2.7.0中，現在有一個beta存儲後端，它使用Secret來存儲發佈（release）信息。這是爲了在Kubernetes發佈Secret加密的同時保護chart而增加的額外安全措施。要啓用secret存儲後端，你需要使用以下選項初始化Tiller：helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'；SQL存儲後端，在Helm v2.14.0中，現在有一個beta SQL存儲後端，它在SQL數據庫中存儲發佈信息（到目前爲止只測試了postgres）。如果你的發佈（release）信息超過1MB（在這種情況下，它不能存儲在ConfigMap或Secret中，因爲Kubernetes的底層etcd鍵值存儲存在內部限制），那麼使用這樣的存儲後端尤其有用。
三個重要的概念及使用：chart是一個Helm包。它包含了在Kubernetes集羣中運行應用程序、工具或服務所需的所有資源定義。可以把它看作Kubernetes的Homebrew formula、一個Apt dpkg或一個Yum RPM文件。倉庫（repository）是可以收集和共享chart的地方。它類似於Perl的CAPN歸檔或Fedora包數據庫，但倉庫針對的是Kubernetes包，是一個存放了index.yaml文件和一些的chart（可選）的HTTP服務器。當你準備共享chart時，最好的方法是將它們上傳到chart倉庫。由於chart倉庫可以是任何能夠提供YAML和tar文件並能夠響應GET請求的HTTP服務器，所以當涉及到託管自己的chart倉庫時，你有很多的選擇。例如，你可以使用谷歌雲存儲（GCS）桶、Amazon S3桶、Github頁面，甚至創建自己的web服務器。chart倉庫由打包的chart和稱爲index.yaml（包含倉庫中所有chart的索引）的特殊文件組成。通常情況下，index.yaml描述的chart和來源文件託管在同一服務器上。如倉庫 https://example.com/charts的佈局可能如下所示：
charts/
|
|- index.yaml
|
|- alpine-0.1.2.tgz
|
|- alpine-0.1.2.tgz.prov
索引文件是一個名爲index.yaml的yaml文件。它包含關於包的一些元數據，包括chart的Chart.yaml文件的內容。一個有效的chart倉庫必須有一個索引文件。索引文件包含關於chart倉庫中每個chart的信息。helm repo index命令將根據包含打包chart的給定本地目錄生成索引文件。
發佈（release）是在Kubernetes集羣中運行的chart的實例。一個chart通常可以多次安裝到同一個集羣中。每次安裝它時，都會創建一個新的發佈。考慮一個MySQL chart。如果希望在集羣中運行兩個數據庫，可以安裝該chart兩次。每個都有自己的發佈，而每個發佈又有自己的發佈名稱。Helm將chart安裝到Kubernetes中，爲每個安裝創建一個新的發佈。要找到新的chart，你可以搜索Helm chart倉庫。helm search：查找chart：當第一次安裝Helm時，它被預先配置爲與官方的Kubernetes chart倉庫進行交互。這個倉庫包含許多精心策劃和維護的chart。默認情況下，這個chart倉庫的名稱爲stable。可以運行helm search查看哪些圖表可用：如果不使用過濾器，helm search向你顯示所有可用的chart。你可以使用過濾器來縮小你的搜索結果：$ helm search mysql,可以使用helm inspect char查看helm 包的詳細信息。
使用helm install來安裝搜索得到的包，它只需要一個參數：chart的名稱。如$ helm install stable/mariadb；注：安裝chart會創建一個新的發佈對象。（如果你想使用自己的發佈名稱，只需在helm install上使用--name選項即可）在安裝期間，helm客戶端將打印關於創建了哪些資源、發佈的狀態如何以及是否可以或應該執行其他配置步驟的有用信息。Helm不會等到所有資源都運行之後才退出。許多chart需要大小超過600M的Docker鏡像，並且可能需要很長時間才能安裝到集羣中。在安裝過程中有兩種傳遞配置數據的方法: 1) --values 或者 -f：指定YAML文件覆蓋配置項。可以指定多次，最右邊的文件將優先；2) --set 與其變種 --set-string 和--set-file：在命令行中指定要覆蓋的配置項。如果兩者都使用，--set值將合併到具有更高優先級的 --values 值中。用--set指定的覆蓋將持久化在ConfigMap中。可以通過 helm get values <release-name>查看通過--set已設置的值。通過 --set 設置的值可以執行 helm upgrade時指定 --reset-values來清除。從Helm 2.5.0開始，可以使用數組索引語法訪問列表項。有時需要在--set行中使用特殊字符。你可以使用反斜槓來轉義字符；
helm upgrade和helm rollback，升級發佈並在失敗時進行恢復,當一個chart的新版本發佈時，或者當你想要改變發佈的配置時，你可以使用helm upgrade命令。升級採用現有版本並根據你提供的信息進行升級。因爲Kubernetes chart可能很大也很複雜，Helm試圖執行侵入性最小的升級。它將只更新自上一個版本以來更改的內容。$ helm upgrade -f panda.yaml happy-panda stable/mariadb在上面的例子中，happy-panda 發佈使用相同的chart進行了升級，但是使用了一個新的YAML文件：可以使用helm get values來查看新設置是否生效。helm get命令是查看集羣中某個發佈的有用工具。它顯示了我們從panda.yaml得到的、被部署到集羣中的新值。使用 helm rollback [RELEASE] [REVISION]很容易回滾到以前的發佈。可以使用helm history [RELEASE]來查看某個發佈的修訂號。在安裝、升級、回滾期間，還可以指定幾個其他有用的選項來自定義Helm的行爲。請注意，這不是一個完整的命令行選項。要查看所有選項的描述，只需運行 helm <command> --help。(1)--timeout：等待Kubernetes命令完成的秒數值，默認爲300（5分鐘）(2) --wait：等待，直到所有的pod都處於就緒狀態，PVC被綁定，部署在就緒狀態中有最少的pod（Desired 減去maxUnavailable），服務有一個IP地址（如果是LoadBalancer類型，則爲Ingress），然後纔將發佈標記爲成功。它將等待與--timeout值一樣長的時間。如果超時，則發佈將被標記爲FAILED。注意：在部署將 replicas設置爲1而maxUnavailable不設置爲0作爲滾動更新策略的一部分的場景中，--wait將返回Ready，因爲它滿足了Ready條件下的最少Pod。(3) --no-hooks：跳過鉤子執行 (4) --recreate-pods（只對 upgrade 和rollback可用） ：此選項將導致重新創建所有pod（屬於部署的pod除外）.helm delete：刪除發佈,可以使用helm list命令查看你目前部署的所有發佈：helm repo：操作倉庫,可以使用helm repo list查看配置了哪些倉庫：使用helm repo add添加一個新倉庫：$ helm repo add dev https://example.com/dev-charts由於chart倉庫經常更改，在任何時候都可以通過運行helm repo update來確保helm客戶端是最新的。