Helm Charts 是 Kubernetes 應用程式的打包格式,可以想像成是一個”食譜”,裡面包含了部署應用程式所需的所有 Kubernetes 資源定義。
主要包含:
- 應用程式的 Kubernetes YAML 檔案(如 Deployment、Service、ConfigMap 等)
- 版本資訊
- 應用程式的配置選項
- 相依性設定
舉例來說,如果要部署一個 WordPress 網站,一個 WordPress Chart 會包含:
wordpress/
Chart.yaml # Chart 的版本和資訊
values.yaml # 預設配置值
templates/ # Kubernetes 資源模板
deployment.yaml # WordPress 的部署設定
service.yaml # 服務設定
ingress.yaml # 入口設定
OCI(Open Container Initiative)原本是用來定義容器映像檔的標準格式,現在這個標準也被用來儲存 Helm Charts。
主要優點:
- 可以和容器映像檔使用相同的儲存庫
- 有標準的版本控制
- 支援數位簽名,提高安全性
- 可以使用相同的存取控制機制
比較傳統方式和 OCI 格式:
傳統 Chart 儲存:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install wordpress bitnami/wordpress
OCI 格式儲存:
helm install wordpress oci://registry.example.com/charts/wordpress:1.0.0
在 Google Cloud 的情境下,使用 Artifact Registry 儲存 OCI 格式的 Charts 特別有優勢:
- 可以集中管理容器映像檔和 Charts
- 整合 Google Cloud 的存取控制
- 支援 VPC Service Controls 提高安全性
- 有完整的版本追蹤和稽核記錄
那你可能會問 WordPress 不是一整包 php 程式檔嗎?它們存在哪裡?
Helm Charts 本身不包含 WordPress 的 PHP 檔案。Charts 只包含了 Kubernetes 的部署設定檔。實際的 WordPress PHP 檔案是存在於容器映像檔(Container Image)中。
讓我用 WordPress 為例子來說明整個架構:
- 容器映像檔(Container Image)
- 包含 WordPress 的所有 PHP 檔案
- 包含 Apache/PHP 運行環境
- 通常存放在像 Docker Hub 這樣的容器登錄庫
- 例如:
wordpress:6.4.3
- Helm Chart
- 只包含 Kubernetes 的設定檔
- 會在設定中引用上面的容器映像檔
- 例如在
deployment.yaml
中:
spec:
containers:
- name: wordpress
image: wordpress:6.4.3 # 這裡引用包含實際 PHP 檔案的容器映像檔
ports:
- containerPort: 80
所以完整的部署流程是:
- Kubernetes 讀取 Helm Chart 的設定
- 根據設定去下載指定的容器映像檔
- 將容器映像檔(包含 PHP 檔案)部署到 Kubernetes 集群中
這種設計的好處是:
- 關注點分離:部署設定(Chart)和應用程式程式碼(容器映像檔)可以分開管理
- 重用性:同一個容器映像檔可以用不同的 Chart 設定來部署
- 版本控制:程式碼和部署設定可以分別進行版本控制