所属技术领域:
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