随着 Kubernetes 应用越来越广泛，k8s管理的native对象资源有时不能满足用户的需求，以提高可扩展性 v1.7 以来，Kubernetes 引入了 CRD 机制（CustomResourceDefinition），简单地说，它允许用户定义他们的对象资源注册到集群，并通过自定义controller管理这些资源的生命周期，就像操作一样pod，deployment一些复杂的资源对象管理和运维也很方便。伴随着云原生的技术浪潮，lindorm-operator充分利用k8s在云环境(包括公共云、私有云和混合云)中，底座的特点和优势得到了极大的改善Lindorm数据库的生产运维效率。
本文以lindorm-operator以项目为例，深入介绍行深入介绍 Kubernetes 中基于 Operator 实现自定义资源对象和控制器的模式。
Lindorm部署结构演进史
Lindorm是云原生多模超融合数据库，为物联网、互联网、车联网等设计和优化，支持宽表、时序、文本、对象、流量、空间等数据的统一访问和整合。
Lindorm整个部署架构大致可分为三个阶段，On 物理机--> On ECS --> On K8S ,大多数早期输出都是on 2020年公有云商业化时，物理机的部署形式开始出现On ECS形式输出，虽然服务全面上云，然而，云原生化在整个架构上并没有得到充分的发展。到2021年左右，云原生化开始全面拥抱混合云输出形。所有组件On k8s生产层只依赖部署Operator，实现云原生化的真正意义。虽然发展时间不长，但控制架构基本走在前列，充分吸收了云原演变道路上的红利Lindorm生产效率越来越高。虽然发展时间不长，但控制架构基本走在前列，充分吸收了云原演变道路上的红利Lindorm生产效率越来越高。本文不重点介绍其他两种形式，主要介绍On k8s设计细节和实践模式。
Operator技术体系
Operator 可以看成是 CRD 和 Controller 组合特例，Operator 是特定应用程序的控制器，通过扩展 Kubernetes API 资源以代表 Kubernetes 通常通过资源模型定义和控制器，用户创建、配置和管理复杂应用程序的例子 Operator 它通常是为了实现特定软件（通常是状态服务）的自动操作和维护。
controller基本工作原理：
上图显示 controller 工作原理，实际上是事件监控变更的循环过程，以一个pod变更为例，如下图所示go-client核心组件和我们的controller如何配合工作：
go-client初始化时，Reflector 会先 List API 获得所有的 Pod，并放入本地缓存Informer 初始化完成后，Reflector 开始监听 Pod变更相关时间；如果此时 pod_1 被删除，那么 Reflector 会监听到这一事件Reflector 将 pod_1 被删除 事件callbacks通过本地队列(DeltaFIFO) 存入workqueueworker(其实是我们的业务。controller）从队列中 取出事件处理Controller 通过比较资源对象的实际状态终状态的差异，执行业务逻辑，不断调整到最终状态。虽然client-go已经封装了 controller-runtime 和 controller-tools，用于快速施工 Operator，但从零开始构建一个 CRD 控制器不容易，需要 Kubernetes 的 API 深入了解，还需要自己实现和api-server一些互动细节。为了解决这个问题，社区推出了相应的简单易用 Operator 框架，更主流的是 kubebuilder 和 Operator Framework，这两个框架的使用基本上没有太大区别。我们可以根据自己的习惯选择一个。
Lindorm Operator问题与挑战Lindorm以前的部署形式是On ecs是的，基于控制架构pengine，实例的生命周期管理是通过任务流安排来实现的，这个架构需要控制侧感知很多调度细节。而Lindorm和Operator结合资源调度、节点弹性伸缩能力、安全隔离等特点K8S充分利用云原生技术红利实现集群Lindorm CR定义和一个Operator组件可以在各种复杂的环境中轻松交付lindorm实例。为了实现这一目标，需要从设计、开发、构建、部署、交付、监控交付、监控构建、部署、交付、监控和运维。从Lindorm从集群本身的管理来看，核心要求如下:
体验升级： 实例创建、监控报警、排障定位等。需要平稳简单，整个过程比以前更有效、更灵活。 根据业务负载灵活动态分配或释放资源容错&安全性：停机迁移、故障隔离、负载平衡等可观察性：丰富细粒度监测指标，多形式集群兼容性可持续提供查询：目前Lindorm形式非常丰富，有单机版、集群版、多可用区版，基于存储池serverless一套版本operator在架构下实现多种形式的安排虽然K8S为我们提供了基础workload、存储、网络调度和管理能力，但是如何充分利用这些能力呢？Operator挑战，LindormOperator是集群中实例生命周期管理和运维的入口，Lindorm集群的生产、运维是Operator合理安排调度K8S实现了原生资源，如下图所示operator会持续监听K8S原生资源和Lindorm 路由知识 CR状态变化，并通过不断的反应行动做出反应reconcile使Lindorm集群最终达到了我们想要的状态，所以operator是Lindorm关于生产层的关键组件，关于workload，存储相关技术方案的选择和思考直接影响Lindorm性能是否在K8S充分发挥这些问题和挑战绍这些问题和挑战lindorm-operator一些主要的设计逻辑和技术选择思考。
技术方案
整体架构
Lindorm物理机器的部署架构经历了 -> 虚拟化(On ecs) -> 云原生化(On k8s)目前公有云的销售形式是逐渐演变的On ECS，基于存储池的公共云On K8s云原生架构也将上线，如下图所示:
其中，LindormCluster 是由 CRD（CustomResourceDefinition）用于描述用户期望的自定义资源 Lindorm 集群状态， 以下组件负责集群的安排和调度逻辑：
Lindorm-Controller是一组 Kubernetes 自定义控制器。这些控制器将继续比较 LindormCluste 对象中记录的期望状态和期望状态 Lindorm 调整集群的实际状态，调整集群的实际状态 Kubernetes 驱动资源 Lindorm 集群满足预期状态；Lindorm-webhook 路由知识 是一个 Kubernetes api的拦截器，外部传入Lindorm CR做一些参数验证或增加默认参数配置，也可以拦截一些高级操作，如集群释放。实例部署拓扑&生命周期管理
为了保证核心组件架构的一致性，实例资源的安排必须以部署拓扑为基础，On K8S结构下核心组件的部署拓扑与公共云目前的销售形式基本一致，如下图所示：
通过修改实例创建和弹性变配Lindorm CR实现，只要通过kube api修改起来很方便Lindorm从控制和运维的角度来看，资源有着一致的经验，可以避免许多重复建设的工作。Lindorm每个组件的交互逻辑在实例变。
以实例生产和变更流程为例，说明内部流程：
用户通过API Server CURD LindormCluster，可以是客户端kubectl，也可以是其他形式k8s ClientLindormCluster controller 根据用户写入LindormCluster，依赖关系 分别创建出LindormZK, LindormStore ，LindormTable, LindormTSDB, LindormSearch资源子资源Controller 所需的组合configMap， StatefulSet， CommonService， HeadlessService， Ingress， 并依次创建这些资源。子资源的controller 监听 各自资源（statefulSet, service,ingress) 的状态, 并通过API Server更新到etcdLindormCluster Cluster 接受子资源的更新event，更新Lindorm Cluster 的Status，通过API Server 更新的etcd用户通过GET LindormCluster/status 获取全集群状态信息核心设计要点
将Lindorm从部署拓扑的角度拆分资源，每个组件都是独立的Controller，这样，组件间的事件相互独立，提升reconcile流程稳定性；Lindorm CRD尽量简化定义，只暴露与资源相关的参数，将编排细节聚集在一起Operator充分利用内部K8S实现调度策略pod打散，保证同类发动机的打散pod分散在不同pod，避免因少量节点异常导致计算机引擎服务异常而关闭状态服务驱逐策略pod漂移，这样可以尽这样做pod被删除的风险架构优势
节约成本通过Operator调度具有更高效的资源分配能力。通过存储池调度，可以大大降低存储成本体验，大大降低升级交付成本，实现标准化交付流程，屏蔽底部硬件，降低运维成本。当节点异常时，可以通过pod漂移重布解决实例生产速度和效率大大提高，用户感觉更好地充分利用基础调度能力，控制调度逻辑更清晰，使开发更加光滑，降低复杂性，提高控制开发迭代效率，减少组件依赖，减少无复杂元数据依赖关系思考技术选择
Lindorm作为数据库产品，迁移到k8s在这个过程中也遇到了很多问题，因为k8s调度设计对无状态服务自然友好，但对于Lindorm这种重型存储产品将面临许多挑战，以下是workload，介绍存储和网络三个方面lindorm在k8s实践中的一些思考。
Workload选型
在谈workload在选择之前，我们可以考虑重存储和状态服务对部署的基本要求。在我看来， 主要有四个基本特征：
(1) 网络稳定： Pod要有稳定的网络标识，因为这些数据可能会持久；
（2) 稳定存储： 存储不随pod状态变化发生变化；
(3) 安全可控升级：灰度可控升级重启；
(4)操作维护可控:指定pod具有状态节点运维的升级能力将涉及节点主切换，需要按需升级
K8S内置了 Pod、Deployment、StatefulSet 等负载类型(Workload)。 Pod是k8s由共享网络、数据卷等资源组成的最小调度和部署单位。通过 Pod 然而，业务流程集成成功， Pod 为了解决上述挑战，本身不具备高可用性、自动扩缩容、滚动更新等特点，Kubernetes 提供更先进的 Workload，主要有Deployment和Statefuleset，前者主要生成无状态服务场景pod名称变化，不稳定 网络
