k8s的包管理

1、Helm的概念和架构

每个成功的软件平台都有一个优秀的打包系统，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 则是 Kubernetes 上的包管理器。

 

思考？？Helm 到底解决了什么问题？为什么 Kubernetes 需要 Helm？

 

Kubernetes 能够很好地组织和编排容器，但它缺少一个更高层次的应用打包工具，而 Helm 就是来干这件事的。

 

举个例子，我们需要部署一个MySQL服务，Kubernetes则需要部署以下对象：

 

① 为了能够让外界访问到MySQL，需要部署一个mysql的service；

 

②需要进行定义MySQL的密码，则需要部署一个Secret；

 

③Mysql的运行需要持久化的数据存储，此时还需要部署PVC；

 

④保证后端mysql的运行，还需要部署一个Deployment，以支持以上的对象。

 

针对以上对象，我们可以使用YAML文件进行定义并部署，但是仅仅对于单个的服务支持，如果应用需要由一个甚至几十个这样的服务组成，并且还需要考虑各种服务的依赖问题，可想而知，这样的组织管理应用的方式就显得繁琐。为此就诞生了一个工具Helm，就是为了解决Kubernetes这种应用部署繁重的现象。

 

Helm的核心术语：

 

Chart：一个helm程序包，是创建一个应用的信息集合，包含各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等。可以将Chart比喻为yum中的软件安装包；

Repository：Charts仓库，用于集中存储和分发Charts；

Config：应用程序实例化安装运行时所需要的配置信息；

Release：特定的Chart部署于目标集群上的一个实例，代表这一个正在运行的应用。当chart被安装到Kubernetes集群，就会生成一个release，chart可以多次安装到同一个集群，每次安装都是一个release。

Helm的程序架构：

 

Helm主要由Helm客户端、Tiller服务器和Charts仓库组成，如下图：

 

helm：客户端，GO语言编写，实现管理本地的Chart仓库，可管理Chart，与Tiller服务进行交互，用于发送Chart，实例安装、查询、卸载等操作。

Tiller：服务端，通常运行在K8S集群之上。用于接收helm发来的Charts和Conifg，合并生成release，完成部署。

简单的说：Helm 客户端负责管理 chart；Tiller 服务器负责管理 release。