主要包含：

• 應用程式的 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 特別有優勢：

1. 可以集中管理容器映像檔和 Charts
2. 整合 Google Cloud 的存取控制
3. 支援 VPC Service Controls 提高安全性
4. 有完整的版本追蹤和稽核記錄

那你可能會問 WordPress 不是一整包 php 程式檔嗎？它們存在哪裡？

Helm Charts 本身不包含 WordPress 的 PHP 檔案。Charts 只包含了 Kubernetes 的部署設定檔。實際的 WordPress PHP 檔案是存在於容器映像檔（Container Image）中。

讓我用 WordPress 為例子來說明整個架構：

1. 容器映像檔（Container Image）
   • 包含 WordPress 的所有 PHP 檔案
   • 包含 Apache/PHP 運行環境
   • 通常存放在像 Docker Hub 這樣的容器登錄庫
   • 例如：wordpress:6.4.3
2. Helm Chart
   • 只包含 Kubernetes 的設定檔
   • 會在設定中引用上面的容器映像檔
   • 例如在 deployment.yaml 中：

spec:
  containers:
  - name: wordpress
    image: wordpress:6.4.3   # 這裡引用包含實際 PHP 檔案的容器映像檔
    ports:
    - containerPort: 80

所以完整的部署流程是：

1. Kubernetes 讀取 Helm Chart 的設定
2. 根據設定去下載指定的容器映像檔
3. 將容器映像檔（包含 PHP 檔案）部署到 Kubernetes 集群中

這種設計的好處是：

• 關注點分離：部署設定（Chart）和應用程式程式碼（容器映像檔）可以分開管理
• 重用性：同一個容器映像檔可以用不同的 Chart 設定來部署
• 版本控制：程式碼和部署設定可以分別進行版本控制

The post [GKE 教學] Helm Charts 是什麼？什麼是 OCI 格式的 Charts？ first appeared on 東東 GCP 教學 - GCP 實戰講師.