面对配置文件不再恐慌，k8s的包管理神器helm简介

helm

helm 是 k8s 生态中的软件包管理工具，其作用可类比于 Ubuntu 系统中的 apt，或者是 CentOS 中的 yum，又或者是 python 中的 pip。都是为了应用或模块的统一打包、分发、依赖管理等工作。

同大多数包管理器一样，helm 也是爱偷懒的程序猿们为了解放双手解决低端劳动力而产生的。在 k8s 中，要部署一个应用，需要很多 k8s 的配置文件（yaml）协同工作，例如
Deployment/Service/ReplicationController 等等。

编写这些配置文件是一项非常枯燥且乏味的事情。往往部署一个新服务，需要`Ctrl+C`/`Ctrl+V`一个已有的服务，然后修修改改，一不小心写错一个配置说不定还能引起雪崩效应。同时这些资源的配置非常松散，没有一个统一管理的有效途径，如果直接通过**kubectl**来管理集群，将会是一个灾难。

helm帮我们解决了这些问题

Helm 架构

helm架构图

helm 通过客户端工具从仓库拉取软件包，再通过kubeconfig配置文件链接到k8s集群，与k8s的ApiServer进行交互，以实现部署。

在helm3.X版本之前，还有一个helm Tiller作为helm部署在k8s集群中的服务器，负责接收来自客户端的请求再投递给k8s集群。从helm 3.X以后，helm客户端直连k8s ApiServer，进一步简化了架构。

Helm 关键词

Helm client，是一个命令行客户端工具，主要用于 k8s 应用程序 chart 的创建、打包、发布以及创建和管理本地和远程的 chart 仓库。

Chart，即helm的软件包，采用tar格式打包。chart包含了一组定义k8s资源的相关配置文件。

Release，使用helm install命令生成在k8s集群中的部署叫做**Release**。

Repository，helm的软件包仓库，就如同docker的hub。

Helm 客户端使用

如果你在本地使用了k3s，那么其自带的helm在使用时可能会遇到这样的问题：

或者是

第一个问题是因为上面说到的3.X版本的helm不再需要Tiller服务器了，直接访问了ApiServer，而第二种报错则是因为kubeconfig配置文件中的证书信息问题，但这两个问题都可以用同意的方法解决。

手动配置 KUBECONFIG 环境变量

其目的是让helm使用正确的kubeconfig配置文件，之后在此执行helm命令就恢复正常了。

使用 Helm 部署服务

helm创建一个软件包非常容易，创建之后再使用install命令即可部署一个服务，创建好的软件包可保留下次创建时直接使用，或者直接通过Repository部署他人编写好的软件包。

创建软件包

我们来看一下生成的软件包目录下的结构

Chart.yaml

Chart.yaml 文件描述了软件包的基本信息，如名称、简介、版本号等内容。

templates/

templates/ 目录下保存了部署服务所需要用到的配置模板，这些模板统一使用`Go`语言内置的模板库实现，其语法格式也同内置模板库相同。

values.yaml

这个文件里面存储了 templates/ 模板文件中所需要用到的键值，例如以下默认的部署软件包的内容：

helm就是这样通过获取 templates/* 与 values.yaml 文件，联合渲染为k8s的配置文件，然后投递给k8s ApiServer进行服务部署的。

部署软件包

之后我们只需要简单地执行install命令即可将服务部署到k8s集群中去。

执行list命令可查看部署包的状态。

以上为helm简单入门，关于helm的更多信息可以参考官方文档了解。

来源：文兄君