Helm Chart - 随笔

发现越来越多公司用 K8S 了，反正不管服务多大多小，都上 K8S，那之前了解过的简单的 deployment 部署就不够用了，就得用上更上一层的工具 Helm。

What

Helm 是打包+模版+发布工具，它可以把各种资源如 Deployment、Service、ConfigMap 写成模版，打成一个 Chart，并在运行时根据 values 动态渲染这些模版并部署资源，并且支持发布回滚。

Helm 是基于 Go 语言实现的，所以模板语法采用的是 Go 的 template。

How

一个典型的 Helm Chart 结构大概是这样：

mychart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml

或者更典型的包含前后端的项目大概是这样：

mychart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── frontend/
    │   ├── deployment.yaml
    │   └── service.yaml
    ├── backend/
    │   ├── deployment.yaml
    │   └── service.yaml
    └── _helpers.tpl

其中 values 就是存放变量的地方，在 templates 下面的各个 yaml 配置中引用，比如前端项目中的仓库以及暴露的端口可以定义为变量：

spec:
      containers:
      - name: frontend
        image: "{{ .Values.frontend.image.repository }}:{{ .Values.frontend.image.tag }}"
        ports:
        - containerPort: {{ .Values.frontend.service.port }}

具体每个放什么可以拷贝上方目录结构，然后对着 AI 吟唱：请帮我生成一个 Helm Chart，目录参考以上，技术栈用的是 XXX+XXX。

接着是运行该 Chart

helm install myapp ./mychart
helm upgrade myapp ./mychart

以及如果运行了发现有问题，需要回滚

helm rollback myapp <revision>

如果觉得 CLI 工具不够直观，操作起来不够简单，也有许多开源的 GUI 工具，比如 Argo CD 基于 GitOps 工作流，当 Helm Chart 仓库产生变更时自动执行部署。

比如当进入测试阶段后，当测试提出问题，开发修复完成后，就可以在构建完成后提交一个 PR，测试进行 MR 后自动部署，接着就可以验收之前提出的问题。

回顾历史演进，到目前为止可以细分为五个阶段：

阶段 0: 直接部署
阶段 1: Docker 单机部署
阶段 2: Docker Compose 多服务协调
阶段 3: Kubernetes YAML 资源部署
阶段 4: Kubernetes Helm 模板化部署