管理 Kubernetes 的服務時常有一些困擾：
- 須根據環境 (staging, production…) 去套用不同的設定及環境變數，整合不易
- secret 常是手動新增，如 cloudsql-proxy 的憑證，時間久了常忘記該 secret 是幹麻用的，及整個服務重新部署也會卡在這個手動步驟
使用 Helm 可以幫助我們管理這些部署檔案：
- 一鍵部署、移除
- 可根據不同的環境採用不同變數，有幾種可行的作法
- 可根據彈性的判斷式生成設定檔
- chart 的版本控制 (Release)
準備事項：
- 有個叢集
- Client 端安裝 Helm ， Server 端安裝 Tiller
- 叢集有 RBAC ，可以關閉 RBAC ，或給 Tiller 權限：
helm init預設使用的服務帳戶是default- 叢集的
default服務帳戶綁定cluster-admin叢集角色
|
1 2 |
kubectl create clusterrolebinding default-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default |
Helm 有提供 dependency 的功能，可以透過以下指令來部署全部的 subchart：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
└── parentchart ├── charts │ ├── subchart1-0.1.0.tgz │ └── subchart2-0.1.0.tgz ├── Chart.yaml ├── README.md ├── requirements.lock ├── requirements.yaml ├── templates │ └── ingress.yaml └── values.yaml |
|
1 2 3 |
$ helm dependency update $ helm install -f values.yaml . |
但這裡會有一個問題，即部署時沒辦法指定 subchart 要吃哪個 value file ，因若你的 chart 參數是分成values.prod.yaml、values.staging.yaml，一旦 chart 打包成 package ，package 在使用時只能吃 values.yaml
下個版本可能提供相對應的作法，請參考相關 issue
透過 Cloud Build 部署
透過helm create建立並設定完 chart 後，希望能在 Cloud Build 的流程透過 helm 部署，這邊選用 cloud-builer-community 提供的helm映像檔
