基于Helm和Operator的K8S应用管理

大家好，今天我们分享的内容是基于Helm和Operator的K8S应用管理。

我们知道，Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统，需要组合使用大量的Kubernetes资源。针对有状态应用，常常还需要复杂的运维管理操作以及更多的领域知识。

今晚的分享就将介绍如何用Helm这一Kubernetes应用包管理的社区主导方案来简化应用的部署管理，如何制作应用模板以及打造Kubernetes版应用商店，以及如何利用operator自动化应用的运维。

---

我们知道在K8S社区里面，根据不同的领域，分成了不同的兴趣小组，英文叫SIG。今晚的话题属于APP这个领域。它们是为了解决K8S的应用管理里面的一些问题而生的。

一、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

# (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包，或者说你的远程仓库路径。 
对于应用的