Helm安裝

Helm安裝

Helm有兩個部分：Helm客戶端（helm）和Helm伺服器（Tiller）。本指南介紹如何安裝客戶端，然後繼續演示兩種安裝服務端的方法。

重要提示：如果你負責的群集是在受控的環境，尤其是在共享資源時，強烈建議使用安全配置安裝Tiller。有關指導，請參閱安全Helm安裝。

安裝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.shcurl 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/tillerTiller 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_TAGdeployment "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/v1beta1kind: Deploymentmetadata: 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

在下面的例子中，我們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。