1、Kubernetes 应用部署的挑战

Kubernetes 是一个提供了基于容器的应用集群管理解决方案,Kubernetes 为容器化应用提供了部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。
Kubernetes 的核心设计理念是: 用户定义要部署的应用程序的规则,而 Kubernetes 则负责按照定义的规则部署并运行应用程序。如果应用程序出现问题导致偏离了定义的规格,Kubernetes 负责对其进行自动修正。例如:定义的应用规则要求部署两个实例(Pod),其中一个实例异常终止了,Kubernetes 会检查到并重新启动一个新的实例。
用户通过使用 Kubernetes API 对象来描述应用程序规则,包括 Pod、Service、Volume、Namespace、ReplicaSet、Deployment、Job等等。一般这些资源对象的定义需要写入一系列的 YAML 文件中,然后通过 Kubernetes 命令行工具 Kubectl 调 Kubernetes API 进行部署。

以一个典型的三层应用 Wordpress 为例,该应用程序就涉及到多个 Kubernetes API 对象,而要描述这些 Kubernetes API 对象就可能要同时维护多个 YAML 文件。
在进行 Kubernetes 软件部署时,我们面临下述几个问题:

  • 如何管理、编辑和更新这些这些分散的 Kubernetes 应用配置文件。
  • 如何把一套相关的配置文件作为一个应用进行管理。
  • 如何分发和重用 Kubernetes 的应用配置

2、Helm 是什么

Helm 是 Deis 开发的一个用于 Kubernetes 应用的包管理工具,主要用来管理 Charts。有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。

Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata,以便于应用程序的分发。

对于应用发布者而言,可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。

对于使用者而言,使用 Helm 后不用需要编写复杂的应用部署文件,可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
做为 Kubernetes 的一个包管理工具,Helm具有如下功能:
创建新的 chart
chart 打包成 tgz 格式
上传 chart 到 chart 仓库或从仓库中下载 chart
在Kubernetes集群中安装或卸载 chart
管理用Helm安装的 chart 的发布周期

3、Helm 组件及相关术语

本文中讲到的是helm V2最新版本,V3版本也已经发布了beta版,在 Helm 3 中,Tiller 被移除了。

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

  • Tiller
    Tiller 是 Helm 的服务端,部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求,并根据 Chart 生成 Kubernetes 的部署文件( Helm 称为 Release ),然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。

  • Chart
    包含了创建Kubernetes的一个应用实例的必要信息,Helm 的软件包,采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包,其包含了一组定义 Kubernetes 资源相关的 YAML 文件。

  • Repoistory
    Helm 的软件仓库,Repository 本质上是一个 Web 服务器,该服务器保存了一系列的 Chart 软件包以供用户下载,并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。

  • Release
    是一个 chart 及其配置的一个运行实例,使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。

4、Helm 工作原理

  • Chart Install 过程
    Helm 从指定的目录或者 TAR 文件中解析出 Chart 结构信息。
    Helm 将指定的 Chart 结构和 Values 信息通过 gRPC 传递给 Tiller。
    Tiller 根据 Chart 和 Values 生成一个 Release。
    Tiller 将 Release 发送给 Kubernetes 用于生成 Release。

  • Chart Update 过程
    Helm 从指定的目录或者 TAR 文件中解析出 Chart 结构信息。
    Helm 将需要更新的 Release 的名称、Chart 结构和 Values 信息传递给 Tiller。
    Tiller 生成 Release 并更新指定名称的 Release 的 History。
    Tiller 将 Release 发送给 Kubernetes 用于更新 Release。

  • Chart Rollback 过程
    Helm 将要回滚的 Release 的名称传递给 Tiller。
    Tiller 根据 Release 的名称查找 History。
    Tiller 从 History 中获取上一个 Release。
    Tiller 将上一个 Release 发送给 Kubernetes 用于替换当前 Release。

  • Chart 处理依赖说明
    Tiller 在处理 Chart 时,直接将 Chart 以及其依赖的所有 Charts 合并为一个 Release,同时传递给 Kubernetes。因此 Tiller 并不负责管理依赖之间的启动顺序。Chart 中的应用需要能够自行处理依赖关系。

Helm Client 是用户命令行工具,其主要负责如下:

  • 本地 chart 开发
  • 仓库管理
  • 与 Tiller sever 交互
  • 发送预安装的 chart
  • 查询 release 信息
  • 要求升级或卸载已存在的 release

Tiller Server是一个部署在Kubernetes集群内部的 server,其与 Helm client、Kubernetes API server 进行交互。Tiller server 主要负责如下:
监听来自 Helm client 的请求
通过 chart 及其配置构建一次发布
安装 chart 到Kubernetes集群,并跟踪随后的发布
通过与Kubernetes交互升级或卸载 chart
简单的说,client 管理 charts,而 server 管理发布 release

5、Helm 安装

5.1 客户端安装

客户端二进制文件下载地址:https://github.com/helm/helm/releases
解压后将可执行文件helm拷贝到/usr/local/bin目录下即可,这样Helm客户端就在这台机器上安装完成了。

[root@master01 helm-soft]# mv linux-amd64/helm /usr/local/bin/
[root@master01 helm-soft]# helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

5.2 安装服务端 Tiller

Tiller 是以 Deployment 方式部署在 Kubernetes 集群中的,只需使用以下指令便可简单的完成安装,使用阿里云镜像安装并把默认仓库设置为阿里云上的镜像仓库

[root@master01 helm-soft]# helm init --upgrade --tiller-image registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.14.3 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
$HELM_HOME has been configured at /root/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Happy Helming!
[root@master01 helm-soft]# kubectl get pods -n kube-system |grep tiller-deploy
tiller-deploy-6d99bc8567-zv9q8          1/1     Running   0          2m33s
[root@master01 helm-soft]# helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

如果在初始化时报错

Error: cannot connect to Tiller

解决方法为在节点执行

yum install -y socat

5.3 给 Tiller 授权

因为 Helm 的服务端 Tiller 是一个部署在 Kubernetes 中 Kube-System Namespace 下 的 Deployment,它会去连接 Kube-Api 在 Kubernetes 里创建和删除应用。
而从 Kubernetes 1.6 版本开始,API Server 启用了 RBAC 授权。目前的 Tiller 部署时默认没有定义授权的 ServiceAccount,这会导致访问 API Server 时被拒绝。所以我们需要明确为 Tiller 部署添加授权。详细内容可见https://docs.helm.sh/using_helm/#role-based-access-control

[root@master01 helm]# pwd
/root/manifest/helm
[root@master01 helm]# vim rbac.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
[root@master01 helm]# kubectl create -f rbac.yaml 
serviceaccount/tiller created
clusterrolebinding.rbac.authorization.k8s.io/tiller created    

使用 kubectl patch 更新 API 对象,给 Tiller 打上一个 ServiceAccount 的补丁

[root@master01 helm]# kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
deployment.extensions/tiller-deploy patched

查看授权是否成功

[root@master01 helm]# kubectl get deploy --namespace kube-system   tiller-deploy  --output yaml|grep  serviceAccount
      serviceAccount: tiller
      serviceAccountName: tiller

卸载 Helm 服务器端 Tiller
如果你需要在 Kubernetes 中卸载已部署的 Tiller,可使用命令helm reset完成卸载。

5.4 Helm 命令补全

命令自动补全
为了方便 helm 命令的使用,Helm 提供了自动补全功能
如果使用 ZSH 请执行

$ source <(helm completion zsh)

如果使用 BASH 请执行

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