Helm提供了Hook的機制，允許Chart開發人員在Release的生命週期中的某些節點來進行干預，比如我們可以利用Hooks來做下面的這些事情：
- 在加載Chart的其它資源之前，先加載ConfigMap或Secret。
- 在安裝新Chart之前執行作業以備份數據庫，然後在升級後執行第二個作業以恢復數據。
- 在刪除Release之前運行作業，以便在刪除Release之前優雅地停止服務。
Hooks和普通模板一樣工作，但是它們具有特殊的註釋，可以使Helm以不同的方式使用它們。
Hooks在資源清單中的metadata部分用annotations註解的方式進行聲明：
apiVersion: batch/v1
kind: Job
metadata:
annotations:
"helm.sh/hook": post-install
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": hook-succeeded
......
Helm中定義瞭如下一些可供我們使用的Hooks：
| 註解值 | 說明 |
|---|---|
| 預安裝pre-install | 在渲染模板之後，但在Kubernetes中創建任何資源之前執行 |
| 安裝後post-install | 在所有Kubernetes資源安裝到集羣后執行 |
| 預刪除pre-delete | 在從Kubernetes刪除任何資源之前執行刪除請求 |
| 刪除後post-delete | 刪除所有Release的資源後執行 |
| 升級前pre-upgrade | 在渲染模板之後，但在任何資源升級之前執行 |
| 升級後post-upgrade | 在所有資源升級後執行 |
| 預回滾pre-rollback | 在模板渲染後，在任何資源回滾之前執行 |
| 回滾後post-rollback | 在修改所有資源後執行回滾請求 |
| 測試test | 在調用Helm test子命令時執行 |
請注意，爲了支持Helm 3中的crds目錄，已刪除了crd-install鉤子。
Hooks允許開發人員在Release的生命週期中的一些關鍵節點執行一些鉤子，我們正常安裝一個Chart包的時候的生命週期如下所示：
- 用戶運行helm install foo
- Helm客戶端調用Helm library庫的安裝API
- 經過一些驗證，Helm庫渲染foo模板
- Helm庫將產生的資源加載到Kubernetes中去
- Helm庫將Release對象（和其它數據）返回給Helm客戶端
- Helm客戶端退出
如果開發人員在install的生命週期中定義了兩個hook：pre-install和post-install，那麼我們安裝一個Chart包的生命週期就會多一些步驟了：
- 用戶運行helm install foo
- Helm客戶端調用Helm library庫的安裝API
- 安裝crds目錄下的CRDs
- 經過一些驗證，Helm庫渲染foo模板
- Helm庫準備執行pre-install hooks（將hook資源加載到kubernetes中）
- Helm庫根據權重對hooks進行排序（默認分配權重0），權重相同時按照名稱升序排序
- Helm庫然後加載最低權重的hook（從負到正）
- Helm庫等待，直到hook就緒Ready（除了CRDs）
- Helm庫將產生的資源加載到Kubernetes中去，注意：如果設置了–wait參數，Helm庫將會等待直到所有資源爲就緒狀態，在所有資源就緒前post-install hook不會執行
- Helm庫執行post-install hook（將hook資源加載到kubernetes中）
- Helm庫等待，直到hook就緒Ready
- Helm庫將Release對象（和其它數據）返回給Helm客戶端
- Helm客戶端退出
等待直到hook就緒Ready意味着什麼？這是一個阻塞的操作，如果 hook 中聲明的是一個 Job 資源，那麼 Tiller 將等待 Job 成功完成，如果失敗，則發佈失敗，在這個期間，Helm 客戶端是處於暫停狀態的。
對於所有其他類型，只要 kubernetes 將資源標記爲加載（添加或更新），資源就被視爲就緒狀態，當一個 hook 聲明瞭很多資源是，這些資源是被串行執行的。
另外需要注意的是 hook 創建的資源不會作爲 release 的一部分進行跟蹤和管理，一旦 Tiller Server 驗證了 hook 已經達到了就緒狀態，它就不會去管它了。
所以，如果我們在 hook 中創建了資源，那麼不能依賴helm delete去刪除資源，因爲 hook 創建的資源已經不受控制了，要銷燬這些資源，需要在pre-delete或者post-delete這兩個 hook 函數中去執行相關操作，或者將helm.sh/hook-delete-policy這個 annotation 添加到 hook 模板文件中。
等待直到hook就緒Ready意味着什麼？這取決於鉤子中聲明的資源。如果資源是Job或Pod類型，Helm將等待直到成功運行完成completion爲止。如果鉤子失敗，Release就會失敗。
對於所有其它資源類型，只要Kubernetes將資源標記爲已加載loaded（添加added或更新updated），該資源即被視爲就緒Ready。
Hooks也是Kubernetes清單文件，只不過是在metadata中帶有特殊的註解annotation。因爲Hooks也是模板文件，所以可以使用所有常規模板功能，包括讀取.Values，.Release和.Template。
例如，現在我們來創建一個Hook，在前面的示例templates/目錄中添加一個post-install-job.yaml的文件，表示安裝後執行的一個hook：
apiVersion: batch/v1
kind: Job
metadata:
name: "{{ .Release.Name }}"
labels:
app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
app.kubernetes.io/instance: {{ .Release.Name | quote }}
app.kubernetes.io/version: {{ .Chart.AppVersion }}
helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
annotations:
# This is what defines this resource as a hook. Without this line, the
# job is considered part of the release.
"helm.sh/hook": post-install
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": hook-succeeded
spec:
template:
metadata:
name: "{{ .Release.Name }}"
labels:
app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
app.kubernetes.io/instance: {{ .Release.Name | quote }}
helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
spec:
restartPolicy: Never
containers:
- name: post-install-job
image: "alpine:3.3"
command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"]
使這個模板成爲鉤子的原因是以下的註解：
annotations:
"helm.sh/hook": post-install
一種資源也可以實現多個掛鉤，如下該資源可以在安裝後和升級後執行。
annotations:
"helm.sh/hook": post-install,post-upgrade
同樣，一種Hook也可以有多個資源支持。例如，可以將Secret和ConfigMap都聲明爲預安裝鉤子。
當subchart聲明鉤子時，也會對其進行評估。頂級Chart圖表無法禁用子Chart所聲明的鉤子。
可以爲鉤子定義權重，這將有助於建立確定性的執行順序。權重使用以下注釋定義：
annotations:
"helm.sh/hook-weight": "5"
鉤子刪除策略定義了何時刪除相應鉤子資源的策略。掛鉤刪除策略使用以下注釋定義：
annotations:
"helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
| 註解值 | 說明 |
|---|---|
| before-hook-creation | 在啓動新的掛鉤之前刪除先前的資源（默認） |
| hook-succeeded | 掛鉤成功執行後刪除資源 |
| hook-failed | 如果掛鉤在執行期間失敗，則刪除資源 |