由 Devashish Patil 设计

Kubernetes 在管理复杂应用方面非常出色。不过，人类往往难以应对复杂性，我们在 Kubernetes 中部署的应用程序也可能变得非常复杂。

一个典型的应用程序可以包含多个相互关联的组件，让整个系统运行起来。随着系统复杂度的增加，开发、维护和升级这些应用程序会变得越来越棘手。

这里就需要自动化了，像Helm这样的工具就可以帮上忙了，来简化你的工作流程。我们来看看如何在Kubernetes的应用程序部署过程中实现一些自动化操作。

本文将介绍以下内容：

• 什么是Helm？它解决了什么问题？又是如何工作的？
• 如何使用Cloud Build创建一个管道，在GKE中安装Helm图表？

前提条件:

• 基本了解Kubernetes/Google Kubernetes Engine
• CICD管道

上下文设定

我们先来了解一下在 Kubernetes 上使用标准方法部署应用程序的过程。

首先，我们需要了解我们应用或microservice中的所有容器。然后，我们需要理解为了在Kubernetes上运行这些容器，我们需要哪些Kubernetes资源。完成这些步骤后，我们将开始为这些容器创建Kubernetes清单。

让我们通过这个例子来理解一下这个概念。

我们有一个简单的WordPress应用程序，我们希望在Kubernetes上进行部署。一个WordPress应用通常包含这些主要组件：一个Web服务器，一个数据库，以及一个用于存储web应用数据的存储层。

当我们部署此应用程序在 Kubernetes 上时，我们通常需要以下组件有：

• 部署 — 定义在部署文件中的 Web 服务器和 MySQL Pod 规范。
• 服务 — 一个 MySQL 数据库服务，使 WordPress Web 服务器 Pod 能访问它，另一个服务供外部用户访问网站内容。
• 持久卷和声明：一个用于存储数据库表，另一个用于 Web 应用静态内容。
• 一个密钥（Secret） — 用于存储数据库凭据，Web 服务器 Pod 将使用这些凭据访问数据库。

接下来需要为所有这些组件创建清单（manifest）文件。它们看起来与下面图中展示的类似。

您可以在这里查阅K8s上简单的WordPress应用示例清单：链接here。

问题就在这里开始了。对于这些清单文件，您可以使用以下命令来应用它们：

运行以下命令来应用配置文件: kubectl apply -f /path/to/my-清单.yaml

这会让事情变得相当枯燥，特别是如果你的应用程序有很多Kubernetes对象的时候。

这还没完，如果你需要修改、更新应用或回滚，你将需要编辑特定的文件（你得事先知道哪些文件），再重复同样的步骤。再想想删掉所有资源，那可就麻烦大了。

不仅如此，团队协作会变得相当棘手，因为这些文件并没有真正的版本控制，所有这些操作都在你的命令行里，没有版本控制。当然，你可以把它们放到 Git 中，还有大量的手动工作要做。

现在，想象你需要在一个类似的应用或在不同的环境（如prod，test等）下创建一个类似的应用，你将不得不从头开始做同样的事情，就像上面一样。

这就到了 Helm 出场的时候了。

Helm 是怎么解决这个问题的？

Helm 在 Kubernetes 中不仅担任软件包管理的角色，还负责 Kubernetes 的版本管理。

Helm 帮助你管理 Kubernetes 应用程序，甚至是那些最复杂的。它从头开始构建，旨在理解这些应用。它使用 Helm 图表（Charts）来定义、安装和升级这些应用。

我会用一个类比来解释这个。假设你想要在电脑上安装一个视频游戏。视频游戏通常包含成千上万个文件，形式包括图像、音频、音乐、可执行代码等。所有这些文件都必须被放置在电脑内的特定位置，才能运行游戏。

想象一下，如果必须一个一个下载这些文件并放到各自的位置。这将是一场噩梦。但是，幸运的是，我们不需要这么麻烦。我们有游戏安装程序来处理这些。我们只需要指定想要安装游戏的位置，安装程序就会自动搞定剩下的。

Helm 对于你想在 Kubernetes 上运行的应用程序也采取了同样的操作。就像你在 Linux 上使用 apt 或 yum 安装应用程序，用 Pip 安装 Python 库，用 npm 安装 Node.js 包一样，Helm 也是专门用于 Kubernetes 的工具，同样适用于 Kubernetes。

但是这一切又是如何运作的呢？首先，让我们先来了解一下Helm的基本概念。

Helm 相关概念：

图表
一个 Helm 图包含了部署一个 Kubernetes 应用所需的所有信息。

图表包含该文件夹中的清单文件（manifest文件），有关图表自身的元数据，以及如果有任何依赖关系的话，对其他图表的依赖关系。

配置信息
它包含了可以配置的信息，并与打包图表一起使用以生成可发布的图表。

values.yaml 文件一般包含可以在一处进行配置的信息。可以使用多个值文件来为不同的环境创建不同的配置。

发布
当图表与配置一起运行时，这个正在运行的实例就叫做发布。

当你在 Kubernetes 集群中安装一个 Helm 图表时，可以将其称为一个 release。这个 release 在安装时会分配一个版本号，每次升级或回滚时，版本号都会更新。

Helm快速入门

首先，在您的计算机上先安装helm。要从头开始创建一个新的helm图表，请在命令行中运行该命令。

运行命令：helm create hello-world (这将创建一个名为hello-world的应用程序)

这将创建一个名为 hello-world 的文件夹，并为你生成一些初始代码，供你开始编辑。进入该文件夹，你会看到如下结构：

你可以在这里详细了解这些文件 这里。

这里的其中一个重要的文件夹是 templates/。如果你是从头开始编写清单文件，你可以直接编辑 YAML 文件；或者如果你已经有了这些清单文件，只需移除这个文件夹中除 _helpers.tpl 之外的所有文件，并将你的文件放进去。

然后你可以编辑 YAML 文件，用 Go 模板替换可配置的部分，并将这些内容放入 values.yaml 文件中。

例子：

通常，当你为一个容器指定一个镜像时，通常这样做，比如：

---
spec:
  containers:
- image: docker.io/hello-world:1.2.3
  name: hello-world
---

但是，你可以将硬编码的图片名称和标签替换为可配置的值，例如：image_name=configurable_value 和 tag=configurable_value。

---
spec:  
  containers:  
  - image: "**{{ .Values.image.repo }}:{{ .Values.image.tag }}**"  
    name: "**{{ .Release.Name }}**"
---

在 values.yaml 文件中放入默认值，如下所示：

    image:  
      repo: docker.io/hello-world (仓库地址)  
      tag: 1.2.3 (标签版本)

这是一个使用Helm进行模板化的非常基础的例子。你可以做很多其他的事情，让您的清单文件变得更模块化且易于重用。

您可以使用以下命令在此Kubernetes集群中安装此部署图表，在完成清单文件后。

    $ helm install hello-world /path/to/hello-world

安装名为hello-world的应用程序

如果你想在特定的命名空间里安装，只需在上述命令后面加上 --namespace <name>。

你可以用这个命令列出你安装的所有 Helm 应用：

helm list

$ helm list --namespace <name>

运行以下命令列出指定命名空间下的 Helm 释放:

$ helm list --namespace <name>

现在，假设你的应用程序正在扩大规模，你需要给你的 pod 添加更多的 CPU。所以，你可以更新你的 pod 的 CPU 请求。首先，你可以通过将 CPU 和内存请求放入 values.yaml 文件来使它们可配置。然后，你可以把这些更改应用到你的实时应用中，你只需要运行这个命令即可。

$ helm 更新 hello-world /path/to/hello-world --namespace <namespace>

这将为你创建一个新的发布修订版本。现在假设你在发布升级时，在发布之后，你发现最新版本存在问题，并且你想回滚到某个特定的旧版本。你可以按照以下方法操作：

$ helm rollback hello-world <版本号> --namespace <命名空间> # <命名空间> 是 Helm 发布所在的命名空间

最后，如果你不想再保留你的应用程序，你可以用这个命令删除全部：

$ helm uninstall hello-world --namespace <name>
# 请将<name>替换为实际的命名空间名称
# 请确保你已经替换为正确的命名空间名称

这样您可以访问 artifacthub.io 查找许多预构建的 Helm 图，适合大多数常见应用，并可以直接从那里安装，如果您不想从零开始构建所有内容。

这将是一个很好的起点，帮助你开始使用Helm。它将帮助你减少许多重复的任务，让你能够专心于应用程序本身。

云构建

现在，你在上一节中使用的所有命令仍然需要你在命令行中执行。进一步的自动化可以通过使用GCP中的Cloud Build来实现，这将消除对命令行的依赖，你每次更新GIT仓库中的图表后，所有内容将自动同步。我们将使用Cloud Build来创建一个持续集成和持续部署（CI/CD）工作流，以确保这一过程。

比如CICD，有许多可用的工具。比如 Jenkins、GitLab CI、Spinnaker 等等，还有各大云服务商提供的工具。

本教程中，我们将专注于 Cloud Build ，这是 Google 云平台上的一个 CICD 工具。Cloud Build 可以轻松整合许多 GCP 服务，并且设置和配置都非常简单。

CD流程将会是这样的：

以下是我们准备CD管道所需的步骤：

• 有一个Git仓库来存储Helm图表
• 构建一个Helm Cloud Builder
• 创建一个Cloud Build触发器
• 配置管道

新建一个 Git 仓库

第一步是创建一个在GCP中的云源代码仓库，我们将在此仓库中存放Helm图表。你也可以使用其他版本控制系统，例如GitHub或Bitbucket。将图表目录提交到该仓库。

搭建一个云构建平台

装有语言和工具的构建镜像是指在 cloudbuild.yaml 文件中可以指定的容器镜像。

要使用任何自定义命令或工具，比如我们例子中的 helm，我们需要 Helm 构建器。

你可以访问这个链接 this link 查看受支持的构建器列表、社区提供的构建器以及如何创建你自己的构建器。

在您可以在管道中使用它之前，您需要在自己的GCP环境中构建Helm构建器。为此，您需要从具有gcloud访问权限的命令行下载并克隆此Git仓库，在该目录中打开一个终端窗口，然后运行相应的命令。

在终端中运行以下命令：

gcloud builds submit . --config=cloudbuild.yaml

完成之后，您将在容器注册表的 gcr.io/<**PROJECT_ID**>/helm 查看构建器的图像。这样您就可以在 Cloud Build 的构建管道中使用该构建器了。

注意：这里我们使用 gcr.io 作为容器镜像仓库（如 gcr.io），你也可以选择其他仓库，比如 docker.io 等等

创建触发器

现在，我们将在这个仓库中创建一个云构建触发器。这就是指定详细信息的一个例子。

确保将服务账号添加到云构建触发器中，这个账号需要具备 Kubernetes Engine Developer 访问权限。

配置 Cloud Build 管道

现在回到你之前创建的那个 Helm Chart 仓库。首先，我们在该仓库的 main 分支上创建了一个触发器，并指定了 cloudbuild.yaml 文件作为构建管道的配置文件。但我们还没创建这个文件，现在就来做。

在你的仓库根目录创建一个名为 cloudbuild.yaml 的文件。将以下内容添加到文件，并提交。

步骤：- 名称: 'gcr.io/$PROJECT_ID/helm'  参数: ['upgrade', '--install', 'hello-world-app', './hello-world', '--namespace', '**helloworldns**', '--create-namespace']  

环境变量:  
- 'CLOUDSDK_COMPUTE_ZONE=**< your-gcp-zone>**'  
- 'CLOUDSDK_CONTAINER_CLUSTER=**< your-cluster-name>**'

注意：确保helm构建器镜像在gcr.io/$PROJECT_ID/helm里

在这里你就完成了任务，一推送这个更改，部署就会开始。这个简化的流程会自动安装或升级你的图表，你只需要管好你的git仓库。

接下来学什么呢？

• 您可以在 Google Cloud 上查找与基于 Kubernetes 的应用程序相关的常见 CICD 模式。本文只是整个拼图中的一块。通常，很多人在容器化应用程序的情况下采取将 CI 和 CD 管道分开的方法。
  应用程序代码一个仓库，CI 管道用于构建和测试容器镜像。另一个仓库用于像我们在此处所见的用于 CD 的仓库。

• 其次，您可以了解 GitOps 风格 的管道。例如，您可以查看 Config Sync，这是 Google Cloud 自己的 GitOps 工具。
  这些资源将向您展示如何在 GKE 集群中实现 GitOps 的完整流程：

1. 使用 OCI 资源和 Config Sync 的 GitOps

2. 使用 Helm、GitHub Actions、Artifact Registry 和 Config Sync 的 CI 和 GitOps

3. 使用 Helm、GitHub Actions、GitHub Container Registry 和 Config Sync 的 CI 和 GitOps

4. 使用 ArgoCD

• 您还可以学习 Helm 的替代工具。例如 [kustomize](https://kustomize.io/)，它以类似的方式工作，但我建议您自行探索。

参考资料

• Helm - 一个用于管理和部署Kubernetes应用的工具.
• 云构建服务
• K8s - 一个用于自动化部署、扩展和管理容器化应用的开源平台.
• 工件中心 - 一个用于发现、分享和使用Kubernetes资源的中心平台.