本文讲的是
简化Kubernetes应用部署工具-Helm简介【编者的话】微服务和容器化给复杂应用部署与管理带来了极大的挑战。Helm是目前Kubernetes服务编排领域的唯一开源子项目，做为Kubernetes应用的一个包管理工具，可理解为Kubernetes的apt-get / yum，由Deis 公司发起，该公司已经被微软收购。Helm通过软件打包的形式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用部署和管理的复杂性。
随着业务容器化与向微服务架构转变，通过分解巨大的单体应用为多个服务的方式，分解了单体应用的复杂性，使每个微服务都可以独立部署和扩展，实现了敏捷开发和快速迭代和部署。但任何事情都有两面性，虽然微服务给我们带来了很多便利，但由于应用被拆分成多个组件，导致服务数量大幅增加，对于Kubernetest编排来说，每个组件有自己的资源文件，并且可以独立的部署与伸缩，这给采用Kubernetes做应用编排带来了诸多挑战：
而Helm恰好可以帮助我们解决上面问题
Helm把Kubernetes资源(比如deployments、services或 ingress等) 打包到一个chart中，而chart被保存到chart仓库。通过chart仓库可用来存储和分享chart。Helm使发布可配置，支持发布应用配置的版本管理，简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。
本文简单介绍了Helm的用途、架构与实现。
Helm有三个重要概念：
Helm Client是用户命令行工具，其主要负责如下：
Tiller server主要负责如下：
简单的说，client管理charts，而server管理发布release。
Helm server
说明：配置文件尽可能使用YAM格式
欢迎转载，请注明作者出处：张夏，FreeWheel Lead Engineer，DockOne社区
随着业务容器化与向微服务架构转变，通过分解巨大的单体应用为多个服务的方式，分解了单体应用的复杂性，使每个微服务都可以独立部署和扩展，实现了敏捷开发和快速迭代和部署。但任何事情都有两面性，虽然微服务给我们带来了很多便利，但由于应用被拆分成多个组件，导致服务数量大幅增加，对于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社区
2 个评论
请教楼主，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 <none> 44134/TCP 4d
我查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 <none> 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。
我的理解是这样的，欢迎补充修正。
我认为使用了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简介
