Kubernetes里的Operator

Kubernetes里的Operator

Kubernetes作为一个“容器编排”平台，其核心是对资源对象进行”编排“，而控制器(controller)则负责此工作。Kubernetes的核心组件controller-manager管理controllers,不同的controllers各自和APIServer通信，获取新的状态，对系统进行"修正"。

Kubernetes中内置了Deployment，StatefulSet，Job、Cronjob等丰富的编排对象，但在实际使用中，面对纷繁复杂的应用场景，尤其是针对etcd、Redis、ES、PG、openGauss等复杂的有状态应用，现有的编排对象在面对这些应用的如主从配置、集群扩缩容等需求时显得力不从心。Kubernetes在v1.7版本引入了CRD(Custom Resource Definition)，允许用户将应用的复杂需求抽象成自定义资源对象并且做到像原生对象一样操作它们。

Kubernetes Controller开发框架注册CRD，可使得自定义资源被Apiserver识别并存储在etcd中，而为了对资源进行操纵以满足实际需求则需要开发针对自定义资源的controller。在Kubernetes客户端，如client-go，包含了可便捷开发controller的现成框架。

Operator本质为CRD（CR）+ Controller。无论是外部厂商的Operator还是自研的Operator均遵循该模式。要设计一个统一的容器数据库模型，可以放在集群外部做模型转化适配，也可以放在集群内部做模型转化适配。自研的Operator可以直接复用这一套容器数据库模型。最终选择使用CRD承载结构体定义，在靠近数据库Operator侧进行模型转化适配。

Operator通过扩展Kubernetes定义Custom Controller，观察应用并根据实际状态执行自定义任务。应用被定义为Kubernetes对象：Custom Resource （CR），它包含yaml spec和被API服务接受对象类型（K8s kind）。这样，您可以在自定义规范中定义要观察的任何特定条件，并在实例与规范不匹配时协调实例。虽然Operator controller主要使用自定义组件，但它与原生Kubernetes controller协调方式非常类似。Operator通过Custom Controller协调应用spec。虽然API服务知道Custom Controller，但Operator可以独立运行在集群内部或外部。

参考链接https://linux.com/topic/cloud/demystifying-kubernetes-operators-operator-sdk-part-1/