所属技术领域：
K8s
|名词定义|
Operator Framework给用户提供了webhook和controller框架，包括消息通知、失败重新入队等等，开发人员仅需关心被管理应用的运维逻辑实现
主流的Operator Framework项目
-kubebuilder：https:github.com/kubernetes-sigs/kubebuilder
-operator-sdk：https:github.com/operator-framework/operator-sdk
-两者没有本质上的区别，都是使用的controller-tools和controller-runtime。细节上kubebuilder相应的测试、部署、代码生成脚手架更完善，如Makefile和Kustomize等工具的集成；operator sdk则支持与ansible operator 、operator Lifecycle Manager的集成
|技术特点|
Operator Framework
Operator Framework 同样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：
--Operator SDK:集成controller-runtime，提供了：编写运维逻辑的高阶API，快速构建Operator项目及代码生成的脚手架工具，覆盖常见Operator用例的扩展。Operator SDK是Operator Framework中最核心的工程。
--Operator Lifecycle Manager : K8S集群内所有Operator(及其关联服务)的生命周期管理（ installation, updates, and management ）
SDK提供了用于构建，测试和打包操作员的工具。最初，SDK促进了应用程序的业务逻辑（例如，如何扩展，升级或备份）与Kubernetes API的结合，以执行那些操作。随着时间的推移，SDK可以使工程师使应用程序更智能，并拥有云服务的用户体验。SDK中包含在操作员之间共享的领先实践和代码模式，以帮助防止重新发明轮子。
Workflow
Operator SDK 提供以下工作流来开发一个新的 Operator：
-使用 SDK 创建一个新的 Operator 项目
-通过添加自定义资源（CRD）定义新的资源 API
-指定使用 SDK API 来 watch 的资源
-定义 Operator 的协调（reconcile）逻辑
-使用 Operator SDK 构建并生成 Operator 部署清单文件
Demo
我们平时在部署一个简单的 Webserver 到 Kubernetes 集群中的时候，都需要先编写一个 Deployment 的控制器，然后创建一个 Service 对象，通过 Pod 的 label 标签进行关联，最后通过 Ingress 或者 type=NodePort 类型的 Service 来暴露服务，每次都需要这样操作，是不是略显麻烦，我们就可以创建一个自定义的资源对象，通过我们的 CRD 来描述我们要部署的应用信息，比如镜像、服务端口、环境变量等等，然后创建我们的自定义类型的资源对象的时候，通过控制器去创建对应的 Deployment 和 Service，是不是就方便很多了，相当于我们用一个资源清单去描述了 Deployment 和 Service 要做的两件事情。
这里我们将创建一个名为 AppService 的 CRD 资源对象，然后定义如下的资源清单进行应用部署：
apiVersion: app.example.com/v1
kind: AppService
metadata:
name: nginx-app
spec:
size: 2
image: nginx:1.7.9
ports:
- port: 80
targetPort: 80
nodePort: 30002通过这里的自定义的 AppService 资源对象去创建副本数为2的 Pod，然后通过 nodePort=30002 的端口去暴露服务，接下来我们就来一步一步的实现我们这里的这个简单的 Operator 应用。
|资料来源|
名词定义：https://blog.csdn.net/bbwangj/article/details/82355337
技术特点：https://www.jianshu.com/p/628aac3e6758
