使用 Helm 管理 K8s 集群中的应用

status
Published
type
Post
slug
helm-k8s
date
Jan 3, 2023
tags
K8s
Helm
DevOps
summary
Helm 是一个 Kubernetes 的包管理工具，通过使用 Charts 描述 Kubernetes 资源的集合来管理和部署应用程序。Helm 3 相对于 Helm 2 提供了更好的安全性、稳定性和易用性。一个典型的 Chart 包含了部署一个应用所需的所有配置、依赖关系和相关资源。我们可以通过修改 Chart 中的配置文件和模板文件来自定义部署应用程序的方式。使用 Helm，我们可以轻松地管理和部署复杂的应用程序，并减少人工操作的错误和遗漏。我们可以通过编写脚本，从现有的 Kubernetes Deployment 配置中提取相应配置，并将其转换为 Helm Values 文件，从而实现自动化管理和部署。
在当前一个项目中，早期交付时的人员使用了 Rancher 的 Web 页面纯手工地逐个部署了整个系统的微服务。这导致之后每次版本更新都需要先从主分支拉取代码并进行编译构建镜像，然后去到 Rancher 设置新版本的镜像标签、配置环境变量等才能完成发布。也就是说这种方式仅仅是通过平台完成了镜像构建，而后续的操作仍然依赖人工进行。
但这样每次都得人工操作配置，难免会出纰漏。于是我提出要改进，小伙伴却又大多觉得发版时这样手动操作一下也没啥 ——“又不是不能用”.jpg 。
notion image
加上其他工作的压力，我只能将这个想法放在一边。但我一直惦记着，可能是因为有一点强迫症：对我来说，所有需要重复人工操作的情景，都应该自动化，无论是通过脚本还是其他方案。
对于 Kubernetes 集群的部署场景，主流的解决方案自然是 Helm 和 Kustomize。考虑到现有平台中有 Helm（但是仅支持 Helm 2版本，我真想去帮他们改进一下这个基础设施建设，太拉了），于是就朝着 Helm 的方式进行改造。

Helm

Helm 是一个 Kubernetes 的包管理工具，借助它我们可以更轻松地管理和部署应用程序。
Helm 使用 Charts 来描述 Kubernetes 资源的集合。一个 Chart 包含了部署一个应用所需的所有配置、依赖关系和相关资源。
主要有两个版本：Helm 2 和 Helm 3
版本差异
  • 配置存储方式
      • 在 Helm 2 中，配置信息存储在 Kubernetes 集群中的 ConfigMap 中，而在 Helm 3 中，配置信息存储在 Secret 中。这种改变带来了更好的安全性，因为 Secrets 可以更好地保护敏感信息，如密码和密钥。
  • Tiller 的移除
      • Helm 2 需要使用 Tiller 来管理和协调 Chart 的部署。然而，Tiller 存在一些安全风险，因此 Helm 3 移除了对 Tiller 的依赖。在 Helm 3 中，所有的操作都直接与 Kubernetes API 交互，提高了安全性和稳定性。
  • Chart 仓库
      • 在 Helm 2 中，Chart 仓库的索引信息存储在集群中的 ConfigMap 中。而在 Helm 3 中，Chart 仓库的索引信息存储在本地计算机上，而不是存储在集群中。这使得 Chart 仓库的管理更加灵活，并且不会影响到集群的状态。
  • 命名空间隔离
      • Helm 3 引入了命名空间隔离的概念，每个 Release（一个部署的实例）都与特定的命名空间相关联。这提供了更好的资源管理和隔离，使得在同一个集群中部署多个实例更加容易。
  • 命令行工具的改进
      • Helm 3 对命令行工具进行了改进，使其更加直观和易用。一些命令的参数名称和行为也发生了变化，以提供更好的一致性和易读性。
综合来看，Helm 3 相对于 Helm 2 提供了更好的安全性、稳定性和易用性，但此处受限于基础设施条件，只得使用 Helm 2。

Chart

Chart 是 Helm 的核心概念之一，它是一个预定义的模板，用于描述如何部署一个应用程序到 Kubernetes。Chart 由多个文件组成，包括配置文件、模板文件和其他资源文件。
一个典型的 Chart 包含以下文件和目录：
  • Chart.yaml：Chart 的元数据，包括版本、名称、描述等信息。
  • values.yaml：默认的配置值，用于指定部署应用程序时的参数。
  • templates/：包含了用于生成 Kubernetes 资源的模板文件。
  • charts/：用于存放依赖的子 Chart。
通过修改 Chart 中的配置文件和模板文件，我们可以自定义部署应用程序的方式。比如，可以修改容器的副本数、暴露的端口号，或者添加其他 Kubernetes 资源，如 Service、Ingress 等。
Chart 的结构和文件配置提供了一种灵活且可复用的方式来管理 Kubernetes 应用程序的部署。通过使用 Helm，我们可以轻松地管理和部署复杂的应用程序，并且减少人工操作带来的错误和遗漏。
 
以上是对 Helm 的基础介绍，可见要将现有运行着的应用改造为 Helm 管理，先确定好模板，然后再配置 values.yaml 文件即可。
但是系统的微服务少说都是几十个，一个个对照现有配置修改 values.yaml 也太麻烦了，纯复制粘贴的体力活。这种同一模式下的重复操作那自然就得把他自动化，如下 go 脚本，通过与 K8s 集群的API Server 交互得到 各个应用的现有配置，然后再将其解析转换为 values.yaml 所要求的格式。
ℹ️
因模板文件有针对性修改调整，故此脚本生成的 values.yaml 并不适用于 helm 命令所创建的标准Chart
以上脚本完成了从现有 K8s 集群中提取配置转换为 values.yaml , 同时按照服务名，按照 Chart 文件夹格式分别保存。基于此我们可以快速地得到相应的 Helm 配置，之后就是配置 CI/CD 的流水线。
以后版本更新就可以不再需要那么多人工操作了。

2020 - 2024 © HK