云原生应用设计模式之Operator模式详解 原创 精华

本文整理自51CTO开源基础软件学习季直播公开课《云原生应用设计模式之Operator模式详解》，更多细节，可点击链接跳转查看。

现代应用是分布式的，资源是统一管理的，那么能否由管理数据中心级别资源的平台向上提供API直接支持应用系统的构建，而不再基于机器模型/模式？云原生应需而生。

云原生发展如火如荼，大幅提升了业务系统的可用性、敏捷性和可扩展性。今天我们的分享以云原生应用设计模式概述为开端，然后，选择其中一种设计模式-Operator模式，结合代码演示，做详细讲解。

云原生应用设计模式

总结以往的工作经验，云原生应用设计模式大致可分为三种：基础模式、复杂模式和子模式。

• 基础模式：基于Kubernetes、Spring Cloud   等云原生平台构建，在大多应用里都很常见，如无状态服务模式、有状态服务模式 、服务网关 / API 网关模式，以及Operator模式等。
• 复杂模式：基础模式与多种技术相结合的模式，如服务网格模式（Istio） 、云-边协同模式（KubeEdge） 、Data Pipeline 模式（KubeFlow） ，以及Serverless 模式等。
• 子模式：在基础模式和复杂模式中都会涉及到的具有共性的模式，如Pod 模式（Sidecar模式 & initContainers模式） 、注册中心模式 、配置中心模式，以及基础设施即代码模式等。

以常见的注册中心模式为例，该模式在云原生应用构建中基本都会用到。服务发现是注册中心模式的主要应用场景，该场景中要解决的问题及注册中心模式在不同平台上的实现，如下图所示：

    注意：同一种模式在不同平台或框架中可能有不同的具体实现。

声明式 API 与 Operator 模式 

下面详细介绍下声明式API和Operator模式。在云原生计算基金会对“云原生技术”的定义中，将声明式API与容器、服务网格、微服务和不可变基础设施并列作为云原生技术的代表。

声明式API与与命令式API相对应，四大名著中孙悟空与诸葛亮改变天气的方法，很形象地体现了声明式API与与命令式API两者的区别。命令式 API向服务器发出执行命令：要做什么，而声明式 API表述的是：要得到什么样的结果。声明式API容许系统根据自己的逻辑，不断调整实际状态，直到与期望状态相一致，这个过程与用户解耦。

Kubernetes本身给出了很好的声明式API的示范，我们来看一个deployment的例子，如下图：

基于Kubernetes构建应用时，常会用到deployment，API很简单，用户只需要指定这个deployment由几个什么样的pods组成即可。至于这些pods如何创建出来，在哪个（哪些）节点运行，如何调度，节点出现故障时deployment如何容错等，用户不需要关心，完全由系统来实现，与用户接口解耦。

那么声明式API的后台逻辑在 Kubernetes是怎么的实现呢？是通过controller，与我们说的operator没有本质区别。controller不断地去看（watch）系统当前状态与用户所期望的目标状态是否有区别，如果有区别，那就会做出相应动作，调整系统当前状态，达到用户所希望的状态。后端controller的实现逻辑用户无需了解，controller升级更新用户也无感知。

我们也可以像Kubernetes这样，通过API Server，提供声明式API给用户，用户基于这些接口指定应用或被应用管理的某类资源需要达到的状态。后端operator及时获知状态变化，通过执行应用逻辑或调整资源，以达到用户指定的期望状态，这就是operator模式。

声明式API和Operator模式的主要应用场景，一般来说有如下四种情况：

一：对 K8s 的功能进行扩展，例如：CronHPA，kube-batch scheduler ；

二： 某些场景下 StatefulSet / DaemonSet 不能满足需求，例如：数据库、有状态中间件的维护，即DBaaS，XaaS；

三：需要感知底层资源，多见于分布式计算/并行计算场景，例如： Spark、TensorFlow，尤其注意老业务改造，用户自己写的分布式计算/并行计算系统云原生化； 

四：一些希望使用声明式 API 的新应用。

下面举一个例子：用于支持机器学习的tf-operator，通过它可以在Kubernetes上以云原生的方式运行基于TensorFlow的分布式训练。用户通过TFjob API，指定一次训练作业需要几个什么角色的节点（pods）即可。Pods的调度和创建、训练任务的启动和运行、训练结束后销毁pods回收资源等，都由tf-operator完成，用户不需要关注。

声明式API和Operator具体如何实现呢？

基于Kubernetes实现声明式API不需要从0构建一个完整的API Server，Kubernetes提供了一种被称之为CRD（Custom Resource Definition）的机制，可以对Kubernetes的API进行扩展，支持用户自定义资源。具体CRD的调用方式和实现效果如下图所示：

Operator的实现也很复杂，有很多工作需要进行，例如要维护各种状态变化事件的队列、还要应对各种冲突和故障、同时也要做好并发处理等等。为了让用户不必关注这些繁琐的底层细节，专注于operator逻辑的实现，社区提供了一些用于开发operator的SDK。其中KubeBuilder就是一个基于 CRD 构建 K8s operator 的SDK，方便用户从零开始开发 CRDs，controllers 和admission webhooks 来扩展 K8s及实现应用的operator。

基于Kubebuilder开发operator的流程如下： 

一、创建一个新的工程目录，并初始化；

二、用kubebuilder命令创建一个或多个资源 API CRD，然后将字段添加到资源代码中 ；

三、在控制器中编程实现协调循环（reconcile loop），watch 额外的资源 ；

四、运行测试（自动安装 CRD 并自动启动控制器） ；

五、更新引导集成测试，测试新字段和业务逻辑 ；

六、使用 Dockerfile 构建镜像和发布operator容器到集群。

此处结合了代码实操进行，每个步骤都有进行详细讲解，文字表示有限，更多细节内容，请观看视频：《云原生应用设计模式之Operator模式详解》。