安裝
Helm有兩個部分：Helm用戶端（helm）和Helm服務端（Tiller）。本指南介紹如何安裝用戶端，然後繼續示範兩種安裝服務端的方法。
重要提示：如果你負責的群集是在受控的環境，尤其是在共享資源時，強烈建議使用安全配置安裝Tiller。有關指導，請參閱“Helm安全安裝”。
我在網址
https://whmzsu.github.io/helm-doc-zh-cn/不斷更新，同時也會搬運到這裡，大家有興趣加入
https://github.com/whmzsu/helm-doc-zh-cn/的可以給我送出意見和建議。
安裝Helm用戶端
Helm用戶端可以從源代碼安裝，也可以從預建構的二進制版本安裝。
二進制版本
每一個版本
releaseHelm提供多種作業系統的二進制版本。這些二進制版本可以手動下載下傳和安裝。
- 下載下傳你 想要的版本
- 解壓縮（
tar -zxvf helm-v2.0.0-linux-amd64.tgz
-
helm
mv linux-amd64/helm /usr/local/bin/helm
到這裡，你應該可以運作用戶端了：
helm help
。
通過homebrew（macOS）
Kubernetes社群的成員為Homebrew貢獻了Helm。這個通常是最新的。
brew install kubernetes-helm （注意：emacs-helm也是一個軟體，這是一個不同的項目。）
從Chocolatey（Windows）
Kubernetes社群的成員為 Chocolatey貢獻了Helm包。這個軟體包通常是最新的。
choco install kubernetes-helm 從腳本
Helm現在有一個安裝shell腳本，将自動擷取最新版本的Helm用戶端并在本地安裝。
可以擷取該腳本，然後在本地執行它。這種方法也有文檔指導，以便可以在運作之前仔細閱讀并了解它在做什麼。
$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash 也可以做到這一點。
從金絲雀版本(Canary )建構
“Canary”版本是從最新的主分支建構的Helm軟體的版本。它們不是正式版本，可能不穩定。但是，他們提供了測試最新功能的機會。
“Canary”版本Helm二進制檔案存儲在Kubernetes Helm GCS存儲中。以下是常見建構的連結：
源代碼方式（Linux，macOS）
從源代碼建構Helm的工作稍微多一些，但如果你想測試最新的（預釋出）Helm版本，那麼這是最好的方法。
你必須有一個安裝Go工作環境 。
$ cd $GOPATH
$ mkdir -p src/k8s.io
$ cd src/k8s.io
$ git clone https://github.com/kubernetes/helm.git
$ cd helm
$ make bootstrap build 該
bootstrap
目标将嘗試安裝依賴，重建 vendor/樹，并驗證配置。
build
目标編譯
helm
并将其放置在
bin/helm
目錄。Tiller也會編譯，并且被放置在
bin/tiller
目錄。
安裝Tiller
Helm的伺服器端部分Tiller通常運作在Kubernetes叢集内部。但是對于開發，它也可以在本地運作，并配置為與遠端Kubernetes群集通信。
快捷群集内安裝
tiller
到群集中最簡單的方法就是運作
helm init
。這将驗證
helm
本地環境設定是否正确（并在必要時進行設定）。然後它會連接配接到
kubectl
預設連接配接的任何叢集（
kubectl config view
）。一旦連接配接，它将安裝
tiller
到
kube-system
命名空間中。
helm init
以後，可以運作
kubectl get pods --namespace kube-system
并看到Tiller正在運作。
你可以通過參數運作
helm init
:
-
--canary-image
-
--tiller-image
-
--kube-context
-
--tiller-namespace
一旦安裝了Tiller，運作helm version會顯示用戶端和伺服器版本。（如果它僅顯示用戶端版本， 則helm無法連接配接到伺服器,使用
kubectl
檢視是否有任何 tiller Pod正在運作。）
除非設定
--tiller-namespace
或
TILLER_NAMESPACE環境變量
參數，否則Helm将在命名空間
kube-system
中查找Tiller 。
安裝Tiller金絲雀版本
Canary 鏡像是從master分支建立的。他們可能不穩定，但他們提供測試最新功能的機會。
安裝Canary 鏡像最簡單的方法是helm init與 –canary-image參數一起使用：
$ helm init --canary-image 這将使用最近建構的容器鏡像。可以随時使用
kubectl
删除
kube-system
名稱空間中的Tiller deployment來解除安裝Tiller。
本地運作Tiller
對于開發而言，有時在本地運作Tiller更容易，将其配置為連接配接到遠端Kubernetes群集。
上面介紹了建構部署Tiller的過程。
一旦tiller建構部署完成，隻需啟動它：
$ bin/tiller
Tiller running on :44134 當Tiller在本地運作時，它将嘗試連接配接到由
kubectl
配置的Kubernetes群集。（運作kubectl config view以檢視是哪個群集。）
必須告知helm連接配接到這個新的本地Tiller主機，而不是連接配接到群集中的一個。有兩種方法可以做到這一點。第一種是在指令行上指定
--host
選項。第二個是設定
$HELM_HOST
環境變量。
$ export HELM_HOST=localhost:44134
$ helm version # Should connect to localhost. Client: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"db...", GitTreeState:"dirty"} Server: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"a5...", GitTreeState:"dirty"} 注意，即使在本地運作，Tiller也會将安裝的release配置存儲在Kubernetes内的ConfigMaps中。
更新Tiller
從Helm 2.2.0開始，Tiller可以更新使用
helm init --upgrade
對于舊版本的Helm或手動更新，可以使用
kubectl
修改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
deployment "tiller-deploy" image updated 設定
TILLER_TAG=canary
将獲得master版本的最新快照。
删除或重新安裝Tiller
由于Tiller将其資料存儲在Kubernetes ConfigMaps中，是以可以安全地删除并重新安裝Tiller，而無需擔心丢失任何資料。推薦删除Tiller的方法是使用
kubectl delete deployment tiller-deploy --namespace kube-system
或更簡潔使用
helm reset
然後可以從用戶端重新安裝Tiller：
$ helm init 進階用法
helm init 提供了額外的參數，用于在安裝之前修改Tiller的deployment manifest。
使用 --node-selectors
--node-selectors
--node-selectors
參數允許我們指定排程Tiller Pod所需的節點标簽。
下面的例子将在nodeSelector屬性下建立指定的标簽。
helm init --node-selectors "beta.kubernetes.io/os"="linux" 已安裝的deployment manifest将包含我們的節點選擇器标簽。
...
spec: template:
spec:
nodeSelector:
beta.kubernetes.io/os: linux
... 使用 –override
--override
允許指定Tiller的deployment manifest的屬性。與在Helm其他地方
--set
使用的指令不同，
helm init --override
修改最終manifest的指定屬性（沒有”values”檔案）。是以，可以為deployment manifest中的任何有效屬性指定任何有效值。
覆寫注釋
在下面的示例中，我們使用–override添加修訂版本屬性并将其值設定為1。
helm init --override metadata.annotations."deployment\.kubernetes\.io/revision"="1" 輸出：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1" ... 覆寫親和性
在下面的例子中，我們為節點設定了親和性屬性。
--override
可以組合來修改同一清單項的不同屬性。
helm init --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].weight"="1" --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].preference.matchExpressions[0].key"="e2e-az-name" 指定的屬性組合到“preferredDuringSchedulingIgnoredDuringExecution”屬性的第一個清單項中。
...
spec:
strategy: {} template: ...
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution: - preference:
matchExpressions: - key: e2e-az-name
operator: ""
weight: 1 ... 使用 –output
--output
參數允許我們跳過安裝Tiller的deployment manifest，并以JSON或YAML格式簡單地将deployment manifest輸出到标準輸出stdout。然後可以使用
jq
類似工具修改輸出，并使用
kubectl
手動安裝。
在下面的例子中，我們helm init用–output json 參數執行。
helm init --output json Tiller安裝被跳過，manifest以JSON格式輸出到stdout。
"apiVersion": "extensions/v1beta1", "kind": "Deployment", "metadata": { "creationTimestamp": null, "labels": { "app": "helm", "name": "tiller" }, "name": "tiller-deploy", "namespace": "kube-system" }, ... 存儲後端
預設情況下，tiller将安裝release資訊存儲在其運作的名稱空間中的ConfigMaps中。從Helm 2.7.0開始，現在有一個Secrets用于存儲安裝release資訊的beta存儲後端。添加了這個功能是為和Kubernetes的加密Secret一起，保護chart的安全性。
要啟用secrets後端，需要使用以下選項啟動Tiller：
helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' 目前，如果想從預設後端切換到secrets後端，必須自行為此進行遷移配置資訊。當這個後端從beta版本畢業時，将會有更正式的移徙方法。
總結
在大多數情況下，安裝和擷取預先建構的helm二進制代碼及
helm init
一樣簡單。這個文檔提供而了一些用例給那些想要用Helm做更複雜的事情的人。
一旦成功安裝了Helm Client和Tiller，可以繼續下一步使用Helm來管理charts。
本文轉自kubernetes中文社群-
Helm 使用者指南-系列（2）-安裝![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)