K8s安装Helm
摘要
0.1 1.1 Helm的安装
0.1.1 1.1.1 helm简介
很多人都使用过Ubuntu下的ap-get或者CentOS下的yum, 这两者都是Linux系统下的包管理工具。采用apt-get/yum,应用开发者可以管理应用包之间的依赖关系,发布应用;用户则可以以简单的方式查找、安装、升级、卸载应用程序。
我们可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis (https://deis.com/) 开发的一个用于kubernetes的包管理器。每个包称为一个Chart,一个Chart是一个目录(一般情况下会将目录进行打包压缩,形成name-version.tgz格式的单一文件,方便传输和存储)。
对于应用发布者而言,可以通过Helm打包应用,管理应用依赖关系,管理应用版本并发布应用到软件仓库。
对于使用者而言,使用Helm后不用需要了解Kubernetes的Yaml语法并编写应用部署文件,可以通过Helm下载并在kubernetes上安装需要的应用。
除此以外,Helm还提供了kubernetes上的软件部署,删除,升级,回滚应用的强大功能。
0.1.2 1.1.2 Helm 组件及相关术语
0.1.2.1 Helm
Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。
0.1.2.2 Tiller
Tiller 是 Helm 的服务端,部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求,并根据 Chart 生成 Kubernetes 的部署文件( Helm 称为 Release ),然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。
0.1.2.3 Chart
Helm 的软件包,采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包,其包含了一组定义 Kubernetes 资源相关的 YAML 文件。
0.1.2.4 Repoistory
Helm 的软件仓库,Repository 本质上是一个 Web 服务器,该服务器保存了一系列的 Chart 软件包以供用户下载,并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。
注:需要注意的是:Helm 中提到的 Release 和我们通常概念中的版本有所不同,这里的 Release 可以理解为 Helm 使用 Chart 包部署的一个应用实例。
0.1.3 1.1.3 Helm工作原理
Chart Install 过程:
- Helm从指定的目录或者tgz文件中解析出Chart结构信息
- Helm将指定的Chart结构和Values信息通过gRPC传递给Tiller
- Tiller根据Chart和Values生成一个Release
- Tiller将Release发送给Kubernetes用于生成Release
Chart Update过程:
- Helm从指定的目录或者tgz文件中解析出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
0.1.4 1.1.4 Helm部署
0.1.4.1 Helm 客户端安装
Helm 的安装方式很多,这里采用二进制的方式安装。更多安装方法可以参考 Helm 的官方帮助文档。
使用官方提供的脚本一键安装
|
|
helm3安装
|
|
手动下载安装
从官网下载最新版本的二进制安装包到本地(推荐用迅雷下载后上传服务器)
|
|
helm3安装
|
|
验证
|
|
目前只能查看到客户端的版本,服务器还没有安装,helm3无需安装Tiller。
0.1.4.2 Helm 服务端安装Tiller
注意:先在 K8S 集群上每个节点安装 socat 软件
|
|
不然会报如下错误:
|
|
为了安装服务端tiller,还需要在这台机器上配置好kubectl工具和kubeconfig文件,确保kubectl工具可以在这台机器上访问apiserver且正常使用。 这里的node1节点已经配置好了kubectl。
因为Kubernetes APIServer开启了RBAC访问控制,所以需要创建tiller使用的ServiceAccount: tiller并分配合适的角色给它。 详细内容可以查看helm文档中的Role-based Access Control。 这里简单起见直接分配cluster-admin这个集群内置的ClusterRole给它。
创建tiller.yaml
|
|
|
|
初始化helm服务端
|
|
Tiller 是以 Deployment 方式部署在 Kubernetes 集群中的
由于 Helm 默认会去gcr.io拉取镜像,所以如果你当前执行的机器没有配置科学上网的话可以实现下面的命令代替:helm init –service-account tiller --tiller-image <images-url> –skip-refresh
使用私有镜像仓库中的tiller镜像
|
|
tiller默认被部署在k8s集群中的 kube-system 这个 namespace 下
|
|
最后在node1上修改helm chart仓库的地址为azure提供的镜像地址:
|
|
0.1.4.3 卸载 Helm 服务器端 Tiller
如果你需要在 Kubernetes 中卸载已部署的 Tiller,可使用以下命令完成卸载。
|
|
验证helm
|
|