【云原生--Kubernetes】Helm 工具安装

一. Helm 概述

1.1 Helm 简介

在没使用 helm 之前，向 kubernetes 部署应用，我们要依次部署 deployment、svc 等，步骤较繁琐。 况且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂，helm 通过打包的方式，支持发布的版本管理和控制， 很大程度上简化了 Kubernetes 应用的部署和管理。

Helm 本质就是让 K8s 的应用管理（Deployment、Service 等）可配置，可以通过类似于传递环境变量的方式能动态生成。通过动态生成 K8s 资源清单文件（deployment.yaml、service.yaml）。然后调用 Kubectl 自动执行 K8s 资源部署。

我们可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis (https://deis.com/) 开发的一个用于kubernetes的包管理器。每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成name-version.tgz格式的单一文件，方便传输和存储）。

1.2 Helm重要概念

Helm 是官方提供的类似于 YUM 的包管理器，是部署环境的流程封装。Helm 有三个重要的概念：Chart 、Repository 和 Release

• Chart：Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。
• Repository（仓库）：Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。
• Release：使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。可以理解为 Helm 使用 Chart 包部署的一个应用实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 release。

PS：以 MySQL chart 为例，如果你想在你的集群中运行两个数据库，你可以安装该 chart 两次。每一个数据库都会拥有它自己的 release 和 release name。可以将 release 想象成应用程序发布的版本号。

1.3Helm2 组件

在 Helm 中有两个主要的组件，即 Helm 客户端和 Tiller 服务器

• Helm客户端
  是一个供终端用户使用的命令行工具
  客户端负责如下的工作：

• 本地 chart 开发

• 管理仓库

• 与 Tiller 服务器交互（发送需要被安装的 charts、请求关于发布版本的信息、请求更新或者卸载已安装的发布版本）

• Tiller服务端
  Tiller 是 helm 的服务器端，一般运行于 kubernetes 集群之上，定义 tiller 的 ServiceAccount，并通过 ClusterRoleBinding 将其绑定至集群管理员角色 cluster-admin，从而使得它拥有集群级别所有的最高权限

Tiller 服务器负责如下的工作：

• 监听来自于 Helm 客户端的请求
• 组合 chart 和配置来构建一个发布
• 在 Kubernetes 中安装，并跟踪后续的发布
• 通过与 Kubernetes 交互，更新或者 chart

1.4Helm2 工作原理

• Chart Install 过程：

1. Helm从指定的目录或者tgz文件中解析出Chart结构信息
2. Helm将指定的Chart结构和Values信息通过gRPC传递给Tiller
3. Tiller根据Chart和Values生成一个Release
4. Tiller将Release发送给Kubernetes用于生成Release

• Chart Update过程：

1. Helm从指定的目录或者tgz文件中解析出Chart结构信息
2. Helm将要更新的Release的名称和Chart结构，Values信息传递给Tiller
3. Tiller生成Release并更新指定名称的Release的History
4. Tiller将Release发送给Kubernetes用于更新Release

• Chart Rollback过程：

1. Helm将要回滚的Release的名称传递给Tiller
2. Tiller根据Release的名称查找History
3. Tiller从History中获取上一个Release
4. Tiller将上一个Release发送给Kubernetes用于替换当前Release

1.5 Helm2与Helm3区别

Helm2 是 C/S 架构，主要分为客户端 helm 和服务端 Tiller。在 Helm 2 中，Tiller 是作为一个 Deployment 部署在 kube-system 命名空间中，很多情况下，我们会为 Tiller 准备一个 ServiceAccount ，这个 ServiceAccount 通常拥有集群的所有权限。
用户可以使用本地 Helm 命令，自由地连接到 Tiller 中并通过 Tiller 创建、修改、删除任意命名空间下的任意资源。
在 Helm 3 中，Tiller 被移除了。新的 Helm 客户端会像 kubectl 命令一样，读取本地的 kubeconfig 文件，使用我们在 kubeconfig 中预先定义好的权限来进行一系列操作。
Helm3使得我们在使用的时候更加的方便，无需另外为Helm配置任何k8s的权限

二.Helm部署

官方手册：https://helm.sh/zh/docs/

下载二进制 Helm client 安装包：https://github.com