Helm

已发布的 DevOps 自动化实践 - 定时任务监控的进化之路 一次 KubeCPUOvercommit 告警排查过程小记 DevOps 自动化实践 — 在 K8s 上自动化执行 Database Migration 基于 UniFi 全家桶的企业 Wi-Fi 客户端管理 DevOps 自动化实践 — 管理 Incident 工作流 迁移至个人博客的 由于相关人员长期拖延审稿、发稿，将部分文章迁移至个人博客发布。

在之前的文章中，我介绍了： 如何使用 GitLab CI 实现持续部署。 如何使用 Helm 和 Helmfile 部署应用到 Kubernetes 集群中。 但这其中缺少了关键的一环：创建一个属于你的项目的 chart，这样才能把我们开发的项目通过 Helm 部署到集群中。本文将会为大家介绍我们如何创建并维护 chart，从而打通从提交代码到部署的完整流程。

在上一篇文章中，为大家介绍了 Helm 的初步使用。然而这仍然不能满足我司的工作流，主要问题有： Helm 不提供 apply 命令；因此在 CI/CD 场景中必须考虑到判断是 install 还是 upgrade。 不方便控制安装的 chart 版本；例如指定版本范围、锁定某一版本等。 Values 必须是纯文本；不支持模板渲染、不方便区分环境。 因此我们需要 Helm Releases as Code。我听说过的产品有 Helmsman 和 Helmfile 两款。目前我们团队已经使用后者一段时间，并且有团队成员贡献过部分代码。

Helm 是一款针对 Kubernetes 的「包管理器」，虽说称它为包管理器，其实与应用开发过程中使用的包管理器略有不同，后者管理的是应用开发过程中的依赖，Helm 则管理着 Kubernetes 中应用部署时各项资源的依赖。 如果你对 Kubernetes 有一定了解，相信你已经对 Deployment、Service、Ingress 等资源有了一定认识，大多数 Web 应用在部署到 K8s 集群上时需要大量不同类型的资源。你可以将这些资源声明的 YAML 文件放在同一个文件夹下管理，但是随着数量的增加，如何复用这些 YAML、如何灵活又不繁琐地调整配置以适应不同环境、如何将这些 YAML 作为一个整体管理，成了一个不小的问题。

Recently, I’ve been working against Kubernetes and Helm for a while. Today, I faced a strange problem that could only be triggered in a very very specific condition. After determined what happened under the hood, I decided to write it down in case someone else needs it. Also, BTW, to practice my English. :D

（接上文） 前面的部分介绍了如何为我的博客打包 Docker 镜像，接下来就是重头戏 —— 部署到 Kubernetes。