Helm介绍

1.为何要用Helm？

首先在原来项目中都是基于yaml文件来进行部署发布的，而目前项目大部分微服务化或者模块化，会分红不少个组件来部署，每一个组件可能对应一个deployment.yaml,一个service.yaml,一个Ingress.yaml还可能存在各类依赖关系，这样一个项目若是有5个组件，极可能就有15个不一样的yaml文件，这些yaml分散存放，若是某天进行项目恢复的话，很难知道部署顺序，依赖关系等，而全部这些包括

• 基于yaml配置的集中存放
• 基于项目的打包
• 组件间的依赖

均可以经过helm来进行解决。

2.Helm 基本概念

Helm 能够理解为 Kubernetes 的包管理工具，能够方便地发现、共享和使用为Kubernetes构建的应用，它包含几个基本概念

• Chart：一个 Helm 包，其中包含了运行一个应用所须要的镜像、依赖和资源定义等。chart 是建立一个应用的信息集合，包括各类 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。能够将 chart 想象成 apt、yum 中的软件安装包。
• Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上，一个 Chart 能够安装不少次。每次安装都会建立一个新的 release。例如一个 MySQL Chart，若是想在服务器上运行两个数据库，就能够把这个 Chart 安装两次。每次安装都会生成本身的 Release，会有本身的 Release 名称。
• Repository：用于发布和存储 Chart 的仓库。

Helm 是包管理工具，这里的包就是指的 chart。Helm 可以：

1. 从零建立新 chart。

2. 与存储 chart 的仓库交互，拉取、保存和更新 chart。

3. 在 Kubernetes 集群中安装和卸载 release。

4. 更新、回滚和测试 release。

3.Helm 组件及架构

Helm 采用客户端/服务器架构，有以下组件组成：

• Helm CLI 是 Helm 客户端，能够在本地执行
• Tiller 是服务器端组件，在 Kubernetes 群集上运行，并管理 Kubernetes 应用程序的生命周期
• Repository 是 Chart 仓库，Helm客户端经过HTTP协议来访问仓库中Chart的索引文件和压缩包。

Helm 客户端是终端用户使用的命令行工具，用户能够：

1. 在本地开发 chart。

2. 管理 chart 仓库。

3. 与 Tiller 服务器交互。

4. 在远程 Kubernetes 集群上安装 chart。

5. 查看 release 信息。

6. 升级或卸载已有的 release。

Tiller 服务器运行在 Kubernetes 集群中，它会处理 Helm 客户端的请求，与 Kubernetes API Server 交互。Tiller 服务器负责：

1. 监听来自 Helm 客户端的请求。

2. 经过 chart 构建 release。

3. 在 Kubernetes 中安装 chart，并跟踪 release 的状态。

4. 经过 API Server 升级或卸载已有的 release。

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

4.Helm客户端的安装

一般，咱们将 Helm 客户端安装在可以执行 kubectl 命令的节点上，只须要下面一条命令进行安装

# curl https://raw.githubusercontent.com/helm/helm/master/scripts/get | bash

  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  100 7236 100 7236 0 0 10536 0 --:--:-- --:--:-- --:--:-- 10532
  Downloading https://kubernetes-helm.storage.googleapis.com/helm-v2.11.0-linux-amd64.tar.gz
  Preparing to install helm and tiller into /usr/local/bin
  helm installed into /usr/local/bin/helm
  tiller installed into /usr/local/bin/tiller
  Run 'helm init' to configure helm.

执行 helm version 验证。

helm 有不少子命令和参数，为了提升使用命令行的效率，一般建议安装 helm 的 bash 命令补全脚本，方法以下：

echo "source <(helm completion bash)" >>.bashrc

从新登陆后就能够经过 Tab 键补全 helm 子命令和参数了。

 5.Tiller服务器安装

对于已开启RBAC访问控制的集群，首先须要新建账户和绑定

参考：https://github.com/helm/helm/blob/master/docs/rbac.md

vim tiller-rbac-config.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

# kubectl apply -f tiller-rbac-config.yaml

# helm init --service-account tiller  -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.11.0  #镜像地址更换

# helm version

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

查看生成的账户和POD

# kubectl get sa -n kube-system |grep tiller

# kubectl get pods -n kube-system |grep tiller

6.Helm的使用 

Helm 安装成功后，可执行 helm search 查看当前可安装的 chart。

Helm 安装时已经默认配置好了两个仓库：stable 和 local。stable 是官方仓库，local 是用户存放本身开发的 chart 的本地仓库。

# helm repo list
NAME    URL                                             
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts

用户能够经过 helm repo add 添加更多的仓库，好比企业的私有仓库，仓库的管理和维护方法请参考官网文档 https://docs.helm.sh

# helm repo update 更新仓库中可使用的镜像仓库

安装 chart 也很简单，执行以下命令便可安装 MySQL。

# helm install --name mysql stable/mysql  #可以使用--name自定义名称

helm list 显示已经部署的 release，helm delete 能够删除 release

输出分为三部分：

① chart 本次部署的描述信息：

NAME 是 release 的名字，由于咱们没用 -n 参数指定，Helm 随机生成了一个，这里是 fun-zorse。

NAMESPACE 是 release 部署的 namespace，默认是 default，也能够经过 --namespace 指定。

STATUS 为 DEPLOYED，表示已经将 chart 部署到集群。

② 当前 release 包含的资源：Service、Deployment、Secret 和 PersistentVolumeClaim，其名字都是 fun-zorse-mysql，命名的格式为 ReleasName-ChartName。

③ NOTES 部分显示的是 release 的使用方法。好比如何访问 Service，如何获取数据库密码，以及如何链接数据库等

7.Chart目录结构

Chart 由一系列文件组成，这些文件描述了 Kubernetes 部署应用时所须要的资源，好比 Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap 等。

单个的 chart 能够很是简单，只用于部署一个服务，好比 Memcached；chart 也能够很复杂，部署整个应用，好比包含 HTTP Servers、 Database、消息中间件、cache 等。

chart 将这些文件放置在预约义的目录结构中，一般整个 chart 被打成 tar 包，并且标注上版本信息，便于 Helm 部署。

已安装过的release的tar包默认存放在 ~/.helm/cache/archive 目录下，解压后通常大体相同，主要包含：

# helm create hello #这里的手动新建初始化一个release

# tree hello

hello
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   └── service.yaml
└── values.yaml

2 directories, 7 files

Chart.yaml : YAML 文件，描述 chart 的概要信息。name 和 version 是必填项，其余都是可选。

values.yaml : Chart 支持在安装的时根据参数进行定制化配置，而 values.yaml 则提供了这些配置参数的默认值。 

templates 目录 :
各种 Kubernetes 资源的配置模板都放置在这里。Helm 会将 values.yaml 中的参数值注入到模板中生成标准的 YAML 配置文件。

模板是 chart 最重要的部分，也是 Helm 最强大的地方。模板增长了应用部署的灵活性，可以适用不一样的环境。

templates/NOTES.txt : Chart 的简易使用文档，chart 安装成功后会显示此文档内容。

 8.Helm之建立自定义Chart

官方介绍文档：https://docs.helm.sh/developing_charts/#charts

 # helm serve

在本地启动一个仓库，端口：8879，http://127.0.0.1:8879/charts ,固然使用其它的web服务器进行取代也是能够的

# helm status myapp

对应的NOTE.txt信息

# helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com 

添加仓库

# helm fetch incubator/elasticsearch

拉取chart，下载taz包