基于Helm和Operator的K8S应用管理的分享

本文由3月7日晚李平辉，Rancher Labs 研发工程师所作的技术分享整理而成。
李平辉熟悉应用容器化解决方案设计和实施，熟悉持续集成方案，关注并参与K8S生态的发展，负责Rancher中国区持续集成服务研发。
搜索微信号RancherLabsChina，添加Rancher小助手为好友，可加入官方技术交流群，实时参加下一次分享~
  
  
   

你们好，今天咱们分享的内容是基于Helm和Operator的K8S应用管理。咱们知道，Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤为是微服务架构系统，须要组合使用大量的Kubernetes资源。针对有状态应用，经常还须要复杂的运维管理操做以及更多的领域知识。
  
今晚的分享就将介绍如何用Helm这一Kubernetes应用包管理的社区主导方案来简化应用的部署管理，如何制做应用模板以及打造Kubernetes版应用商店，以及如何利用operator自动化应用的运维。
    
咱们知道在K8S社区里面，根据不一样的领域，分红了不一样的兴趣小组，英文叫SIG。今晚的话题属于APP这个领域。它们是为了解决K8S的应用管理里面的一些问题而生的。
    

1、Helm

   

让咱们从零开始吧。好比说咱们如今已经部署了一个K8S的集群。无论是用GKE或者是EKS，都不是难事，由于如今部署K8S已经不是之前那么麻烦的事情了。而后咱们作了应用的容器化。接下来，咱们要试着去把咱们的应用部署到K8S上面去。
   
其实在K8S里面，资源对象是不少的：
 

 
对于一些微服务架构来讲，会有不一样的服务在上面运行，你可能要管理诸如deployment、service、有状态的Statefulset、权限的控制等等。你会发现，部署应用后还会有不少其余关联的东西以及你须要考虑的点：好比说你的不一样团队，要去管理这样一个应用，从开发到测试再到生产，在不一样的环境中，一样一套东西可能都须要不一样的配置。例如，你在开发的时候，不须要用到PV，而是用一些暂时的存储就好了；可是在生产环境中，你必需要持久存储；而且你可能会在团队之间作共享，而后去存档。
  
另外，你不只仅要部署这个应用资源，你还要去管理其生命周期，包括升级、更新换代、后续的删除等。咱们知道，K8S里面的deployment是有版本管理的，可是从整个应用或某个应用模块来考虑的话，除了deployment，可能还会有其余的configmap之类的去跟其关联。这时咱们会想，是否有这样一个工具能够在更上层的维度去管理这些应用呢？这个时候咱们就有了社区的一个包管理工具：Helm。
   
咱们知道K8S的意思是舵手，即掌控船舵的那我的。而Helm其实就是那个舵。在Helm里面，它的一个应用包叫Charts，Charts实际上是航海图的意思。它是什么东西呢？
   
它其实就是一个应用的定义描述。里面包括了这个应用的一些元数据，以及该应用的K8S资源定义的模板及其配置。其次，Charts还能够包括一些文档的说明，这些能够存储在chart的仓库里面。
 
怎么用Helm这个工具呢？Helm其实就是一个二进制工具。你只要把它下载下来，已经配置好了kubeconfig的一些相关配置信息，就能够在K8S中作应用的部署和管理了。
用Helm能够作什么事情呢？其实Helm分为服务端跟客户端两部分，你在helm init以后，它会把一个叫作Tiller的服务端，部署在K8S里面。这个服务端能够帮你管理Helm Chart应用包的一个完整生命周期。
   
Release == Chart 的安装实例：

接着说说Helm Chart。它本质上是一个应用包，你能够把它理解成dpkg或者像rpm这样的包。只不过，它是基于K8S领域的一个应用包的概念。你能够对同一个chart包进行屡次部署，每次安装它都会产生一个Release。这个Release至关于一个chart中的安装实例。
   
如今咱们已经把Tiller部署进去了，那么就能够去作咱们应用的管理了：

$ helm install <chart>
# (stable/mariadb, ./nginx-1.2.3.tgz, ./nginx, https://example.com/charts/nginx-1.2.3.tgz)
$ helm upgrade <release>
$ helm delete <release>

关于一些经常使用的命令例如安装一个应用包，能够用install，它实际上是能够支持不一样格式的：好比说本地的一些chart包，或者说你的远程仓库路径。
对于应用的更新，用Helm upgrade。
若是要删除的话，就用Helm Delete。
  
Helm的一个Release会生成对应的Configmap，由它去存储这个Release的信息，并存在K8S里面。它至关于把应用的一个生命周期的迭代，直接跟K8S去作关联，哪怕Tiller挂了，但只要你的配置信息还在，这个应用的发布和迭代历程不会丢失：例如想回滚到之前的版本，或者是查看它的升级路径等。
  
接下来咱们看一个chart的结构。
  
$ helm create demoapp

用Helm create的话，它会提供一个大概的框架，你能够去建立本身的一个应用。好比说这个应用就叫作Demoapp，里面会有以下内容：

其中最核心的是templates，即模板化的K8S manifests文件，这里面会包括资源的定义，例如deployment、service等。如今咱们create出来的是一个默认的、用一个nginx deployment去部署的应用。
   
它本质上就是一个Go的template模板。Helm在Go template模板的基础上，还会增长不少东西。如一些自定义的元数据信息、扩展的库以及一些相似于编程形式的工做流，例如条件语句、管道等等。这些东西都会使得咱们的模板变得很是丰富。
   
有了模板，咱们怎么把咱们的配置融入进去呢？用的就是这个values文件。这两部份内容其实就是chart的核心功能。

这个deployment，就是一个Go template的模板。里面能够定义一些预设的配置变量。这些变量就是从values文件中读取出来的。这样一来，咱们就有了一个应用包的模板，能够用不一样的配置将这个应用包部署在不一样的环境中去。除此以外，在Helm install/upgrade时候，可使用不一样的value。
   
配置选项：

$ helm install --set image.tag=latest ./demoapp
$ helm install -f stagingvalues.yaml ./demoapp
  
好比说你能够set某个单独的变量，你能够用整个File去作一个部署，它会用你如今的配置覆盖掉它的默认配置。所以咱们能够在不一样的团队之间，直接用不一样的配置文件，并用一样的应用包去作应用管理。Chart.yaml即chart的元数据，描述的就是这个chart包的信息。

另外还有一些文档的说明，例如NOTES.txt，通常放在templates里面，它是在你安装或者说你察看这个部署详情之时(helm status)，自动列出来的。一般会放一些部署了的应用和如何访问等一些描述性的信息。
 

 
除了模板之外，Helm chart的另外一个做用就是管理依赖。

 
好比说你部署一个Wordpress，它能够依赖一些数据库服务。你能够把数据库服务做为一个chart形式，放在一个依赖的目录下面。这样的话应用之间的依赖管理就能够作的很方便了。
假如如今已经建立了咱们本身的应用包，想要有一个仓库去管理这个包，在团队之间共享应该怎么作？
  
chart的仓库其实就是一个HTTP服务器。只要你把你的chart以及它的索引文件放到上面，在Helm install的时候，就能够经过上面的路径去拿。
  
Helm工具自己也提供一个简单的指令，叫Helm serve，帮你去作一个开发调试用的仓库。
  
例如 https://example.com/charts 的仓库目录结构：

  
关于 Helm，社区版其实已经有了不少的应用包，通常放在K8S下面的一些项目中，好比安装Helm时候，它默认就有一个Stable的项目。里面会有各类各样的应用包。Stable和incubator chart 仓库：https://github.com/kubernetes/charts
  
另外，社区版还会提供相似于Rancher Catalog应用商店的这样一个概念的UI，你能够在这上面作管理。它叫Monocular，即单筒望远镜的意思，这些项目的开发都很是的活跃，一直在随着K8S的迭代作着更新。
  
Monocular: chart的UI管理项目：https://github.com/kubernetes-helm/monocular

 
那么怎么去部署K8S版的应用商店呢？其实也很是简单。由于有了Helm以后，你只要使用Helm install这个Monocular，先把它的仓库加进来，再install一下，就能够把这个应用部署到你的K8S集群之中了。它其实也是利用了Helm Tiller去作部署。咱们能够在上面去搜索一些chart，管理你的仓库，例如官方的stable，或者是incubator里面的一些项目。

 
你也能够管理一些已经部署的应用。好比说你要搜索一个应用，点一下部署，就能够把它部署上去了。不过这其中还有不少亟待完善的东西，好比这里的部署不能配置各类不一样的参数，它只能输入namespace。其次，里面的一些管理依然存在局限性，好比不能很方便地在UI上作更新。
  
围绕Helm chart咱们也会跟一些公有云厂商有相关的合做。由于Helm chart的好处就是：一个应用包能够在多个地方部署。好比公有云的服务，能够基于它去实现应用的编排和管理，把一个服务便利地提供给不一样的用户。Rancher也会在2.0的应用商店中加入对helm chart的支持，但愿帮助用户在方便利用已有模板的同时提供良好的体验。
  
在stable的仓库里面已经有不少chart，其实并非特别完善，还有不少应用是能够补充和加强的。就咱们的实践经验来讲，什么均可以chart化，无论是分布式的数据库集群，仍是并行计算框架，均可以以这样的形式在K8S上部署和管理起来。
  
另一点就是Helm是插件化的，helm的插件有Helm-templates, helm-github，等等。
  
好比你在Helm install的时候，它能够调用插件去作扩展。它没有官方的仓库，可是已经有一些功能可用。实际上是把Restless/release的信息以及你的chart信息以及Tiller的链接信息交给插件去处理。Helm自己无论插件是用什么形式去实现的，只要它是应用包，则对传入的这些参数作它本身的处理就行。
  
Helm的好处，大概就有这些：
• 利用已有的Chart快速部署进行实验
• 建立自定义Chart，方便地在团队间共享
• 便于管理应用的生命周期
• 便于应用的依赖管理和重用
• 将K8S集群做为应用发布协做中心
  

2、Operator

  
咱们接下来讲说Operator。为何讲Operator呢？Operator其实并非一个工具，而是为了解决一个问题而存在的一个思路。什么问题？就是咱们在管理应用时，会遇到无状态和有状态的应用。管理无状态的应用是相对来讲比较简单的，可是有状态的应用则比较复杂。在Helm chart的stable仓库里面，不少数据库的chart实际上是单节点的，由于分布式的数据库作起来会较为麻烦。
  
Operator的理念是但愿注入领域知识，用软件管理复杂的应用。例如对于有状态应用来讲，每个东西都不同，均可能须要你有专业的知识去处理。对于不一样的数据库服务，扩容缩容以及备份等方式各有区别。能不能利用K8S便捷的特性去把这些复杂的东西简单化呢？这就是Operator想作的事情。
  
以无状态应用来讲，把它作成一个Scale UP的话是比较简单的：扩充一下它的数量就好了。
 

   

接着在deployment或者是说ReplicaSet的controller中，会去判断它当前的状态，并向目标状态进行迁移。对有状态的应用来讲，咱们经常须要考虑不少复杂的事情，包括升级、配置更新、备份、灾难恢复、Scale调整数量等等，有时至关于将整个配置刷一遍，甚至可能要重启一些服务。
   
好比像Zookeeper315之前不能实时更新集群状态，想要扩容很是麻烦，可能须要把整个节点重启一轮。有些数据库可能方便一点，到master那里注册一下就好。所以每一个服务都会有它本身的特色。
  
拿etcd来讲，它是K8S里面主要的存储。若是对它作一个Scale up的话，须要往集群中添加一些新节点的链接信息，从而获取到集群的不一样Member的配置链接。而后用它的集群信息去启动一个新的etcd节点。
  
若是有了etcd Operator，会怎么样？Operator实际上是CoreOS布道的东西。CoreOS给社区出了几个开源的Operator，包括etcd，那么如何在这种状况下去扩容一个etcd集群？
  
首先能够以deployment的形式把etcd Operator部署到K8S中。部署完这个Operator以后，想要部署一个etcd的集群，其实很方便。由于不须要再去管理这个集群的配置信息了，你只要告诉我，你须要多少的节点，你须要什么版本的etcd，而后建立这样一个自定义的资源，Operator会监听你的需求，帮你建立出配置信息来。
  
$ kubectl create –f etcd-cluster.yaml

 
 
要扩容的话也很简单，只要更新数量（好比从3改到5），再apply一下，它一样会监听这个自定义资源的变更，去作对应的更新。
  
$ kubectl apply -f upgrade-example.yaml

这样就至关于把之前须要运维人员去处理集群的一些工做所有都交付给Operator去完成了。如何作到的呢？即应用了K8S的一个扩展性的API——CRD（在之前称为第三方资源）。
  
在部署了一个etcd Operator以后，经过kubernetes API去管理和维护目标的应用状态。本质上走的就是K8S里面的Controller的模式。K8S Controller会对它的resource作这样的一个管理：去监听或者是说检查它预期的状态，而后跟当前的状态做对比。若是其中它会有一些差别的话，它会去作对应的更新。
  
Kubernetes Controller 模式：

  
etcd的作法是在拉起一个etcd Operator的时候，建立一个叫etcd cluster的自定义资源，监听应用的变化。好比你的声明你的更新，它都会去产生对应的一个事件，去作对应的更新，将你的etcd集群维护在这样的状态。
  
除了etcd之外，社区好比还有普罗米修斯Operator均可以以这种方便的形式，去帮你管理一些有状态的应用。
  
值得一提的是，Rancher2.0普遍采用了Kubernetes-native的Controller模式，去管理应用负载乃至K8S集群，调侃地说，是个Kubernetes operator。
 

3、Helm和Operator的对比

  这两个东西讲完了，咱们来对比一下两者吧。   Operator本质上是针对特定的场景去作有状态服务，或者说针对拥有复杂应用的应用场景去简化其运维管理的工具。Helm的话，它实际上是一个比较普适的工具，想法也很简单，就是把你的K8S资源模板化，方便共享，而后在不一样的配置中重用。  其实Operator作的东西Helm大部分也能够作。用Operator去监控更新etcd的集群状态，也能够用定制的Chart作一样的事情。只不过你可能须要一些更复杂的处理而已，例如在etcd没有创建起来时候，你可能须要一些init Container去作配置的更新，去检查状态，而后把这个节点用对应的信息给拉起来。删除的时候，则加一些PostHook去作一些处理。因此说Helm是一个更加普适的工具。二者甚至能够结合使用，好比stable仓库里就有etcd-operator chart。  就我的理解来讲，在K8S这个庞然大物之上，他们二者都诞生于简单但天然的想法，helm是为了配置分离，operator则是针对复杂应用的自动化管理。