Helm是kubernetes的應用包管理工具,是CNCF孵化器下的一個項目,主要用來管理 Charts。類似於 Ubuntu 中的 APT 或 CentOS 中的 YUM.它提供了一種簡單的方法來發現,分享和使用為kubernetes准備的軟件包.它消除了繁雜的配置和部署,從而極大提高開發者的生效效率.
怎樣來理解它呢,假設我們的項目非常復雜,同時需要部署api網關,注冊中心,配置中心,web服務,數據庫中間件,消息隊列中間件和緩存中間件...這將會產生大量的配置文件,如果以上操行的順序不對或者某些參數不對,就可能造成整個系統部署失敗.如果你經過一段時間的實踐熟悉了整個部署流程,但是把工作交給其它同事時他仍然可能需要大量的時間來了解部署方案,如果你要把自己的方案在互聯網上分享,開發者往往想要一鍵部署,對於繁雜的配置可能會望而卻步.實踐中部署一個wordpress僅一個web項目和一個mysql服務器的部署就着實把不少開發者折騰的不輕,更不用說像上面復雜的配置了...
而helm正是要解決這樣的問題,它把一系列復雜的有狀態和無狀態服務的部署封裝起來(實際上就是對yaml文件的組織),然后你可以暴露出一些自定義參數信息供用戶選擇,這樣部署就會變得簡單很多.下面我們對helm的一些常用術語進行介紹並展示如何安裝helm
helm相關術語
-
Helm 是一個命令行下的客戶端工具。主要用於 Kubernetes 應用程序 Chart 的創建、打包、發布以及創建和管理本地和遠程的 Chart 倉庫。
-
Tiller 是 Helm 的服務端，部署在 Kubernetes 集群中。Tiller 用於接收 Helm 的請求，並根據 Chart 生成 Kubernetes 的部署文件（ Helm 稱為 Release ），然后提交給 Kubernetes 創建應用。Tiller 還提供了 Release 的升級、刪除、回滾等一系列功能。
-
Chart Helm 的軟件包，采用 TAR 格式。類似於 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一組定義 Kubernetes 資源相關的 YAML 文件
-
Repoistory Helm 的軟件倉庫，Repository 本質上是一個 Web 服務器，該服務器保存了一系列的 Chart 軟件包以供用戶下載，並且提供了一個該 Repository 的 Chart 包的清單文件以供查詢。Helm 可以同時管理多個不同的 Repository。
-
Release 使用 helm install 命令在 Kubernetes 集群中部署的 Chart 稱為 Release
注：需要注意的是：Helm 中提到的 Release 和我們通常概念中的版本有所不同，這里的 Release 可以理解為 Helm 使用 Chart 包部署的一個應用實例。
Chart Install 過程
-
Helm 從指定的目錄或者 TAR 文件中解析出 Chart 結構信息。
-
Helm 將指定的 Chart 結構和 Values 信息通過 gRPC 傳遞給 Tiller。
-
Tiller 根據 Chart 和 Values 生成一個 Release。
-
Tiller 將 Release 發送給 Kubernetes 用於生成 Release。
Chart Update 過程
-
Helm 從指定的目錄或者 TAR 文件中解析出 Chart 結構信息。
-
Helm 將需要更新的 Release 的名稱、Chart 結構和 Values 信息傳遞給 Tiller。
-
Tiller 生成 Release 並更新指定名稱的 Release 的 History。
-
Tiller 將 Release 發送給 Kubernetes 用於更新 Release。
Chart Rollback 過程
-
Helm 將要回滾的 Release 的名稱傳遞給 Tiller。
-
Tiller 根據 Release 的名稱查找 History。
-
Tiller 從 History 中獲取上一個 Release。
-
Tiller 將上一個 Release 發送給 Kubernetes 用於替換當前 Release。
Chart 處理依賴說明
Tiller 在處理 Chart 時，直接將 Chart 以及其依賴的所有 Charts 合並為一個 Release，同時傳遞給 Kubernetes。因此 Tiller 並不負責管理依賴之間的啟動順序。Chart 中的應用需要能夠自行處理依賴關系。
安裝過程
- 先在 K8S 集群上每個節點安裝 socat 軟件，不然會報如下錯誤：
E0522 22:22:15.492436 24409 portforward.go:331] an error occurred forwarding 38398 -> 44134: error forwarding port 44134 to pod dc6da4ab99ad9c497c0cef1776b9dd18e0a612d507e2746ed63d36ef40f30174, uid : unable to do port forwarding: socat not found.
Error: cannot connect to Tiller
# YUM 安裝（每個節點都要安裝）
yum install -y socat
要驗證socat是否已經安裝,在命令容器輸入
sockat
- 下載helm release
每一個版本HELM提供多種操作系統的二進制版本。可以手動下載和安裝這些版本。
下載頁面https://github.com/helm/helm/releases/
注意下載的時候選擇下載的是
Installation and Upgrading下面的包,而不是下面assets里面的內容
注意以上github下載鏈接地址其實指向的是
storage.googleapis.com這個地址目前在國內還是能訪問的,但是時好時壞,通過wget下載很多能會失敗,建議在windows上點擊鏈接下載,如果未能下載成功然后再進行重試,多重試幾次就能下載成功了,當然有上網軟件更好啦!
- 解壓並拷貝
tar -xzvf helm-v2.12.0-linux-amd64.tar.gz
cd linux-amd64 && mv helm /usr/bin/
壓縮中包含兩個可執行文件helm,tiller。其中tiller為server，若采用容器化部署到kubernetes中，則可以不用管tiller，只需將helm復制到/usr/bin目錄即可。
- 安裝服務端（Tiller）
# 創建服務端
helm init --service-account tiller --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
# 創建TLS認證服務端，參考地址：https://github.com/gjmzj/kubeasz/blob/master/docs/guide/helm.md
helm init --service-account tiller --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.1 --tiller-tls-cert /etc/kubernetes/ssl/tiller001.pem --tiller-tls-key /etc/kubernetes/ssl/tiller001-key.pem --tls-ca-cert /etc/kubernetes/ssl/ca.pem --tiller-namespace kube-system --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
```bash
若遇到錯誤 failed to list: configmaps is forbidden: User “system:serviceaccount:kube-system:default” cannot list configmaps in the namespace “kube-system”
執行以下命令
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"}}}}'
這里在init的時候需要指定鏡像源是因為init的時候襯tiller服務端,服務端是以deployment的方式安裝的.
也可以嘗試以下一鍵安裝命令
$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh
注意以下內容參照了這一篇文章,實際在安裝時沒有及時記錄下來,所以我的賬戶已經是正常的了,不知道是新版本的已經默認創建的sa還是我自己手動創建然后忘記了.這里也貼出來,初學的朋友不要害怕,即便是默認已經創建了,再執行以下命令也不會導致錯誤發生的.
給 Tiller 授權
因為 Helm 的服務端 Tiller 是一個部署在 Kubernetes 中 Kube-System Namespace 下 的 Deployment，它會去連接 Kube-Api 在 Kubernetes 里創建和刪除應用。
而從 Kubernetes 1.6 版本開始，API Server 啟用了 RBAC 授權。目前的 Tiller 部署時默認沒有定義授權的 ServiceAccount，這會導致訪問 API Server 時被拒絕。所以我們需要明確為 Tiller 部署添加授權。
可能看了以上描述的朋友依然一頭霧水,不知所雲,實際上是因為helm本身可以創建和刪除pod,因此它需要有操作權限.
- 創建 Kubernetes 的服務帳號和綁定角色
$ kubectl get deployment --all-namespaces
NAMESPACE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
kube-system tiller-deploy 1 1 1 1 1h
$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
- 為 Tiller 設置帳號
使用 kubectl patch 更新 API 對象
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
deployment.extensions "tiller-deploy" patched
- 查看是否授權成功
$ kubectl get deploy --namespace kube-system tiller-deploy --output yaml|grep serviceAccount
serviceAccount: tiller
serviceAccountName: tiller
- 驗證 Tiller 是否安裝成功
[centos@k8s-master ~]$ kubectl -n kube-system get pods|grep tiller
tiller-deploy-6df646875f-ttbn7 1/1 Running 5 15d
[centos@k8s-master ~]$ helm version
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
helm客戶端和服務端的版本必須是一致的才能正常工作
helm命令智能補全
source <(helm completion bash)
對於zsh命令,則使用如下命令
source <(helm completion zsh)
卸載helm
使用中你會發現,helm並不像想像的那樣能正常完美工作,時爾會出現一些小問題,可以使用以下命令來卸載
helm reset
查看 helm 版本信息
[centos@k8s-master tekton]$ helm version
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}