[k8s 生態鏈 完美組合 Day16] 我怎麼規劃 helm charts
介紹完了,helm value 間的上下層關係,今天來跟大家分享,我實際規劃團隊所使用的 helm 結構。不過會因為一些商業機密問題,內容會有所轉換,但會盡量呈現相近概念讓大家了解。
這邊先看一個示意圖
demo code
大家可以看到上圖,我切成兩個主要 charts ,分別為 backend & plugin ,然後 backend 下面分別有兩個 sub charts為 cart & user 。 這兩個 sub charts,又各自會需要 redis , 所以又分別它們各有一個 sub charts。
這裡假設的情況 backend 下面的 cart & user 會需要連線共同的 mysql。那我們不可能分別在 cart & user 的 value.yaml
各別去設定 mysql 的位置。所以我在 backend 這層的 values.yaml
就會設定這樣
global:
mysql:
host: 127.0.0.1:3306
user: root
password: test4321
運用到昨天所講的 global keyword。這樣我就能往下設定兩個服務,如果需要像前幾天講的 k8s namespace 介紹,需要拆成不同站台,那我就會依照不同站台設定不同 values.yaml
,如下
這時如果我需要在 QA 站做部署我只需要
$ helm install backend ./backend -f ./backend/qa-values.yaml
要在 PROD 站做部署
$ helm install backend ./backend -f ./backend/prod-values.yaml
這樣就很容易做到不同站別,快速部署。
裡面如果看到 image 都是拉 nginx ,是正常的,這裡純粹就是用
helm create
指令,跟小調整 deployment ,實際上並無法真實使用,純展示。
總結
導入 helm 的契機是在於,當微服務架構下,服務越拆越多,每個服務都有自己的 deployment,甚至服務之間都有相依問題,這方面的管理相當擾人。再加上我們團隊,剛開始使用 k8s 初期,常常會有人手殘把上面的服務全部刪掉,這時侯重建非常的困難….,只要一有人下錯指令,大家就要花很多時間在重建服務上面,嚴重 delay 開發進度。
有了 helm 協助下,我們不管何時何地,只要是 k8s ,我們可以在任何地方,把我們的服務『迅速』重建起來。而且所有的部署檔案,可以在很有架構下的管理,再搭配 git 策略,可以說是非常強大的工具,強烈推薦有在使用 k8s 的人,一定都要了解一下 helm 這套工具。