【51CTO.com快譯】Helm 是 Kubernetes 的包管理器。由于其模板方法和可重用和生產就緒包（也稱為 Helm charts)）的豐富生態系統，它減少了部署復雜應用程序的工作量。有了Helm可以將打包的應用程序部署為一組版本化、預配置的 Kubernetes 資源。

??

假設你正在使用 Kubernetes 部署一個數據庫，包括多個部署、容器、服務等。Helm 允許你使用單個命令和一組值安裝相同的數據庫。其聲明性和冪等性命令使 Helm 成為持續交付 (CD) 的理想工具。

隨著最新版本的Helm 3的發布，它與Kubernetes的生態系統融合得更加緊密。

本文介紹了創建Helm Chart來管理在Kubernetes中運行的應用程序的13個實踐案例。

1.充分利用Helm生態系統

Helm為你提供了豐富的社區專業知識——這可能是該工具最大的好處。它從世界各地的開發人員那里收集圖表，然后通過圖表庫進行共享。你可以將官方穩定圖表庫添加到本地，設置如下： 

$ helm repo add stable https://charts.helm.sh/stable
"stable" has been added to your repositories
Then you can search for charts, for example, MySQL:
$ helm search hub mysql
URL CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/mysql 8.2.3 8.0.22 Chart to create a Highly available MySQL cluster
https://hub.helm.sh/charts/t3n/mysql 0.1.0 8.0.22 Fast, reliable, scalable, and easy to use open-...

你會看到一長串的結果列表，可以看得出Helm圖表的生態系統有多大。

2. 使用子圖來管理你的依賴

由于部署到Kubernetes的應用程序由細粒度的、相互依賴的部分組成，因此它們的Helm圖表具有各種資源模板和依賴項。例如，假設后端依賴于數據庫和消息隊列。數據庫和消息隊列已經是獨立的應用(如PostgreSQL和RabbitMQ)。因此，建議為獨立應用程序創建或使用單獨的圖表，并將它們添加到父圖表中。依賴的應用程序在這里被命名為子圖表。

創建和配置子圖表有三個基本要素:

• 文件夾結構的順序如下：

backend-chart
- Chart.yaml
- charts
- message-queue
- Chart.yaml
- templates
- values.yaml
- database
- Chart.yaml
- templates
- values.yaml
- values.yaml

• Chart.yaml

另外Chart.yaml在父圖表中應該列出任何依賴關系和條件： 

apiVersion: v2
name: backend-chart
description: A Helm chart for backend
...
dependencies:
- name: message-queue
condition: message-queue.enabled
- name: database
condition: database.enabled

• values.yaml

最后，你可以使用以下 values.yaml 文件設置或覆蓋父圖表中子圖表的值： 

message-queue:
enabled: true
image:
repository: acme/rabbitmq
tag: latest
database:
enabled: false

創建和使用子圖表在父應用程序和依賴程序之間建立了一個抽象層。這些單獨的圖表使Kubernetes中的應用程序易于部署、調試和更新，這些應用程序具有各自的值和升級生命周期。你可以在像??bitnami/wordpress??這樣的示例圖表中瀏覽文件夾結構、依賴項和值文件。

3.使用標簽輕松找到資源

標簽對于Kubernetes的內部運營和Kubernetes運營商的日常工作至關重要。Kubernetes中的幾乎每個資源都為不同的目的提供了標簽，例如分組、資源分配、負載平衡或調度。

一個Helm命令將允許你安裝多個資源。但重要的是要知道這些資源的來源。標簽可以讓你快速找到由Helm版本創建的資源。

最常用的方法是在 中定義標簽`helpers.tpl`，如下所示： 

{{/*
Common labels
*/}}
{{- define "common.labels" -}}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

然后你需要在資源模板中使用帶標簽的" include "函數： 

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-queue
labels:
{{ include "labels" . | indent 4 }}
...

現在你應該能夠使用標簽選擇器列出所有資源。例如，您可以使用該`kubectl get pods -l app.kubernetes.io/instance=[Name of the Helm Release]`命令列出 my-queue 部署的所有 pod 。這一步對于定位和調試 Helm 管理的資源至關重要。

4. 記錄你的圖表

文檔對于確保可維護的 Helm 圖表至關重要。在資源模板和 README 中添加注釋可幫助團隊開發和使用 Helm 圖表。

你應該使用以下三個選項來記錄你的圖表：

• 注釋：模板和值文件是 YAML 文件。你可以添加注釋，并提供有關YAML文件中的字段的有用信息。
• README：圖表的README是一個解釋如何使用圖表的標記文件。你可以使用以下命令檢查 README 文件的內容：`helm show readme [Name of the Chart]`
• NOTES.txt：這是一個位于`templates/NOTES.txt` 中的特殊文件，提供有關版本部署的有用信息。`NOTES.txt`文件的內容也可以使用類似于資源模板的函數和值進行模板化：

You have deployed the following release: {{ .Release.Name }}.
To get further information, you can run the commands:
$ helm status {{ .Release.Name }}
$ helm get all {{ .Release.Name }}

在 helm install 或 helm upgrade 命令結束時，Helm 會打印出 NOTES.txt 的內容，如下所示： 

RESOURCES:
==> v1/Secret
NAME TYPE DATA AGE
my-secret Opaque 1 0s

==> v1/ConfigMap
NAME DATA AGE
db-configmap 3 0s

NOTES:
You have deployed the following release: precious-db.
To get further information, you can run the commands:
$ helm status precious-db
$ helm get all precious-db

5. 測試你的 Charts

Helm charts 由多個要部署到集群的資源組成。必須檢查是否在集群中創建的所有資源都具有正確的值。例如，在部署數據庫時，你應該檢查數據庫密碼設置是否正確。

幸運的是，Helm提供了一個測試功能，可以在集群中運行一些容器，以驗證應用程序。例如，注解的資源模板`"helm.sh/hook": test-success`由 Helm 作為測試用例運行。

讓我們假設你正在部署帶有MariaDB數據庫的WordPress。Bitnami維護的Helm圖表有一個pod來驗證數據庫連接，定義如下：

...
apiVersion: v1
kind: Pod
metadata:
name: "{{ .Release.Name }}-credentials-test"
annotations:
"helm.sh/hook": test-success
...
env:
- name: MARIADB\_HOST
value: {{ include "wordpress.databaseHost" . | quote }}
- name: MARIADB\_PORT
value: "3306"
- name: WORDPRESS\_DATABASE\_NAME
value: {{ default "" .Values.mariadb.auth.database | quote }}
- name: WORDPRESS\_DATABASE\_USER
value: {{ default "" .Values.mariadb.auth.username | quote }}
- name: WORDPRESS\_DATABASE\_PASSWORD
valueFrom:
secretKeyRef:
name: {{ include "wordpress.databaseSecretName" . }}
key: mariadb-password
command:
- /bin/bash
- -ec
- |
mysql --host=$MARIADB\_HOST --port=$MARIADB\_PORT --user=$WORDPRESS\_DATABASE\_USER --password=$WORDPRESS\_DATABASE\_PASSWORD
restartPolicy: Never
{{- end }}
...

建議為你的圖表編寫測試并在安裝后運行它們。例如，你可以使用 helm test`<RELEASE_NAME>`命令運行測試。這些測試對于驗證和發現與Helm安裝的應用程序中的問題是很有價值的資產。

6.確保你的秘密安全

敏感數據，如密鑰或密碼，在Kubernetes中作為機密存儲。盡管在Kubernetes方面保護機密是可能的，但它們大多存儲為文本文件，作為Helm模板和值的一部分。

helm-secrets插件為您的關鍵信息提供秘密管理和保護。它將秘密加密委托給Mozilla sop，后者支持AWS KMS、GCP上的Cloud KMS、Azure Key Vault和PGP。

假設你已將敏感數據收集在名為 secrets.yaml 的文件中，如下所示： 

postgresql: postgresqlUsername: postgres postgresqlPassword: WoZpCAlBsg postgresqlDatabase: wp

你可以使用插件加密文件： 

$ helm secrets enc secrets.yamlEncrypting secrets.yamlEncrypted secrets.yaml

現在，文件將被更新并且所有值都將被加密： 

postgresql: postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\] postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\] postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]sops: ...

上面secrets.yaml 中的數據并不安全，helm-secrets 解決了將敏感數據存儲為Helm charts 的一部分問題。

7.使用模板函數使圖表可重用

Helm支持超過60個函數，可以在模板中使用。這些函數在Go模板語言和Sprig模板庫中定義。模板文件中的函數顯著簡化了Helm操作。

讓我們以下面的模板文件為例：

apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
environment: {{ .Values.environment | default "dev" | quote }}
region: {{ .Values.region | upper | quote }}

當沒有提供環境值時，模板函數會默認。當檢查區域字段時，你會看到模板中沒有定義默認值。但是，該字段有另一個名為 upper 的函數，用于將提供的值轉換為大寫。

另一個重要且有用的功能是`required`. 它使您能夠根據模板渲染的需要設置一個值。例如，假設你需要使用以下模板為 ConfigMap 命名： 

...metadata: name: {{ required "Name is required" .Values.configName }}...

如果該條目為空，則模板渲染將失敗并顯示錯誤 Name is required。創建 Helm 圖表時，模板函數非常有用。它們可以改進模板、減少代碼重復，并可用于在將應用程序部署到 Kubernetes 之前驗證值。

8.當 ConfigMaps 或 Secrets 改變時更新你的部署

將 ConfigMaps 或 Secrets 安裝到容器是很常見的。盡管部署和容器映像會隨著新版本而變化，但 ConfigMap 或機密不會經常更改。以下注釋可以在 ConfigMap 更改時推出新部署： 

kind: Deployment
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
...

ConfigMap 中的任何更改都將計算`sha256sum`新的部署版本并創建新版本。這確保部署中的容器將使用新的 ConfigMap 重新啟動。

9. 使用資源策略選擇退出資源刪除

在典型的設置中，安裝 Helm chart 后，Helm 將在集群中創建多個資源。然后，您可以通過更改值以及添加或刪除資源來升級它。一旦您不再需要該應用程序，您可以將其刪除，這會從集群中移除所有資源。

但是，即使在運行 Helm 卸載之后，某些資源也應保留在集群中。假設您已經使用 PersistentVolumeClaim 部署了一個數據庫，并且即使您要刪除數據庫版本也希望存儲卷。對于此類資源，您需要使用資源策略注釋，如下所示： 

kind: Secretmetadata: annotations: "helm.sh/resource-policy": keep...

Helm 命令（例如卸載、升級或回滾）會導致刪除上述機密。但是通過使用如上所示的資源策略，Helm 將跳過秘密的刪除并允許它成為孤立的。因此，應該非常小心地使用注釋，并且僅用于在 Helm Releases 被刪除后所需的資源。

10. 調試 Helm Chart 的有用命令

Helm 模板文件帶有許多不同的功能和用于創建 Kubernetes 資源的多個值來源。了解部署到集群的內容是用戶的基本職責。因此，你需要學習如何調試模板和驗證圖表。有四個基本命令可用于調試：

• helm lint：linter 工具進行一系列測試以確保您的圖表正確形成。
• helm install —dry-run — debug：此函數呈現模板并顯示生成的資源清單。您還可以在部署之前檢查所有資源，并確保設置了值并且模板功能按預期工作。
• helm get manifest：此命令檢索安裝到集群的資源的清單。如果發布未按預期運行，這應該是您用來找出集群中正在運行的內容的第一個命令。
• helm get values：此命令用于檢索安裝到集群的版本值。如果您對計算值或默認值有任何疑問，這絕對應該在您的工具帶中。

11.使用查找功能避免秘密再生

Helm 函數用于生成隨機數據，例如密碼、密鑰和證書。隨機生成會在每次部署和升級時創建新的任意值并更新集群中的資源。例如，它可以在每次版本升級時替換集群中的數據庫密碼。這會導致客戶端在更改密碼后無法連接到數據庫。

為了解決這個問題，建議隨機生成值并覆蓋集群中已有的值。例如： 

{{- $rootPasswordValue := (randAlpha 16) | b64enc | quote }}
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "db-keys") }}
{{- if $secret }}
{{- $rootPasswordValue = index $secret.data "root-password" }}
{{- end -}}
apiVersion: v1
kind: Secret
metadata:
name: db-keys
namespace: {{ .Release.Namespace }}
type: Opaque
data:
root-password: {{ $rootPasswordValue}}

上面的模板首先創建一個 16 個字符的 randAlpha 值，然后檢查集群中的秘密及其對應的字段。如果找到，它會覆蓋并重用 rootPasswordValue 作為 root-password。

12. 遷移到 Helm 3 以獲得更簡單、更安全的 Kubernetes 應用程序

最新的Helm版本Helm 3提供了許多新功能，使其成為一個更輕、更精簡的工具。Helm v3由于其增強的安全性和簡單性而推薦使用。這包括：

• 刪除 Tiller：Tiller 是 Helm 服務器端組件，但由于在早期版本中對集群進行更改所需的詳盡權限已從 v3 中刪除。這也造成了安全風險，因為任何獲得 Tiller 訪問權限的人都會對您的集群擁有過多的權限。
• 改進的圖表升級策略：Helm v2 依賴于雙向策略合并補丁。它將新版本與 ConfigMap 存儲中的版本進行比較并應用更改。相反，Helm v3 比較舊清單、集群中的狀態和新版本。因此，在升級 Helm 版本時，您的手動更改不會丟失。這簡化了升級過程并增強了應用程序的可靠性。

有一個helm-2to3插件，你可以用以下命令安裝： 

$ helm3 plugin install https://github.com/helm/helm-2to3

它是一個小但有用的插件，帶有清理、轉換和移動命令，幫助你遷移和清理v2配置，并創建v3版本。

13. 保持持續交付管道的冪等性

Kubernetes 資源是聲明性的，因為它們的規范和狀態存儲在集群中。同樣，Helm 需要創建聲明性模板和發布。因此，你需要在使用 Helm 時將持續交付和發布管理設計為冪等的。冪等操作是您可以多次應用而不會改變第一次運行后的結果的操作。

有兩個基本規則需要遵循：

• 始終使用該`helm upgrade --install`命令。如果圖表尚未安裝，它會安裝圖表。如果它們已經安裝，它會升級它們。
• 使用`--atomic`標志在 helm 升級期間操作失敗時回滾更改。這確保 Helm 版本不會停留在失敗狀態。

概括

Helm 是將應用程序部署到 Kubernetes 集群不可或缺的工具。但是，只有遵循最佳實踐，您才能真正獲得 Helm 的好處。

本文中介紹的實踐將幫助你和你的團隊創建、操作和升級生產級分布式應用程序。從開發的角度來看，你的 Helm 圖表將更易于維護和保護。在操作方面，你將享受自動更新的部署、從刪除中節省資源，并學習如何測試和調試。

Helm的官方指南是檢查Helm命令和理解其設計理念的另一個很好的資源。有了這些資源以及本文中概述的最佳實踐和示例，就已經準備好創建和管理在Kubernetes上運行的生產級Helm應用程序了。 

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】