Helm Charts 依賴與生命週期管理實務

Helm Charts 在 Kubernetes 應用管理中扮演著重要的角色，尤其在依賴管理和生命週期控制方面。理解如何有效地使用 helm dependency 命令和 Helm Hook 是提升 Kubernetes 應用佈署效率的關鍵。透過 helm dependency update 命令，可以將 Chart 的依賴下載到 charts/ 目錄，並生成 Chart.lock 檔案記錄實際使用的依賴版本。Chart.lock 檔案有助於重建依賴環境，避免將 charts/ 目錄納入版本控制。Helm 也支援條件式依賴，透過在 Chart.yaml 中設定條件和標籤，可以根據需求彈性控制依賴的載入。此外，操作和參照子圖表中的值也是 Helm Chart 管理的重點。父圖表可以覆寫子圖表的預設值，也可以透過 import-values 匯入子圖表的值。Helm Hook 則提供在 Chart 生命週期中不同階段執行特定動作的機制，例如在安裝前後執行指令碼、升級前後進行資料函式庫備份或還原，以及移除 Chart 前清理資源等。這些 Hook 以 Kubernetes Job 的形式實作，確保任務的可靠執行。瞭解 Helm Hook 的執行流程和錯誤處理機制，可以更好地控制 Chart 的生命週期，並提升應用佈署的可靠性。

深入瞭解 Helm Charts 依賴管理

下載及管理 Helm Charts 依賴

在使用 Helm 來管理 Kubernetes 應用時，依賴管理是一個至關重要的環節。Helm 提供了多種子命令來處理依賴的下載、更新和建構。這裡我們將探討如何使用 helm dependency 子命令來完成這些操作。

下載依賴

首先，你需要下載所需的依賴。這可以透過 helm dependency update 命令來實作，這個命令會將每個依賴下載到指定 Helm Chart 的 charts/ 目錄中。

$ helm dependency update $CHART_PATH

這個命令會從指定的儲存函式庫中下載依賴，並將它們以 GZip 壓縮格式（.tgz 檔案）儲存。同時，它還會生成一個 Chart.lock 檔案，這個檔案類別似於 Chart.yaml 檔案，但它記錄的是實際應用的依賴狀態，而不是期望的狀態。

Chart.lock 檔案解析

以下是一個 Chart.lock 檔案的範例：

dependencies:
- name: mariadb
  version: 7.3.1
  repository: "https://charts.bitnami.com/stable"

對比一下相應的 Chart.yaml 檔案：

dependencies:
- name: mariadb
  version: "7.x.x"
  repository: "https://charts.bitnami.com/stable"

在 Chart.yaml 中，我們指定了 MariaDB 的版本為 7.x.x，這意味著 Helm 會下載最新的 7.x.x 版本。而實際下載的版本可能是 7.3.1，這就是 Chart.lock 檔案中記錄的內容。

再次建構依賴

如果 charts/ 目錄被刪除或需要重建，Helm 能夠透過 Chart.lock 檔案來重新下載原始的依賴。這可以透過以下命令來實作：

$ helm dependency build $CHART_PATH

這樣可以避免將 charts/ 目錄納入版本控制系統，從而減少儲存函式庫的大小。

條件性依賴

Helm 支援條件性地包含依賴，這可以透過在 Chart.yaml 中設定條件和標籤來實作。以下是一個範例：

dependencies:
- name: dependency1
  repository: https://example.com
  version: 1.x.x
  condition: dependency1.enabled
  tags:
    - monitoring
- name: dependency2
  repository: https://example.com
  version: 2.x.x
  condition: dependency2.enabled
  tags:
    - monitoring

在這個範例中，dependency1 和 dependency2 的包含取決於對應的條件欄位。如果這些條件在 values.yaml 或使用者提供的值中評估為 true，則依賴會被包含；否則不會被包含。

標籤控制

標籤可以用來控制多個依賴的一同包含或排除。例如，如果設定了 monitoring 標籤為 true，則所有標有這個標籤的依賴都會被包含。反之亦然。

操作和參考子圖表中的值

在 Helm 中，子圖表（即依賴）中的值可以被父圖表覆寫或參照。以下是如何操作和參照子圖表中的值：

操作子圖表中的值

假設有一個名為 my-dep 的子圖表，其支援以下值：

replicas: 1
servicePorts:
- 8080
- 8443

當這個子圖表作為依賴安裝時，你可以透過在父圖表中設定相應的 YAML 物件來覆寫這些值：

my-dep:
replicas: 3
servicePorts:
- 8080
- 8443
- 8778

你還可以在父圖表的範本中透過點符號參照這些值：

{{ .Values.my-dep.replicas }}

輸入子圖表中的值

Helm 支援透過 import-values 域從子圖表匯入預設值。首先，子圖表需要在其 values.yaml 中宣告要匯出的值：

exports:
image:
registry: 'my-registry.io'
name: learnhelm/my-image'
tag: latest'

接著，父圖表可以在其 Chart.yaml 中定義 import-values 域：

dependencies:
- name: mariadb
repository: https://charts.bitnami.com'
version: '7.x.x'
import-values:
- image'

這樣做後，父圖表就可以參照從子圖表匯入的值：

registry: 'my-registry.io'
name: learnhelm/my-image'
tag: latest'

最佳實踐與未來趨勢

在處理 Helm Charts 的依賴時，以下幾點最佳實踐值得注意：

版本鎖定：總是鎖定具體版本以確保環境的一致性。
條件性依賴：利用條件和標籤來靈活控制依賴的包含與排除。
依賴管理：定期更新和檢查依賴以確保安全性和穩定性。

隨著 Kubernetes 生態系統的不斷發展，Helm 的功能也在不斷增強。未來可能會看到更多自動化工具和更高效的依賴管理機製出現。玄貓建議大家保持關注相關社群和官方發布資訊，及時更新自己的技術知識和工具鏈。

透過深入瞭解 Helm Charts 的依賴管理機制以及合理應用上述最佳實踐和技術選型分析，玄貓希望能夠幫助各位讀者在 Kubernetes 生態系統中更加自如地進行應用佈署與管理。

Helm 圖表的生命週期管理

在 Kubernetes 環境中，Helm 圖表是管理複雜應用程式的強大工具。這些圖表經歷多個階段，從安裝到升級、移除和回復。為了在這些階段中提供更多的管理功能，Helm 提供了「Hook」機制，讓我們可以在特定時間點執行特定動作。這些動作不僅可以與釋出版本互動，還可以與整個 Kubernetes 環境互動。

Helm Hook 的基礎

Hook 是一個一次性的動作，會在釋出版本生命週期中的特定時間點執行。就像 Helm 中大多數功能一樣，Hook 也是以 Kubernetes 資源的形式實作的，特別是在容器中。雖然 Kubernetes 中大多數工作負載都是長期執行的程式，但也可以是由指令碼執行的一個或多個任務。這些任務在完成後會顯示成功或失敗。

在 Kubernetes 環境中，常用的兩種短暫任務選項是「Pod」和「Job」。Pod 是一種執行至完成後終止的容器，但如果底層節點失敗則不會重新排程。因此，執行生命週期 Hook 的最佳選擇是 Job，因為它可以在節點失敗或不可用時重新排程 Hook。

由於 Hook 只是定義為 Kubernetes 資源，它們也會放在 templates/ 資料夾中，並附上 helm.sh/hook 註解。這個註解確保它們不會在標準處理過程中與其他資源一起渲染到 Kubernetes 環境中。相反地，它們根據 helm.sh/hook 註解中的值來渲染和應用，這決定了它們應該在 Helm 釋出版本生命週期中的哪個時間點執行。

Hook 的執行

Hook 的執行時間點有多種選項。以下是 helm.sh/hook 註解的可用選項及其描述：

pre-install: 在安裝過程開始前執行。
post-install: 在安裝過程完成後執行。
pre-upgrade: 在升級過程開始前執行。
post-upgrade: 在升級過程完成後執行。
pre-rollback: 在回復過程開始前執行。
post-rollback: 在回復過程完成後執行。
pre-delete: 在移除過程開始前執行。
post-delete: 在移除過程完成後執行。

這些 Hook 可以應用於 Pod 或 Job 上，並且可以包含多個值來指示相同資源在圖表釋出版本週期中的不同時間點被執行。

工作範例：

apiVersion: batch/v1
kind: Job
metadata:
  name: helm-auditing
  annotations:
    'helm.sh/hook': pre-install,post-install
spec:
  template:
    metadata:
      name: helm-auditing
    spec:
      restartPolicy: Never
      containers:
      - name: helm-auditing
        command: ["/bin/sh", "-c", "echo Hook Executed at $(date)"]
        image: alpine

此範例展示瞭如何將一個簡單的 Job 作為 Hook 定義。這個 Job 在安裝圖表之前和之後都會執行，並在容器中列印當前日期和時間。

高階 Hook 概念

儘管將標準 Helm 範本資源轉換為 Hook 需要很少努力，但還有其他選項可以幫助圖表執行和資源移除。

清理階段

當我們需要在移除圖表之前清理資產時，特別是那些不由 Helm 管理的資源時，「pre-delete」和「post-delete」Hook 就非常有用了。例如，我們可以使用這些 Hook 清理一些外部資源或日誌。

apiVersion: batch/v1
kind: Job
metadata:
  name: cleanup-job
  annotations:
    'helm.sh/hook': pre-delete,post-delete
spec:
  template:
    metadata:
      name: cleanup-job
    spec:
      restartPolicy: Never
      containers:
      - name: cleanup-container
        command: ["/bin/sh", "-c", "echo Cleaning up resources at $(date)"]
        image: alpine

錯誤處理

Hook 的另一個高階功能是錯誤處理。我們可以定義「success」和「failure」Hook。當主要資源成功或失敗時，這些 Hook 會被觸發。

apiVersion: batch/v1
kind: Job
metadata:
  name: success-job
  annotations:
    'helm.sh/hook': post-install,success # only runs on successful installation
spec:
  template:
    metadata:
      name: success-job
    spec:
      restartPolicy: Never
      containers:
      - name: success-container
        command: ["/bin/sh", "-c", "echo Installation was successful at $(date)"]
        image: alpine

---

apiVersion: batch/v1
kind: Job
metadata:
  name: failure-job
  annotations:
    'helm.sh/hook': post-install,failure # only runs on failed installation
spec:
  template:
    metadata:
      name: failure-job
    spec:
      restartPolicy: Never
      containers:
      - name: failure-container
        command: ["/bin/sh", "-c", "echo Installation failed at $(date)"]
        image: alpine

Helm Hook 的使用場景

Helm Hook 有許多實際應用場景：

應用前置條件管理：例如管理憑證和秘密。
資料函式倉管理：在升級圖表時進行資料函式庫備份或還原。
清理資源：在移除圖表之前清理資產。

Hook 執行流程

理解 Helm Hook 執行流程對於確定圖表生命週期中需要選擇的特定階段非常重要。例如，當我們執行 helm install 命令時：

使用者安裝 Helm Chart（例如 helm install bitnami/wordpress --version 8.1.0）。
呼叫 Helm API。
載入 crds/ 資料夾中的 CRDs。
驗證範本並渲染資源。
按權重順序排列並渲染、載入預安裝鉤子到 Kubernetes。
Helm 停止直到鉤子就緒。
渲染並將範本資源應用到 Kubernetes。
執行後安裝鉤子。
Helm 停止直到後安裝鉤子完成。
剛剛傳回結果。

透過掌握這些基本概念和高階功能，我們可以更好地利用 Helm Hook 在 Kubernetes 中管理複雜應用程式的生命週期。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。