k8s：helm详细介绍及案例（带你上车helm）

1、helm介绍

1.1 Helm 是什么？

helm 是 Kubernetes 的包管理器。包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的 yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成，能够将一组K8S资源打包统一管理，是查找、共享和使用为Kubernetes构建的软件的最佳方式。

Helm类似于yum安装指令，统一对安装服务进行管理，使得用户不需要关心服务之间的依赖关系。

1.2 首先介绍传统的k8s部署应用流程 ？ 面临的问题 ？ ？

传统的部署流程 ？
拉取代码
打包编译
构建镜像
准备资源
准备一堆相关部署资源清单的 yaml 文件(如:deployment、statefulset、service、ingress等
kubectl apply 部署

部署面临的问题 ？
如何统一管理、配置和更新这些分散的 k8s 的应用资源文件
如何分发和复用一套应用模板
如何将应用的一系列资源当做一个软件包管理

1.3 传统部署方式引发的问题 ？

·随着资源引用的增多，需要维护大量的yaml文件
·微服务场景下，每个微服务所需配置差别不大，众多的微服务的yaml文件无法高效复用
·无法将相关yaml文件做为一个整体管理，并实现应用级别的升级和回滚等功能
无法根据一套yaml文件来创建多个环境，需要手动进行修改，尤其是微服务众多的情况，效率低下
例如:部署的环境都分为开发、预生产、生产环境，在开发这套环境部署完了，后面再部署到预生产和生产环境，还需要重新复制出两套配置文件，并手动修改才能完成

1.4 Helm 解决了什么痛点 ？

在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。比如你安装一个 WordPress 博客，用到了一些 Kubernetes (下面全部简称k8s)的一些资源对象，包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码，可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在mariadb里面的，所以需要 mariadb 启动就绪后才能启动 WordPress。这些 k8s 资源过于分散，不方便进行管理，直接通过 kubectl 来管理一套应用，你会发现这十分难受。

1.5 helm和oprater的关系 ？

he1m 和 oprater(有状态服务的、statefulset的升级版)关系：

he1m 只是包管理器,支持无,或有状态的服务
helm 建立在oprater再一层的封装

2、Helm 相关组件及概念

2.1 组件概念描述

Helm 包含两个组件，分别是 helm 客户端 和 Tiller 服务器：

helm 是一个命令行工具，用于本地开发及管理chart，chart仓库管理等
Tiller 是 Helm 的服务端。Tiller 负责接收 Helm 的请求，与 k8s 的 apiserver 交互，根据chart 来生成一个 release 并管理 release

2.2 helm和k8s通信流程 ？

V1和V2版本的helm	
helm（Client）————> gRPC——————> Tiller ——————> kubernetes—API

V3版本的helm
helm（Client）（master节点）——————>使用kubeconfig认证————————> kubernetes—API

2.3 资源概念描述

Chart	一个Helm包，其中包含了运行一个应用所需要的镜像、依赖和资源定义等（Helm的打包格式叫做chart，所谓chart就是一系列资源文件, 它描述了一组相关的 k8s 集群资源）

Repository	存储Helm Charts的地方（类似于docker的harbor仓库）

Release	Chart在k8s上运行的Chart的一个实例，例如，如果一个MySQL Chart想在服务器上运行两个数据库，可以将这个Chart安装两次，并在每次安装中生成自己的Release以及Release名称。（使用 helm install 命令在 Kubernetes 集群中部署）

Value	Helm Chart的参数，用于配置Kubernetes对象

Template	使用Go模板语言生成Kubernetes对象的定义文件

Namespace	Kubernetes中用于隔离资源的逻辑分区

2.4 创建release

helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息
helm 客户端指定的 chart 结构和 values 信息通过 gRPC 传递给 Tiller
Tiller 服务端根据 chart 和 values 生成一个 release
Tiller 将install release请求直接传递给 kube-apiserver

2.5 删除release

helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息
helm 客户端指定的 chart 结构和 values 信息通过 gRPC 传递给 Tiller
Tiller 服务端根据 chart 和 values 生成一个 release
Tiller 将delete release请求直接传递给 kube-apiserver

2.6 更新release

helm 客户端将需要更新的 chart 的 release 名称 chart 结构和 value 信息传给 Tiller
Tiller 将收到的信息生成新的 release，并同时更新这个 release 的 history
Tiller 将新的 release 传递给 kube-apiserver 进行更新

2.7 chart 的基本结构

charts 目录存放依赖的chart

Chart.yaml 包含Chart的基本信息，包括chart版本，名称等

templates 目录下存放应用一系