Helm on K8S

前言

容器的出现，标志着云原生的到来，Docker 基于 Linux 隔离、虚拟化等能力封装了应用；Kubernetes 的出现，建立了云原生时代的技术基础设施，它基于对容器的编排封装了集群；Kubernetes 可以说是云原生的操作系统，它解决了容器之间隔离与协助的问题、解决了分布式系统可靠性的问题；而云原生发展的脚步并没有停下来，这就是 Helm，它封装了应用（Kubernetes 应用的定义、安装和升级）。

Kubernetes应用部署的挑战

通过 Kubernetes 部署一个应用，我们需要写很多的 yml 文件来描述服务，包括 Pod，Service，Volume，Namespace，ReplicaSet，Deployment，Job 等等。然后需要通过 Kubernetes 命令行工具 kubeclt 去逐个 apply。

在这个过程中，我们遇到了以下问题：

1. 通常这些 yml 文件被维护在 git 仓库中，一般 kubectl apply 是在自己的主机上进行，没有纳入 CR 流程，git 仓库的更新也面临挑战。
2. 这些 yml 配置无法复用

Helm 是什么？

Helm 是一个 Kubernetes package manager，Chart 是它定义的格式，类比 Linux 系统下的包管理工具，就像是 Debian 系统的 apt-get 命令与 dpkg 格式、REHL 系统的 yum 命令与 rpm 格式。

Chart的格式如下：

filebeat/
    templates/
        NOTES.txt
        clusterrole.yaml
        clusterrolebinding.yaml
        configmap.yaml
        daemonset.yaml
        deployment.yaml
        serviceaccount.yaml
    Chart.yaml
    requirements.yaml
    values.yml

• Chart.yaml给出了应用自身的详细信息（名称、版本、许可证、自述、说明、图标，等等）
• requirements.yaml给出了应用的依赖关系，依赖项指向的是另一个应用的坐标（名称、版本、Repository地址）
• values.yaml给出了所有可配置项目的预定义值。

部署应用时，Helm会先将管理员设置的值覆盖到values.yaml的默认值上，然后以字符串替换的形式传递给templates目录的资源模板，最后生成要部署到Kubernetes的资源文件。由于Chart封装了足够丰富的信息，所以Helm除了支持命令行操作外，也能很容易地根据这些信息自动生成图形化的应用安装、参数设置界面。

Chart 定义统一的应用配置格式，并通过社区的力量号召大量开发者贡献常用应用的 Chart。并建立了类似 Docker hub

的 Chart 存储仓库，建立了应用发布者与使用者之间责任分明的关系。

应用发布者通过 Helm 打包应用到 Helm Hub 仓库。

使用者通过 Helm 下载应用并安装在 Kubernetes 上。

总结

Helm 的思想与 Docker 一致，通过封装与打包，隐藏与使用者无关的细节，解放使用者双手。但 Helm 也并非银弹，它无法很好的管理有状态服务的依赖关系。云原生还在继续~