什麼是 Kubernetes Helm?
首先來看一下官網的解釋:
Helm is a tool for managing Kubernetes charts. Charts are packages of pre-configured Kubernetes resources.
Helm 就有點像是 Ubuntu 中的 APT 系統,也類似 Ansible 中的 Galaxy;簡單來說就是可以將一個 or 多個應用包裝成一個服務,並透過 chart 的形式發佈,讓大家可以方便在 k8s 上安裝特定的服務。
詳細的說明 & 架構可以參考此篇文章 —-> The Kubernetes Package Manager : Helm - inwinSTACK
以下也有兩張圖可以說明一下 Helm 系統架構:
從上面的文章中,要弄清楚 Helm client
& Tiller server
的關係:
Tiller server 是用來與 API server 溝通,使用 chart 在 k8s cluster 上建立服務
Helm client 則是用來操作 Tiller server 用
此外,佈署 Helm 時可以將其佈署在 cluster level(整個 k8s cluster 皆可用),也可以佈署在 namespace level(只會在該 namespace 可用),這部份可以根據自己的需求去決定。
Helm 要解決什麼問題?
一個工具被開發出來,總是被賦予要解決問題的任務,而 Helm 到底可以協助我們解決什麼樣的問題呢?
先來討論目前的趨勢:
線上的服務開始往 micro service 的方向走
k8s 似乎也變成整個 container 大一統的平台
因此使用 k8s 作為承載 micro service 的平台的確也是很正常的事情,但 k8s 為了解決各式各樣的問題,提供了大量的 resource object(pod, deployment, service … etc),因此如何利用這些 resource object 來組成一個完整的系統,整個過程是很複雜的,其中包含了很多不同面向的問題需要處理,例如:
如何管理、編輯 & 更新大量的 k8s resource object 設定檔?
如何快速佈署一個含有很多設定檔的 k8s application?
如何分享 & 重複利用 k8s resource object 設定檔?
如何透過 parameter & template 的方式,使用相同的設定檔來支援不同環境上的佈署?
如何管理 application 的 deployment, rollback, diff & history?
Application 發佈後如何進行驗證?
在 micro service 的過程中,林林總總的問題也跑了出來,而 Helm 就是為了解決上述問題而被開發出來的工具,它使用了以下幾個方式來解決上述的問題:
將 k8s resource object 打包到一個 chart 中 (chart 是多個 k8s resource object configuration 的集合)
將 chart 保存在 chart repository 中,透過 repository 的方式來儲存 & 分享 chart
Helm 則利用 chart 來進行 deployment, upgrade, rollback, version control …. 等工作
透過以上方式,大幅簡化在 k8s 上佈署 application 的複雜度。
安裝 Helm client
在 k8s cluster 安裝 tiller server 之前,我們要先來準備 Helm client,使用以下的指令安裝最新版的 Helm:
1 | $ wget https://storage.googleapis.com/kubernetes-helm/helm-$(curl -s https://api.github.com/repos/helm/helm/releases/latest | jq --raw-output '.tag_name')-linux-amd64.tar.gz -O helm-linux-amd64.tar.gz |
Helm 三大重要概念
學習 Helm 有 3 個重要概念必須先了解,分別是:
Chart
Repository
Release
Chart
Chart 其實就是一堆 k8s resource object definition 的集合,目的就是要在 k8s 上佈署多個不同的 resource object;而為了要重複利用,這些 resource object definition 必須要支援 template, parameter … 等相關功能。
這概念上就類似 APT dpkg, YUM rpm …. 等套件系統。
Repository
Repository 就是存放 Chart 的地方,由 Helm client 管理。
Release
Release 則是由 chart 產生的一個個 instance,一個 chart 可以被佈署多次,每一個佈署都是每個獨立的 instance,在 Helm 中則稱為 Release
,每個 release name 都不同且獨立運作的。
將 Helm 佈署至 Cluster Level
設定 current context
這裡要先確認 Helm 要安裝在哪個 k8s cluster 中(如果有多個的話)
1 | # 設定 default context |
為 Tiller server 開啟權限
從上面的說明可看出,其實 tiller 就是一個用來與 k8s API server 溝通的 service,因此我們要賦予 tiller 所需要的權限。
權限設定的流程如下:
在
kube-system
namespace 中建立 Service Accounttiller
建立 ClusterRoleBinding,將 Service Account
tiller
與 Cluster Rolecluster-admin
作繫結
首先準備以下檔案來進行設定,名稱為 rbac-config.yaml
:
1 | # 建立 Service Account "tiller" 給 Helm service 與 API server 認證之用 |
接著將上面的設定套用到 k8s 中:
kubectl apply -f rbac-config.yaml
最後進行 Helm 的初始化:
helm init –service-account tiller
如此一來 Helm client 就會開始透過 kubectl 與 k8s cluster 溝通並建立所需要的相關資源:
1 | $ kubectl get deployment --all-namespaces | grep tiller |
將 Helm 佈署至 Namespace Level
這個部份的步驟其實跟 cluster level 差不多,大概就是:
在特定的 Namespace(假設是
helm-lab
) 中建立一個 Service Account(假設為tiller
)建立一個只有
helm-lab
namespace 中擁有所有權限的 Role(假設為tiller-manager
)建立一個 RoleBinding(假設為
tiller-binding
),將tiller-manager
與tiller
進行繫結
如此一來相關的權限設定大致上就完成了。
最後執行以下命令完成初始化:
helm init –service-account tiller
詳細的設定可以參考官網的說明。
開始使用 Kubernetes Helm
新增 namespace
這邊先建立一個全新的 namespace(helm-lab
) 來進行 Helm 的測試,並設定 default namespace:
1 | # 建立 namespace |
更新 Helm Repo
接著更新 Helm repository,Helm client 會取得所有 stable 的 charts:
1 | # 取得最新的 chart 資訊 |
安裝第一個 Helm Chart
1 | # 搜尋 mysql 相關的 Helm chart |
helm chart 的每一個佈署,都被稱為一個 release
,因此可以用同樣的 helm chart 安裝多個 release,從上面可以看到,在沒有指定 release name 的情況下,helm client 會自動幫你產生一個,上面的範例則是 wayfaring-butterfly
若要移除 release,可以使用 helm delete 命令:
1 | $ helm delete wayfaring-butterfly --purge |
雖然 release 被刪除,但是還是可以回溯的,因為 Helm 會幫你保留歷史紀錄:
1 | # 已經被刪除的 release 還是可以查到歷史紀錄 |
若想要回溯已經刪除的 release,可以透過 helm rollback
來完成。
結論
Helm 提供了 k8s 使用者一個方便佈署服務的方式,雖然 micro service 將 service 管理變得複雜了,但透過 Helm 的協助,可以讓管理者有條理地管理各個不同的服務 & 版本,再也不用跟一堆 YAML configuration 奮鬥,大幅減少人為的錯誤,並提升工作效率。