简化Kubernetes应用部署工具-Helm简介

本文讲的是 简化Kubernetes应用部署工具-Helm简介【编者的话】微服务和容器化给复杂应用部署与管理带来了极大的挑战。Helm是目前Kubernetes服务编排领域的唯一开源子项目，做为Kubernetes应用的一个包管理工具，可理解为Kubernetes的apt-get / yum，由Deis 公司发起，该公司已经被微软收购。Helm通过软件打包的形式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用部署和管理的复杂性。

随着业务容器化与向微服务架构转变，通过分解巨大的单体应用为多个服务的方式，分解了单体应用的复杂性，使每个微服务都可以独立部署和扩展，实现了敏捷开发和快速迭代和部署。但任何事情都有两面性，虽然微服务给我们带来了很多便利，但由于应用被拆分成多个组件，导致服务数量大幅增加，对于Kubernetest编排来说，每个组件有自己的资源文件，并且可以独立的部署与伸缩，这给采用Kubernetes做应用编排带来了诸多挑战：

管理、编辑与更新大量的K8s配置文件
部署一个含有大量配置文件的复杂K8s应用
分享和复用K8s配置和应用
参数化配置模板支持多个环境
管理应用的发布：回滚、diff和查看发布历史
控制一个部署周期中的某一些环节
发布后的验证

而Helm恰好可以帮助我们解决上面问题

Helm把Kubernetes资源(比如deployments、services或 ingress等) 打包到一个chart中，而chart被保存到chart仓库。通过chart仓库可用来存储和分享chart。Helm使发布可配置，支持发布应用配置的版本管理，简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。

本文简单介绍了Helm的用途、架构与实现。

Helm产生原因

利用Kubernetes部署一个应用，需要Kubernetes原生资源文件如deployment、replicationcontroller、service或pod 等。而对于一个复杂的应用，会有很多类似上面的资源描述文件，如果有更新或回滚应用的需求，可能要修改和维护所涉及的大量资源文件，且由于缺少对发布过的应用版本管理和控制，使Kubernetes上的应用维护和更新等面临诸多的挑战，而Helm可以帮我们解决这些问题。

Helm架构

Helm基本架构如下：

Helm用途

做为Kubernetes的一个包管理工具，Helm具有如下功能：

创建新的chart
chart打包成tgz格式
上传chart到chart仓库或从仓库中下载chart
在Kubernetes集群中安装或卸载chart
管理用Helm安装的chart的发布周期

Helm有三个重要概念：

chart：包含了创建Kubernetes的一个应用实例的必要信息
config：包含了应用发布配置信息
release：是一个chart及其配置的一个运行实例

Helm组件

Helm有以下两个组成部分：

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。

Helm实现

Helm client

Helm client采用go语言编写，采用gRPC协议与Tiller server交互。

Helm server

Tiller server也同样采用go语言编写，提供了gRPC server与client进行交互，利用Kubernetes client 库与Kubernetes进行通信，当前库使用了REST+JSON格式。
Tiller server 没有自己的数据库，目前使用Kubernetes的ConfigMaps存储相关信息

说明：配置文件尽可能使用YAM格式

欢迎转载，请注明作者出处：张夏，FreeWheel Lead Engineer，DockOne社区

分享 2017-09-14

2 个评论

kozawg

请教楼主，helm client 和服务端tiller通讯的问题：

我查tiller-deploy 只开放一个ClusterIP类型的服务: IP: 10.254.244.173，端口为:44134,这样的svc,helm client 应该不能访问服务端tiller。

请教楼主，helm client 是通过哪个地址和端口连接tiller服务的？还是经过apiserver的地址中转到tiller ?

mac-temp:test xxx$ kubectl get svc -n kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tiller-deploy 10.254.244.173 44134/TCP 4d

张夏

Helm Tiller有多种安装方式，比如本地安装或以pod形式部署到Kubernetes集群中。对于你所采用的pod安装形式:
我认为使用了Tiller service的clusterIp，然后helm client使用kubectl proxy连接。比如：http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/service_name[:port_name]/proxy

可以参考：Manually constructing apiserver proxy URLs：https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls

之所以得出上面的结论：
1. 通过helm init --dry-run --debug查看，暴露的是只有集群内部才能访问的ClusterIP，所以Helm client没有办法直连Tiller
2. helm client会读取”~/.kube/config”发现Kubernetes集群，并且使用默认的context。

我的理解是这样的，欢迎补充修正。

原文发布时间为：张夏

本文作者： 2017-09-19

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：简化Kubernetes应用部署工具-Helm简介