kubernetes實戰篇之helm安裝
系列目錄
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 中的應用需要能夠自行處理依賴關係。
安裝過程
1) 先在 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
2) 下載helm release
每一個版本HELM提供多種作業系統的二進位制版本。可以手動下載和安裝這些版本。
下載頁面https://github.com/helm/helm/releases/
注意下載的時候選擇下載的是
Installation and Upgrading下面的包,而不是下面assets裡面的內容
注意以上github下載連結地址其實指向的是
storage.googleapis.com這個地址目前在國內還是能訪問的,但是時好時壞,通過wget下載很多能會失敗,建議在windows上點選連結下載,如果未能下載成功然後再進行重試,多重試幾次就能下載成功了,當然有上網軟體更好啦!
3) 解壓並拷貝
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目錄即可。
4) 安裝服務端（Tiller）
```bash
建立服務端
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
若遇到錯誤 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"}