Helm 用戶指南-系列（2）-安裝

安裝

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提供多種操作系統的二進制版本。這些二進制版本可以手動下載和安裝。

1. 下載你想要的版本
2. 解壓縮（tar -zxvf helm-v2.0.0-linux-amd64.tgz）
3. 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 AMD64
• macOS AMD64
• Experimental Windows AMD64

源代碼方式（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 用一個特定的命名空間(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參數允許我們指定調度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）-安裝