13个使用Helm部署应用程序的实践

发布时间：2025-11-05 02:36:45 来源：创站工坊 作者：应用开发

【.com快译】Helm 是个使 Kubernetes 的包管理器。由于其模板方法和可重用和生产就绪包（也称为 Helm charts)）的用H用程丰富生态系统，它减少了部署复杂应用程序的署应实践工作量。有了Helm可以将打包的个使应用程序部署为一组版本化、预配置的用H用程 Kubernetes 资源。

​​

假设你正在使用 Kubernetes 部署一个数据库，署应实践包括多个部署、个使容器、用H用程服务等。署应实践Helm 允许你使用单个命令和一组值安装相同的个使数据库。其声明性和幂等性命令使 Helm 成为持续交付 (CD) 的用H用程理想工具。

随着最新版本的署应实践Helm 3的发布，它与Kubernetes的个使生态系统融合得更加紧密。

本文介绍了创建Helm Chart来管理在Kubernetes中运行的用H用程应用程序的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

你会看到一长串的结果列表，可以看得出Helm图表的生态系统有多大。

2. 使用子图来管理你的依赖

由于部署到Kubernetes的应用程序由细粒度的、相互依赖的部分组成，因此它们的Helm图表具有各种资源模板和依赖项。例如，假设后端依赖于数据库和消息队列。数据库和消息队列已经是独立的应用(如PostgreSQL和RabbitMQ)。因此，建议为独立应用程序创建或使用单独的图表，并将它们添加到父图表中。依赖的应用程序在这里被命名为子图表。

创建和配置子图表有三个基本要素:

文件夹结构的顺序如下：backend-chart

- Chart.yaml

- charts

- message-queue

- Chart.yaml

- templates

- values.yaml

- database

- Chart.yaml

- templates

- values.yaml

另外Chart.yaml在父图表中应该列出任何依赖关系和条件： 

apiVersion: v2

name: backend-chart

description: A Helm chart for backend

...

dependencies:

- name: message-queue

condition: message-queue.enabled

- name: database

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

message-queue:

enabled: true

image:

repository: acme/rabbitmq

tag: latest

database:

创建和使用子图表在父应用程序和依赖程序之间建立了一个抽象层。这些单独的图表使Kubernetes中的应用程序易于部署、调试和更新，这些应用程序具有各自的b2b信息网值和升级生命周期。你可以在像​​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}}

然后你需要在资源模板中使用带标签的" 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 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

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 的文件中，如下所示： 

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

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

上面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}}

当没有提供环境值时，模板函数会默认。当检查区域字段时，你会看到模板中没有定义默认值。但是，该字段有另一个名为 upper 的函数，用于将提供的值转换为大写。

另一个重要且有用的功能是`required`. 它使您能够根据模板渲染的需要设置一个值。例如，假设你需要使用以下模板为 ConfigMap 命名： 

如果该条目为空，则模板渲染将失败并显示错误 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 部署了一个数据库，并且即使您要删除数据库版本也希望存储卷。对于此类资源，您需要使用资源策略注释，如下所示： 

Helm 命令（例如卸载、升级或回滚）会导致删除上述机密。但是通过使用如上所示的资源策略，Helm 将跳过秘密的删除并允许它成为孤立的。因此，应该非常小心地使用注释，并且仅用于在 Helm Releases 被删除后所需的资源。

10. 调试 Helm Chart 的有用命令

Helm 模板文件带有许多不同的功能和用于创建 Kubernetes 资源的多个值来源。了解部署到集群的内容是用户的基本职责。因此，你需要学习如何调试模板和验证图表。有四个基本命令可用于调试：

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:

上面的模板首先创建一个 16 个字符的 randAlpha 值，然后检查集群中的秘密及其对应的字段。如果找到，它会覆盖并重用 rootPasswordValue 作为 root-password。

12. 迁移到 Helm 3 以获得更简单、更安全的 Kubernetes 应用程序

最新的Helm版本Helm 3提供了许多新功能，使其成为一个更轻、更精简的工具。Helm v3由于其增强的安全性和简单性而推荐使用。这包括：

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

它是一个小但有用的插件，带有清理、转换和移动命令，帮助你迁移和清理v2配置，并创建v3版本。

13. 保持持续交付管道的幂等性

Kubernetes 资源是声明性的，因为它们的规范和状态存储在集群中。同样，Helm 需要创建声明性模板和发布。因此，你需要在使用 Helm 时将持续交付和发布管理设计为幂等的。幂等操作是您可以多次应用而不会改变第一次运行后的结果的操作。

有两个基本规则需要遵循：

概括

Helm 是将应用程序部署到 Kubernetes 集群不可或缺的工具。但是，只有遵循最佳实践，您才能真正获得 Helm 的好处。

本文中介绍的实践将帮助你和你的团队创建、操作和升级生产级分布式应用程序。从开发的角度来看，你的 Helm 图表将更易于维护和保护。在操作方面，你将享受自动更新的部署、从删除中节省资源，并学习如何测试和调试。

Helm的官方指南是检查Helm命令和理解其设计理念的另一个很好的资源。有了这些资源以及本文中概述的最佳实践和示例，就已经准备好创建和管理在Kubernetes上运行的生产级Helm应用程序了。 

【译稿，合作站点转载请注明原文译者和出处为.com】

相关文章