14、配置管理工具：Helm、Kustomize与KubeVela实践

配置管理工具：Helm、Kustomize与KubeVela实践

1. Helm 发布管理命令

Helm 提供了一系列实用的发布管理命令，以下是一些常见命令及其示例：
- 升级发布 ：

helm upgrade redis bitnami/redis -f values.yaml --set auth.enabled=true

• 回滚发布 ：

# 格式
helm rollback <release-name> <release>
# 示例，将 redis 回滚到第一个版本
helm rollback redis 1

• 卸载发布 ：

# 格式
helm uninstall <release-name>
# 示例，卸载 redis 发布
helm uninstall redis

• 集群发现命令 ：

# 列出目标集群中的所有 Helm 发布
helm list
# 查看名为 redis 的发布状态
helm status redis

2. 动手开发 Helm Chart

2.1 Chart 生成

Helm Chart 是一组带有变量占位符的配置模板。可以使用 helm create <chart-name> 命令生成一个 Chart，例如创建名为 hello-world 的 Chart：

helm create hello-world

生成的 Chart 包含以下重要文件和文件夹：
| 文件/文件夹 | 说明 |
| ---- | ---- |
| Chart.yaml | 存储 Chart 的描述信息，如支持的 Helm 版本、Chart 版本、应用版本、应用名称等，还有 type 属性，值可以是 application 或 library 。 |
| charts 文件夹 | 可存放依赖的子 Chart，子 Chart 可独立部署，父 Chart 可在需要时覆盖子 Chart 模板的值。 |
| values.yaml | YAML 文件，存储模板渲染时需要替换的值，可通过 CLI 用新文件覆盖，也可用 --set 标志覆盖特定值。 |
| templates 文件夹 | 包含 NOTES.txt （ helm install 或 helm upgrade 时会渲染并打印到控制台）、 _helpers.tpl （存储可在 Chart 中复用的函数）和 Kubernetes 资源 YAML 模板。 |
| tests 文件夹 | 可存放单元测试，用于测试资源模板中的逻辑。 |

2.2 变量访问

模板渲染时，可通过指定变量层次结构来替换占位符变量，语法为 {{ variable-hierarchy }} ，示例如下：

# 引用 deployment.yaml 第 9 行
{{ .Values.replicaCount }}
# 引用 _helpers.tpl 第 50 行
{{ .Release.Name }}

重要的内置根对象有：
- Release ：包含发布相关信息，如发布名称、命名空间、版本号等。
- Values ：由 values 文件或命令行 --set 标志形成的对象。
- Chart ： chart.yaml 文件中定义的值。

还可参考 Helm 官方文档 获取完整列表。

2.3 函数和管道

可使用内置函数和管道对变量进行转换后替换，例如：

# 引用 _helpers.tpl 第 40 行
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}

常见函数如下：
| 函数 | 说明 |
| ---- | ---- |
| indent | 用于格式化配置 YAML，接受一个数字输入，按指定索引缩进行。 |
| nindent | 类似 indent 函数，开头会添加一个换行符。 |
| trunc | 按指定索引截断字符串。 |
| trimSuffix | 接受一个字符串后缀作为输入，若操作字符串中存在该后缀则截断。 |
| replace | 用一个子字符串替换操作字符串中的另一个子字符串。 |
| semverCompare | 用于比较两个语义版本。 |

更多函数可参考 Helm 官方文档 。

2.4 流程控制

Helm 模板语言提供三种流程控制：
- if/else 语句 ：根据特定条件包含一个代码块，示例如下：

# 引用 ingress.yaml 第 9 行
{{- if semverCompare ">=1.19-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1
{{- else if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}

• with 语句 ：创建一个具有特定变量作用域的代码块，示例如下：

# 引用 serviceaccount.yaml 第 8 行
{{- with .Values.serviceAccount.annotations }}
annotations:
  {{- toYaml . | nindent 4 }}
{{- end }}

• range 语句 ：用于循环，示例如下：

# 引用 NOTES.txt 第 2 行
{{- range $host := .Values.ingress.hosts }}
  {{- range .paths }}
  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ $host.host }}{{ .path }}
  {{- end }}
{{- end }}

2.5 命名模板

命名模板可作为静态自定义函数，通常在 _helpers.tpl 文件中定义并在 Chart 中复用，示例如下：

# 在 _helpers.tps 第 45 行定义名为 hello-world.selectorLabels 的模板
{{- define "hello-world.selectorLabels" -}}
app.kubernetes.io/name: {{ include "hello-world.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}
# 在 deployment.yaml 第 12 行引用该模板
matchLabels:
  {{- include "hello-world.selectorLabels" . | nindent 6 }}

修改 values.yaml 文件中的镜像名称为 hello-world 后，即可部署该 Chart。

3. 使用 Kustomize 定制配置

3.1 Kustomize 的使用场景

Kustomize 是一个强大的配置定制工具，适用于以下场景：
- 分离环境特定定制 ：如在测试环境设置复制计数，在生产环境启用自动缩放。
- 管理横切配置 ：如应用操作员为所有部署添加治理特定标签，或注入服务网格配置。
- 修复漏洞 ：在配置管道中添加定制步骤，确保所有部署更新有安全漏洞的镜像版本。
- 避免抽象泄漏 ：在多个相似工作负载中复用基础配置模板时使用。

3.2 Kustomize 示例

使用 Kustomize 需要有基础配置和 kustomization.yaml 文件，以下是一个示例 kustomization.yaml 文件：

resources:
- deployment.yaml
commonLabels:
    team-name: alpha
namespace: test

上述配置引用了基础配置 deployment.yaml ，并定义了定制方式：添加 team-name 标签，覆盖部署资源的命名空间。可使用以下命令执行定制：

kubectl kustomize .

helm install 可通过指定 kustomization.yaml 的路径将 Kustomize 作为后渲染步骤，语法如下：

helm install <release-name> <chart-name> --post-renderer ./path/to/executable

更多 Kustomize 定制选项可参考 Kustomize 官方文档 。

4. 使用 KubeVela 部署应用工作负载

4.1 安装 KubeVela

KubeVela 的安装分两步：
- 安装 KubeVela CLI ：
- macOS（使用 Homebrew） ：

brew update
brew install kubevela

- **macOS（使用脚本）**：

curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.0

- **Windows（使用脚本）**：

powershell -Command "iwr -useb https://kubevela.io/script/install.ps1 | iex"

• 安装 KubeVela 到 Kubernetes 集群 ：
  • 使用 CLI ：

vela install

- **使用 Helm Chart**：

helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.0 --wait

4.2 启用附加组件

可启用附加组件增强 KubeVela 的功能，例如：

# 查看可用附加组件列表
vela add-on list
# 安装应用管理仪表盘附加组件
vela add-on enable velaux

4.3 KubeVela 应用定义剖析

KubeVela 应用规范包含四个关键部分：
| 部分 | 说明 |
| ---- | ---- |
| Components | 表示要部署的 Kubernetes 工作负载或外部现成依赖，如 Helm Chart、Kustomize 包、Deployment、Job、Terraform 模块、CloudFormation 模板或 Crossplane 复合资源（XR）/声明。 |
| Traits | 声明性操作行为，如应用推出行为、自动缩放规则、路由规则等，可附加到组件上。 |
| Policies | 要强制执行的一组规则，如 Pod 安全策略和健康检查配置。 |
| Workflow | 控制组件交付过程，如审批步骤和特定环境的 Traits。 |

可使用以下命令查看集群支持的组件、Traits、策略和工作流列表：

# 组件列表
kubectl get ComponentDefinition -n vela-system
# Traits 列表
kubectl get TraitDefinition -n vela-system
# 策略列表
kubectl get PolicyDefinition -n vela-system
# 工作流列表
kubectl get WorkflowStepDefinition -n vela-system

应用 YAML 文件后， hello-world 应用将成功运行。KubeVela 社区基于开放应用模型（OAM）规范开发了许多组件、Traits、策略和工作流，可参考 KubeVela 官方文档 深入了解。如有自定义需求，可创建和注册新的 CRDs。

5. 使用 Crossplane 接入应用

接下来将进行一个完整的实践，使用 Crossplane 实现应用及其所有依赖的端到端自动化，包括项目仓库设置、CI/CD 管道创建、依赖的基础设施资源等。从平台开发者、应用操作员和开发者三个不同角色的角度进行实践，其中平台开发者角色是关键。实践将涵盖应用、服务和基础设施三个方面的自动化。

5. 使用 Crossplane 接入应用

5.1 端到端自动化概述

使用 Crossplane 实现应用及其所有依赖的端到端自动化，是一个涉及多方面的复杂过程。这个过程的依赖包括项目仓库的搭建、持续集成和持续部署（CI/CD）管道的创建，以及依赖的基础设施资源的配置等。接下来将从平台开发者、应用操作员和开发者这三个不同角色的视角，详细阐述整个实践过程。

5.2 不同角色的职责与操作

5.2.1 平台开发者

平台开发者在整个过程中起着核心作用，他们的主要任务是创建所需的 XR/claim API。以下是具体的操作步骤：
1. 理解需求 ：深入了解应用及其依赖的基础设施的需求，确定需要创建的 XR/claim API 的类型和功能。
2. 设计 API ：根据需求设计 XR/claim API 的结构和接口，确保其能够准确地描述和管理应用的资源。
3. 实现 API ：使用 Crossplane 提供的框架和工具，实现设计好的 XR/claim API。
4. 测试和验证 ：对创建的 API 进行测试和验证，确保其能够正常工作并满足应用的需求。

5.2.2 应用操作员

应用操作员负责使用 XR/claim 来配置应用的部署。具体操作如下：
1. 获取 API ：从平台开发者处获取创建好的 XR/claim API。
2. 配置应用 ：根据 API 的文档和说明，使用 XR/claim 来配置应用的部署参数，如资源数量、环境变量等。
3. 部署应用 ：将配置好的应用部署到 Kubernetes 集群中。
4. 监控和管理 ：监控应用的运行状态，根据需要进行调整和管理。

5.2.3 开发者

开发者主要负责应用的开发工作。在这个过程中，他们需要与平台开发者和应用操作员密切合作。具体操作如下：
1. 开发应用 ：按照项目的需求和规范，开发应用的代码。
2. 集成 API ：将平台开发者创建的 XR/claim API 集成到应用中，以便应用能够使用这些 API 来管理资源。
3. 测试和调试 ：对集成了 API 的应用进行测试和调试，确保其能够正常工作。
4. 提交代码 ：将开发好的代码提交到项目仓库中，以便进行 CI/CD 流程。

5.3 实践的三个方面

整个实践过程将涵盖应用、服务和基础设施三个方面的自动化：
| 方面 | 说明 |
| ---- | ---- |
| 应用 | 实现应用代码的开发、部署和管理的自动化，确保应用能够快速、稳定地运行。 |
| 服务 | 自动化配置和管理应用所需的各种服务，如数据库、缓存等，保证服务的可用性和性能。 |
| 基础设施 | 自动化创建和管理应用依赖的基础设施资源，如虚拟机、存储等，提高资源的利用率和管理效率。 |

5.4 总结

通过使用 Crossplane 实现应用及其依赖的端到端自动化，能够大大提高开发和运维的效率，降低成本。不同角色在这个过程中各司其职，密切合作，共同完成应用的自动化部署和管理。在实际应用中，需要根据具体的需求和场景，灵活运用 Crossplane 的功能和工具，不断优化和改进自动化流程。

6. 总结与展望

6.1 总结

本文介绍了 Helm、Kustomize、KubeVela 和 Crossplane 等配置管理工具在应用开发和部署中的应用。Helm 提供了强大的 Chart 开发和发布管理功能，通过变量访问、函数和管道、流程控制和命名模板等特性，能够方便地创建和部署自定义的应用。Kustomize 则专注于配置的定制，能够根据不同的环境和需求对基础配置进行灵活的修改。KubeVela 是一个专注于定制应用工作负载的项目，通过组件、Traits、策略和工作流等概念，能够实现应用的高效部署和管理。Crossplane 则实现了应用及其依赖的端到端自动化，从项目仓库的设置到基础设施的管理，都能够进行自动化处理。

6.2 展望

随着云计算和容器技术的不断发展，配置管理工具的重要性将越来越凸显。未来，这些工具可能会朝着以下几个方向发展：
1. 集成度更高 ：不同的配置管理工具之间可能会实现更紧密的集成，形成一个统一的配置管理平台，方便用户进行一站式的管理。
2. 智能化 ：引入人工智能和机器学习技术，实现配置的自动优化和故障预测，提高系统的稳定性和可靠性。
3. 多集群支持 ：支持在多个 Kubernetes 集群之间进行配置管理和应用部署，满足企业分布式应用的需求。
4. 安全性增强 ：加强配置管理工具的安全性，提供更完善的权限管理和加密机制，保护用户的敏感信息。

总之，配置管理工具将在未来的云计算和容器化应用中发挥越来越重要的作用，不断推动应用开发和部署的自动化和智能化。