k8s的应用打包工具Helm

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

本章我们将讨论为什么需要 Helm，它的架构和组件，以及如何使用 Helm。

1.Why Helm

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

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

先来看个例子。
比如对于一个 MySQL 服务， Kubernetes 需要部署下面这些对象：

1.Service，让外界能够访问到 MySQL。

2.Secret，定义 MySQL 的密码。

3.PersistentVolumeClaim，为 MySQL 申请持久化存储空间。

4.Deployment，部署 MySQL Pod，并使用上面的这些支持对象。

我们可以将上面这些配置保存到对象各自的文件中，或者集中写进一个配置文件，然后通过 kubectl apply -f 部署。

到目前为止，Kubernetes 对服务的部署支持得都挺好，如果应用只由一个或几个这样的服务组成，上面的部署方式完全足够了。

但是，如果我们开发的是微服务架构的应用，组成应用的服务可能多达十个甚至几十上百个，这种组织和管理应用的方式就不好使了：

1. 很难管理、编辑和维护如此多的服务。每个服务都有若干配置，缺乏一个更高层次的工具将这些配置组织起来。

2. 不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务，然后按照逻辑顺序依次执行 kubectl apply。即缺少一种工具来定义应用与服务，以及服务与服务之间的依赖关系。

3. 不能高效地共享和重用服务。比如两个应用都要用到 MySQL 服务，但配置的参数不一样，这两个应用只能分别拷贝一套标准的 MySQL 配置文件，修改后通过 kubectl apply 部署。也就是说不支持参数化配置和多环境部署。

4. 不支持应用级别的版本管理。虽然可以通过 kubectl rollout undo 进行回滚，但这只能针对单个 Deployment，不支持整个应用的回滚。

5. 不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问 MySQL。虽然 Kubernetes 有健康检查，但那是针对单个容器，我们需要应用（服务）级别的健康检查。

Helm 能够解决上面这些问题，Helm 帮助 Kubernetes 成为微服务架构应用理想的部署平台。

2.Helm架构

Helm 有两个重要的概念：chart 和 release。

chart 是创建一个应用的信息集合，包括各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。可以将 chart 想象成 apt、yum 中的软件安装包。

release 是 chart 的运行实例，代表了一个正在运行的应用。当 chart 被安装到 Kubernetes 集群，就生成一个 release。chart 能够多次安装到同一个集群，每次安装都是一个 release。

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

1. 从零创建新 chart。

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

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

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

Helm 包含两个组件：Helm 客户端 和 Tiller 服务器。

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。

3.Helm的部署

3.1Helm 客户端

通常，我们将 Helm 客户端安装在能够执行 kubectl 命令的节点上，只需要下面一条命令：(需要FQ)

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

执行 helm version 验证。

[root@k8s-master app]# mv linux-amd64/helm /usr/local/bin/helm

目前只能查看到客户端的版本，服务器还没有安装。

3.2Tiller 服务器

Tiller 服务器安装非常简单，只需要执行 helm init：

 

Tiller 本身也是作为容器化应用运行在 Kubernetes Cluster 中的：

查看日志

kubectl describe pod --namespace=kube-system

没法FQ镜像pull失败，于是在网上找了个镜像压缩包

 根据日志tiller需要版本v2.11.0而现在我们这个是v2.9.0需要改一下tag

docker tag gcr.io/kubernetes-helm/tiller:v2.9.0 gcr.io/kubernetes-helm/tiller:v2.11.0

将镜像打包 分发给工作节点node1 和node2

docker save  gcr.io/kubernetes-helm/tiller：v2.11.0 tiller-v2.11.0.tar

 

可以看到 Tiller 的 Service、Deployment 和 Pod。

现在， helm version 已经能够查看到服务器的版本信息了。

 

Helm 部署完毕,能***的最好用*** 下载最新的，不然在使用的时候版本不一致会出现问题。

 

4.Helm的使用

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

这个列表很长，这里只截取了一部分。大家不禁会问，这些 chart 都是从哪里来的？

前面说过，Helm 可以像 apt 和 yum 管理软件包一样管理 chart。apt 和 yum 的软件包存放在仓库中，同样的，Helm 也有仓库。

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

helm search 会显示 chart 位于哪个仓库，比如 local/cool-chart 和 stable/acs-engine-autoscaler。

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

与 apt 和 yum 一样，helm 也支持关键字搜索：

包括 DESCRIPTION 在内的所有信息，只要跟关键字匹配，都会显示在结果列表中。

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

helm install stable/mysql

如果看到如下报错，通常是因为 Tiller 服务器的权限不足。

 

执行如下命名添加权限：

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

 

 

 需要添加仓库

helm repo list    #列出所有源，当前还没有添加源
# 添加一个国内可以访问的阿里源，不过好像最近不更新了
helm repo add ali https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts  
如果能连外网，可以加google，f8
helm repo add google https://kubernetes-charts.storage.googleapis.com 
helm repo add fabric8 https://fabric8.io/helm
# 更新源
helm repo update

无法***，只好老实的加一条阿里的仓库

 

输出分为三部分：

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

NAME 是 release 的名字，因为我们没用 -n 参数指定，Helm 随机生成了一个，这里是 piquant-parrot。

NAMESPACE 是 release 部署的 namespace，默认是 default，也可以通过 --namespace 指定。

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

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

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

通过 kubectl get 可以查看组成 release 的各个对象

 

因为我们还没有准备 PersistentVolume，当前 release 还不可用。

helm list 显示已经部署的 release，helm delete 可以删除 release

 

转载于:https://www.cnblogs.com/benjamin77/p/9963250.html