爆款：K8S原生应用管理平台

• 本文的内容仅限于技术探讨，不能作为指导生产环境的素材；
• 鼓励读者购买红帽培训获得更多系统性的培训。

一、如何在K8S集群上部署应用？

首先，需要说明的是：Openshift是K8S集群，但K8S集群不是Openshift集群。K8S集群是Openshift集群的真子集。

在K8S集群上部署应用，有几种方式：

1.通过docker image方式部署

2.通过模板方式部署

3.在Openshift上，我们还可以基于S2I方式部署应用。

在K8S上除了需要部署应用，很多时候还要部署应用集群，对集群进行扩缩容等。这时候，我们大多是调整应用dc。嗯，听起来有一定技术含量。

那么，有没有一种方式，可以专门与K8S API集群对接，实现K8S原生应用的管理？

二、Operator

有，Operator就是。

Operator是一种打包、部署和管理Kubernetes原生应用程序的方法。 Kubernetes应用程序是一个部署在Kubernetes上并使用Kubernetes API和kubectl工具进行管理的应用程序。

Operator是为了解决一个问题而存在的一个思路。什么问题？就是我们在管理应用时，会遇到无状态和有状态的应用。管理无状态的应用是相对来说比较简单的，但是有状态的应用则比较复杂。

Operator的理念是希望注入领域知识，用软件管理复杂的应用。例如对于有状态应用来说，每一个东西都不一样，都可能需要你有专业的知识去处理。对于不同的数据库服务，扩容缩容以及备份等方式各有区别。能不能利用K8S便捷的特性去把这些复杂的东西简单化呢？这就是Operator想做的事情。

Operator本质上是针对特定的场景去做有状态服务，或者说针对拥有复杂应用的应用场景去简化其运维管理的工具。

听起来不错，但问题的关键点在于：

1.Operator的生态如何，到底能管多少个应用。2. Operator是开源，还是闭源厂商按照License或者支持的软件数量去收费？

Operator Framework是一个开源项目，由CoreOS发起的。2018年初CoreOS被红帽收购。Operator目前在Openshift上是TP的状态。相信很快就会正式GA。

Operator Framework提供开发人员和运行时Kubernetes工具，其框架包括三大架构：

它使开发人员能够基于他们的专业知识构建操作员，而无需了解Kubernetes API的复杂性。

管理在Kubernetes集群中运行的所有Operator（及其相关服务）的生命周期的安装，更新和管理。

Operator Metering：为提供专业服务的Operator启用使用情况报告。

三、Operator的生态

我们看一下目前Operator社区支持的应用，目前有45个，并且数量在持续增加中：

https://commons.openshift.org/sig/operators.html?from=timeline&isappinstalled=0

除了红帽列出的官方认证的应用种类，其实社区很多应用都在和operator对接，甚至如weblogic。这些都可以部署到Openshift上：

https://github.com/oracle/weblogic-kubernetes-operator

四、实验展现：couchbase

我自己的Openshift3.11实验环境中，部署了Operator组件：

我们先注册Opertor的订阅（实际上就是部署对应应用的Operator）

我们订阅Couchbase：

看到了吧，源在coreos:

创建Couchbase的订阅：

接下来，创建Couchbase Operator：

接下来，通过Operator部署couchbase集群：

查看运行状态：查看资源使用情况：

五、总结

一个软件，不开放就没有生态，没有生态就没有前途。

Operator能否“火”起来，主要取决于其在开源社区的普及程度。Ansible目前这么普及，在于其在开源社区的受重视程度和影响力。

从目前来看，红帽正在积极推动这个社区的发展。而很多软件提供商/开源软件项目也致力于与Operator对接。如Weblogic、Tensorflow等。

从目前看，我个人看到Operator这个开源项目。