19、使用 CI/CD 和 GitOps 自动化 Helm 流程及创建 Helm 操作符

CI/CD与GitOps自动化Helm流程

最新推荐文章于 2025-10-05 01:10:06 发布

raspberrypi5

最新推荐文章于 2025-10-05 01:10:06 发布

阅读量30

点赞数

CC 4.0 BY-SA版权

分类专栏： Helm实战：云原生部署精要文章标签： CI/CD GitOps Helm

本文链接：https://blog.youkuaiyun.com/raspberrypi5/article/details/152499880

Helm实战：云原生部署精要专栏收录该内容

23 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

使用 CI/CD 和 GitOps 自动化 Helm 流程及创建 Helm 操作符

1. 使用 Helm 构建 CD 管道

1.1 管道的等待输入阶段

在 CD 管道中，有一个名为 Wait for Input 的阶段，代码如下：

stage('Wait for Input') {
    when {
        expression {
            return env.BRANCH_NAME == 'master'
        }
    }
    steps {
        container('chart-testing') {
            input 'Deploy to Prod?'
        }
    }
}

这个输入步骤会暂停 Jenkins 管道，并提示用户是否要部署到生产环境。用户在运行作业的控制台日志中有两个选择： Proceed （继续）和 Abort （中止）。虽然生产部署可以自动执行，但许多开发者和公司倾向于在非生产和生产部署之间设置人工干预。这个输入命令让用户可以决定是否继续部署或在 QA 阶段后中止管道。

1.2 部署到生产环境阶段

如果用户选择继续，将执行最后一个阶段 Deploy to Prod ：

dir('nginx-cd') {
    sh "helm upgrade --install nginx-${env.BRANCH_NAME} learnhelm/nginx --values common-values.yaml --values prod/values.yaml -n prod --wait"
}

这个阶段与 Deploy to Dev 和 Deploy to QA 阶段几乎相同，只是使用了特定于生产环境的 values.yaml 文件，并在 helm upgrade --install 命令中指定了 prod 命名空间。

1.3 运行管道

要查看这个 CD 管道的实际运行情况，可按以下步骤操作：
1. 导航到 Deploy NGINX Chart 作业的 master 分支。在 Jenkins 首页，点击 Deploy NGINX Chart 和 master 。
2. 点击 #1 链接并导航到控制台日志。

在日志中，首先会看到开发环境的部署：

+ helm upgrade --install nginx-master learnhelm/nginx --values common-values.yaml --values dev/values.yaml -n dev --wait
Release 'nginx-master' does not exist. Installing it now.
NAME: nginx-master
LAST DEPLOYED: Thu Apr 30 02:07:55 2020
NAMESPACE: dev
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
    export NODE_PORT=$(kubectl get --namespace dev -o jsonpath='{.spec.ports[0].nodePort}' services nginx-master)
    export NODE_IP=$(kubectl get nodes --namespace dev -o jsonpath='{.items[0].status.addresses[0].address}')
    echo http://$NODE_IP:$NODE_PORT

接着是冒烟测试：

+ helm test nginx-master -n dev
Pod nginx-master-test-connection pending
Pod nginx-master-test-connection pending
Pod nginx-master-test-connection succeeded
NAME: nginx-master
LAST DEPLOYED: Thu Apr 30 02:07:55 2020
NAMESPACE: dev
STATUS: deployed
REVISION: 1
TEST SUITE:     nginx-master-test-connection
Last Started:   Thu Apr 30 02:08:03 2020
Last Completed: Thu Apr 30 02:08:05 2020
Phase:          Succeeded

然后是 QA 环境的部署：

+ helm upgrade --install nginx-master learnhelm/nginx --values common-values.yaml --values qa/values.yaml -n qa --wait
Release 'nginx-master' does not exist. Installing it now.
NAME: nginx-master
LAST DEPLOYED: Thu Apr 30 02:08:09 2020
NAMESPACE: qa
STATUS: deployed
REVISION: 1

之后会看到输入阶段的提示，点击 Proceed 继续管道执行，将看到生产环境的部署：

+ helm upgrade --install nginx-master learnhelm/nginx --values common-values.yaml --values prod/values.yaml -n prod --wait
Release 'nginx-master' does not exist. Installing it now.
NAME: nginx-master
LAST DEPLOYED: Thu Apr 30 03:46:22 2020
NAMESPACE: prod
STATUS: deployed
REVISION: 1

如果生产部署成功，管道末尾会显示以下消息：

[Pipeline] End of Pipeline
Finished: SUCCESS

1.4 验证部署

可以从命令行手动验证部署是否成功。运行以下命令查找 nginx-master 版本：

$ helm list -n dev
$ helm list -n qa
$ helm list -n prod

每个命令应列出每个命名空间中的 NGINX 版本，示例如下：
| NAME | NAMESPACE | REVISION |
| ------------ | --------- | -------- |
| nginx-master | dev | 1 |

也可以使用 kubectl 列出每个命名空间中的 Pod 并验证 NGINX 是否已部署：

$ kubectl get Pods -n dev
$ kubectl get Pods -n qa
$ kubectl get Pods -n prod

每个命名空间的结果将类似于以下内容（开发环境还会有一个在冒烟测试阶段完成的测试 Pod）：
| NAME | READY | STATUS | RESTARTS | AGE |
| ------------------------- | ----- | ------- | -------- | ---- |
| nginx-fcb5d6b64-rmc2j | 1/1 | Running | 0 | 46m |

1.5 清理环境

要清理 Minikube 集群中的相关资源，可删除 chapter7 、 dev 、 qa 和 prod 命名空间：

$ kubectl delete ns chapter7
$ kubectl delete ns dev
$ kubectl delete ns qa
$ kubectl delete ns prod

还可以关闭 Minikube VM：

$ minikube stop

1.6 总结

在 CI 和 CD 管道中调用 Helm CLI 是进一步抽象 Helm 功能的有效方法。图表开发者可以通过编写 CI 管道来自动化端到端的图表开发过程，包括检查、测试、打包和发布图表到图表仓库。最终用户可以编写 CD 管道，使用 Helm 在多个不同环境中部署图表，利用 GitOps 确保应用程序可以作为代码进行部署和配置。编写管道有助于开发者和公司更快、更轻松地扩展应用程序，通过抽象和自动化原本繁琐且容易引入人为错误的流程。

以下是 CD 管道的 mermaid 流程图：

graph LR
    A[开始] --> B[开发环境部署]
    B --> C[冒烟测试]
    C --> D[QA 环境部署]
    D --> E{是否继续到生产环境?}
    E -- 是 --> F[生产环境部署]
    E -- 否 --> G[结束]
    F --> H[验证部署]
    H --> I[清理环境]
    I --> J[结束]

2. 使用 Helm 与操作符框架

2.1 技术要求

使用 Helm 与操作符框架，需要在本地机器上安装以下技术：
- minikube
- helm
- kubectl

此外，还需要在 GitHub 上找到包含示例资源的仓库：https://github.com/PacktPublishing/-Learn-Helm 。

2.2 理解 Kubernetes 操作符

Kubernetes 平台的核心是自动化。Kubernetes 资源可以通过运行 kubectl 命令隐式管理，也可以通过应用 YAML 格式的表示来声明式管理。使用 Kubernetes CLI 应用资源后，Kubernetes 的一个基本原则是将集群中资源的当前状态与期望状态相匹配，这个过程称为控制循环。通过使用控制器实现对集群状态的持续监控。Kubernetes 包含许多原生控制器，例如拦截对 Kubernetes API 请求的准入控制器和管理运行的 Pod 副本数量的复制控制器。

随着对 Kubernetes 的兴趣增长，出现了两个重要趋势：
1. 自定义资源定义（CRDs） ：允许用户扩展默认的 Kubernetes API，创建和注册新类型的资源。注册新的 CRD 会在 Kubernetes API 服务器上创建一个新的 RESTful 资源路径。例如，注册一个名为 Guestbook 的对象类型的 CRD 后，就可以使用 kubectl get guestbook 查看所有已创建的 Guestbook 对象。开发者可以创建自己的控制器来监控这些自定义资源（CRs），以管理可以通过 CRD 描述的应用程序的生命周期。
2. 复杂应用的部署 ：越来越多的复杂和有状态应用被部署到 Kubernetes 上。这些高级应用通常需要更高级的管理和维护，例如处理多个组件的部署，以及考虑备份和恢复等“第二天”活动。这些任务超出了 Kubernetes 中典型控制器的范围，需要嵌入与管理的应用程序相关的深入知识。这种使用 CR 管理应用程序及其组件的模式称为操作符模式。操作符最早由软件公司 CoreOS 在 2016 年提出，旨在捕获人类操作员管理应用程序生命周期所需的知识。操作符通常作为普通的容器化应用程序打包，部署在 Pod 中，对 CRs 的 API 更改做出反应。

操作符通常使用名为操作符框架的工具包编写，基于以下三种不同技术之一：
- Go ：基于 Go 编程语言实现控制循环逻辑。
- Ansible ：利用 Ansible CLI 工具和 Ansible 剧本，Ansible 是一种自动化工具，其逻辑写在名为剧本的 YAML 文件中。
- Helm ：基于 Helm 图表和 Helm CLI 的部分功能实现控制循环逻辑，为 Helm 用户提供了一种简单的实现操作符的方式。

2.3 创建 Helm 操作符

我们将编写一个基于 Helm 的操作符，用于安装之前创建的 Guestbook Helm 图表。该图表位于 GitHub 仓库的 guestbook/ 文件夹中。

2.3.1 Guestbook 操作符工作流程

Guestbook 操作符将持续监控 Guestbook CRs 的更改。当创建 Guestbook CR 时，操作符将安装 Guestbook 图表；当删除 Guestbook CR 时，操作符将移除 Guestbook Helm 图表。

2.3.2 设置环境

启动 Minikube 环境 ：

$ minikube start

创建命名空间 ：

$ kubectl create ns chapter8

创建 Quay 仓库 ：
- 访问 https://quay.io/signin/ 创建 Quay 账户。
- 点击页面底部的 Create Account 链接，按照提示创建新账户。
- 输入所需的凭据，选择 Create Free Account 。
- 点击确认邮件中的链接验证账户。
- 登录 Quay 后，点击页面右上角的 + 图标，选择 New Repository 。
- 在 Create New Repository 页面， Repository Name 输入 guestbook-operator ，选择 Public 单选按钮，其他选项保持默认值。
- 点击 Create Public Repository 按钮创建仓库。

2.3.3 准备本地开发环境

创建 Helm 操作符至少需要以下 CLI 工具：
- operator-sdk
- docker 、 podman 或 buildah

operator-sdk 是用于开发 Kubernetes 操作符的工具包，它需要一个容器管理工具来构建操作符镜像，支持 docker 、 podman 和 buildah 。

要在 Minikube VM 上安装 operator-sdk ，可按以下步骤操作：
1. 进入 Minikube VM：

$ minikube ssh

在 VM 内下载 operator-sdk CLI：可使用 curl 命令，编写本文时使用的 operator-sdk 版本是 0.15.2。

以下是创建 Helm 操作符的步骤列表：
1. 启动 Minikube 环境。
2. 创建命名空间。
3. 创建 Quay 仓库。
4. 准备本地开发环境，安装必要的工具。
5. 在 Minikube VM 上安装 operator-sdk 。

以下是创建 Helm 操作符的 mermaid 流程图：

graph LR
    A[开始] --> B[启动 Minikube]
    B --> C[创建命名空间]
    C --> D[创建 Quay 仓库]
    D --> E[准备本地开发环境]
    E --> F[安装 operator-sdk]
    F --> G[结束]

2.4 深入探究 Helm 操作符的优势与应用场景

2.4.1 Helm 操作符的优势

Helm 操作符基于 Helm 图表和 Helm CLI 的部分功能，为用户带来了诸多优势：
- 简化部署 ：利用 Helm 图表的模板化功能，操作符可以轻松地将应用程序部署到 Kubernetes 集群中。通过定义好的 values 文件，可以灵活配置应用的各种参数，减少手动配置的复杂性。
- 自动化管理 ：操作符能够持续监控自定义资源（CRs）的状态，并根据需要自动执行 Helm 命令来更新应用程序。这大大减少了人工干预，提高了应用的稳定性和可靠性。
- 易于集成 ：对于已经熟悉 Helm 的用户来说，使用 Helm 操作符可以无缝集成到现有的工作流程中。无需学习新的复杂技术，就可以实现应用的自动化管理。

2.4.2 Helm 操作符的应用场景

2.5 对比不同类型的操作符

2.6 总结与展望

通过使用 CI/CD 和 GitOps 自动化 Helm 流程，以及创建 Helm 操作符，我们可以实现应用程序在 Kubernetes 集群中的高效部署和管理。CI/CD 管道帮助我们将应用的开发、测试和部署过程自动化，减少了人工错误和部署时间。而 Helm 操作符则进一步提升了应用的自动化管理水平，确保应用的状态始终与期望状态一致。

在未来，随着 Kubernetes 和 Helm 的不断发展，我们可以期待更多的自动化工具和技术出现。例如，可能会有更智能的操作符能够自动优化应用的资源配置，根据集群的负载情况动态调整应用的副本数量。同时，与其他云原生技术的集成也将更加紧密，为开发者提供更便捷的开发和运维体验。

以下是一个综合的 mermaid 流程图，展示了从 CI/CD 到 Helm 操作符的整个流程：

graph LR
    A[代码变更] --> B[CI 管道]
    B --> C[代码检查与测试]
    C --> D[Helm 打包]
    D --> E[CD 管道]
    E --> F{是否部署到生产?}
    F -- 是 --> G[生产环境部署]
    F -- 否 --> H[测试环境部署]
    G --> I[Helm 操作符监控]
    H --> I
    I --> J{状态是否一致?}
    J -- 是 --> K[维持现状]
    J -- 否 --> L[Helm 操作符更新]
    L --> I

总之，掌握 Helm 的自动化流程和操作符技术，将为我们在云原生应用开发和运维中带来巨大的优势，帮助我们更高效地构建和管理应用程序。