当国产数据库遇上云原生深入解读 KES-Operator让 KES 集群真正长在 Kubernetes 上一、写在前面数据库上云的最后一公里过去几年云原生的浪潮几乎重塑了整个软件基础设施的形态。微服务、容器化、DevOps这些曾经的前沿概念如今已经成为绝大多数业务系统的默认选项。而作为这一切底座的 Kubernetes也早已从一个容器编排工具成长为事实上的数据中心操作系统——计算、存储、网络、调度所有资源都收敛到了一套统一的 API 体系之下。应用为了适配这套体系纷纷完成了容器化改造。但有一类软件的改造始终没有那么顺利那就是数据库。作为典型的有状态应用数据库进入 Kubernetes 环境之后如何适配 Kubernetes 的管理方式给原有的运维模式带来了全新的要求。在传统的虚拟机或者物理机环境中数据库集群的管理已经是一套成熟的体系DBA 装库、建集群、配置流复制、写监控脚本、定期做备份演练。而一旦迁入 Kubernetes数据库集群管理就不再只涉及数据库自身还需要协调计算、存储、网络等一系列相关的资源对象——Pod 怎么编排、存储卷怎么挂载、服务怎么暴露、节点宕掉之后主备怎么切换每一个环节都要和 Kubernetes 的资源模型对齐。随着集群规模的扩大如果这些工作依然依赖人工逐项完成——写 YAML、起 Pod、配存储、盯状态——操作的复杂度和出错概率都会快速上升。数据库团队的运维经验如何沉淀到集群内部变成 7×24 小时不眨眼的自动化能力这正是 Operator 模式要解决的问题。针对用户在 Kubernetes 环境下管理金仓 KESKingbaseES集群的实际需求电科金仓正式推出了 KES K8s 运维工具——KES-Operator。它基于 Kubernetes Operator 技术和声明式管理方式将 KES 集群纳入 Kubernetes 管理体系提供集群部署、状态管理、扩缩容、物理备份等能力让用户可以按照 Kubernetes 原生的管理方式完成 KES 集群的部署和日常运维。这篇文章我们不打算停留在功能列表的罗列上而是从技术原理出发把 KES-Operator 的架构设计、核心能力和运维范式变迁拆开揉碎讲清楚看看数据库交给 Kubernetes 管这件事到底是怎么发生的。二、老问题为什么数据库是 Kubernetes 上最难管的住户要理解 KES-Operator 的价值得先理解数据库在 Kubernetes 上的管理为什么难。这个问题的根源在于Kubernetes 最初是为无状态应用设计的而数据库是典型的有状态应用。2.1 无状态应用的幸运对于一个无状态的 Web 服务Kubernetes 的管理模型非常简单Pod 挂了就重建一个任何一个副本都可以随时被替换反正它们彼此完全等价数据要么不存在要么在外部的 Redis、对象存储里。Deployment 控制器只需要维护副本数这一个数字就能把整个系统管理得井井有条。2.2 有状态应用的四座大山数据库完全不同。一个 KES 集群通常由一个主节点和若干备节点组成备节点通过流复制从主节点同步数据。这套拓扑结构一旦跑进 Kubernetes就会立刻撞上四座大山第一座山网络身份。数据库主备复制要求每个节点拥有稳定、可预期的网络标识。备节点要始终知道主节点在哪主节点切换后所有备节点要能跟上新的主。而原生 Pod 的 IP 和主机名都是随机的重启一次就面目全非。第二座山存储生命周期。数据库的数据必须落盘而且每个节点的数据盘是独立的、专属的。Pod 被重新调度到另一个节点时它的数据卷必须跟着走节点被删除时磁盘又不能被误删。PVC持久卷声明与 Pod 的绑定关系需要非常小心地维护。第三座山拓扑约束。数据库节点不是对等的主节点只有一个备节点可以多个扩容一个备节点要先从主节点做一次全量基础备份再增量追赶缩容时又不能随手删掉主节点。这些先后顺序和约束条件是 Deployment 控制器完全不理解的知识。第四座山故障恢复的专家经验。主节点宕机后如何选出新主如何防止旧主恢复后出现双主脑裂备节点数据落后太多怎么办这些判断和处理逻辑过去都装在资深 DBA 的脑子里写在一篇篇应急预案文档里。Kubernetes 自带的控制器不懂这些它只会机械地把 Pod 拉起来而不知道拉起来之后该让它当主还是当备。这四座大山就是数据库不敢直接上 K8s的根本原因也是所有数据库 Operator 试图翻越的地方。三、Operator 模式Kubernetes 的自我进化Operator 这个概念由 CoreOS 的工程师在 2016 年提出最初的实践是 etcd Operator。它的核心思想用一句话概括就是“An Operator is a software extension to Kubernetes that makes use of custom resources to manage applications and their components.”—— Operator 是 Kubernetes 的软件扩展通过自定义资源Custom Resource来管理应用及其组件。这句话里藏着两个关键技术点值得展开讲讲。3.1 CRD给 Kubernetes 的 API 增加新词汇Kubernetes 的 API Server 维护着一整套资源类型Pod、Service、ConfigMap、StatefulSet……每一种资源都是一句声明。但 Kubernetes 并不认识数据库集群这种概念——没有任何一个内置资源叫KesCluster。CRDCustom Resource Definition自定义资源定义解决了这个问题。通过 CRD用户可以向 API Server 注册全新的资源类型让KES 集群成为 Kubernetes 世界里的一等公民。注册之后你就可以像操作 Pod 一样操作它# 一个示意性的声明描述我要一个什么样的 KES 集群kubectl apply-fkingbase_deploy.yaml# 像查看原生资源一样查看 KES 集群状态kubectl get kesclusters这就是声明式 API 的本质用户不再描述操作步骤而是描述期望结果。你不需要告诉系统先创建这个、再配置那个、然后启动什么你只需要说我要一个三节点的 KES 集群版本是 V009R001C010PS009存储 100Gi剩下的交给控制器。3.2 控制循环向期望状态持续收敛的永动机光有资源定义还不够得有人来兑现这些声明。这个人就是控制器Controller而它的工作方式是一个永不停歇的闭环业内俗称Reconcile Loop调谐循环观察Observe→ 比对Diff→ 执行Act→ 再观察……观察通过 ListWatch 机制监听 API Server 上自定义资源的变化事件同时读取集群的实际运行状态比对把用户声明的期望状态和集群的实际状态放在一起对比算出差异执行针对差异执行协调动作——该建 StatefulSet 建 StatefulSet该挂 PVC 挂 PVC该拉起新备节点就拉起新备节点循环然后回到观察直到实际状态与期望状态收敛一致。这个循环的美妙之处在于幂等与自愈无论系统因为什么原因偏离了目标——节点宕机、误操作、网络抖动——控制循环都会在下一次调谐时发现偏差并自动把系统拉回正轨。用户声明的期望状态成了整个系统永恒的引力中心。3.3 Operator把 DBA 的经验装进集群把 CRD 和控制循环组合起来再注入特定领域的运维知识就得到了 Operator。一个数据库 Operator 相当于把资深 DBA 的运维经验编译成了代码以 Pod 的形式部署在集群内部7×24 小时值守。部署怎么做、主备怎么切换、扩容怎么编排、备份怎么执行这些知识不再依赖值班人员的临场发挥而是变成了机器执行的确定性逻辑。KES-Operator 正是这一模式在金仓 KES 上的完整落地。四、KES-Operator 架构解析它是如何嵌进 Kubernetes 的上图是 KES-Operator 的整体架构我们可以自上而下拆解。交互入口层。图的最上方是两个入口REST API 和 kubectl/CLI。这延续了 Kubernetes 的一贯设计——所有操作最终都汇入 API Server。无论你是用脚本调用 REST 接口还是运维人员敲kubectl命令操作的都是同一套资源对象地位完全对等。这意味着 KES 集群的管理动作可以无缝融入企业现有的 K8s 自动化流水线CI/CD 工具、发布系统、审计系统全部照常工作。Kubernetes 控制平面。图的中部是 Kubernetes Master包含 Controller Manager、API Server 和 Scheduler 三个核心组件。值得强调的是KES-Operator 并不绕开这些原生组件而是站在它们之上工作——它自己也是一个部署在集群里的工作负载通过监听 CRD 事件图中橙色箭头感知用户的配置变更。KingbaseES Operator 本体。图右侧红色的 KingbaseES Operator 是整个体系的大脑。它持续监听 CRD 事件一旦发现用户创建或修改了 KES 集群的自定义资源就立刻进入调谐循环根据期望状态与实际状态的差异执行调度 Pod图中绿色箭头等一系列协调动作——创建 StatefulSet 管理数据库节点、申请存储卷、维护主备拓扑。数据平面KES 集群本体。图的中下部是 Kubernetes Node 层。可以看到KES 集群的各个数据库实例以 Pod 形态分布在多个 Node 上图中 Node1 上有 Pod-0、Pod-1 到 Pod-N 的序列NodeX 上同样部署了一组 KES Pod每个 Node 上由 kubelet 负责容器生命周期、dns 负责服务发现。Pod 编号序列体现了典型的 StatefulSet 特征——每个数据库实例拥有稳定、有序、可预期的身份标识这正是第二部分提到的网络身份问题的标准解法。存储层。图的最底部是存储卷。数据库的数据持久化在独立的存储卷上Pod 的销毁与重建不会影响数据重建后的 Pod 重新挂回原来的卷数据原样归来。整个架构可以概括为一句话用户声明期望 → API Server 记录声明 → Operator 监听并调谐 → 原生资源StatefulSet/PVC/Service落地 → KES 集群按需运行。数据库的运维知识全部收敛在 Operator 这一层而对用户暴露的是纯净、标准的 Kubernetes 使用体验。五、能力一自动化部署让 KES 集群快速运行上面这组动图展示了 KES-Operator 的部署现场管理员登录到 K8s 管理节点图中终端为k8s-204对应 KingbaseES V009R001C010PS009 x86_64 的部署目录目录里可以看到三个关键的 YAML 清单文件all_crd.yaml—— 注册 KES 集群相关的自定义资源定义kingbase_deploy.yaml—— 描述要部署的 KES 集群的期望状态节点数、版本、存储等kingbase_backup.yaml—— 定义备份相关的配置。在 Kubernetes 环境中数据库集群部署原本涉及多个资源对象的配置——StatefulSet、Service、PVC、ConfigMap、Secret环环相扣漏一个都起不来。而 KES-Operator 采用声明式管理方式把这些复杂性全部封装用户只需通过配置文件定义 KES 集群的期望状态执行kubectl apply提交配置完成后由 KES-Operator 自动创建所有相关资源。从提交那一刻起一系列动作在集群内部自动展开API Server 接收并持久化集群声明 → Operator 监听到事件开始调谐 → 按声明创建 StatefulSet 与对应的存储卷 → Scheduler 把各个数据库 Pod 调度到合适的 Node → kubelet 拉起容器 → KES 实例完成初始化 → 主备复制关系自动建立 → 服务就绪。人工逐项配置的过程被压缩成了一份 YAML 和一条命令。更重要的是这份 YAML 本身就是集群的文档——它精确记录了集群的期望形态可评审、可版本化、可重复执行部署结果不再因人而异。六、能力二持续状态管理让数据库集群保持目标状态部署只是起点运行过程中的状态维护才是日常工作的重头。上面这组动图展示的是进入 KES 数据库 Pod 内部kingbase-cluster-kingbase-0正是 StatefulSet 分配的稳定节点标识进行状态核查的场景。KES-Operator 通过 Kubernetes 控制器机制持续监测数据库集群的实际运行状态并与用户定义的期望状态进行比对。这个机制的意义在于它管的不只是Pod 死没死这么粗粒度的问题而是数据库视角的集群健康实例级自愈某个 KES Pod 意外退出控制器检测到实际副本数低于期望自动重建并重新接入集群拓扑主备角色维护集群的期望状态里写着谁是主、谁是备当实际角色分配与声明出现偏差时Operator 按配置协调相关资源恢复正确的复制拓扑配置一致性用户修改了集群配置如资源额度、参数Operator 感知到声明变更后逐步将实际状态调整到新目标。这套机制的价值可以用一句话总结期望状态一旦声明维护它就不再是运维人员的任务而是系统的本能。过去需要值班人员定时巡检、手工比对的日常工作现在由控制循环 7×24 小时自动执行人工检查和被动救火的次数大幅减少。对运维团队来说这也是一种心理上的解放——数据库集群从需要时刻盯着的婴儿变成了会自己吃饭的成熟系统人的精力终于可以投向容量规划、性能优化这些更高价值的工作。七、能力三灵活扩缩容满足业务变化需求业务有波峰波谷数据库资源需求自然也要随之调整。上面这组动图展示的是扩缩容后的集群拓扑核查管理员在 KES 节点内执行/opt/kingbase/bin/repmgr cluster show直接查看集群当前的复制拓扑与各节点角色状态——新增的节点是否已加入、复制关系是否健康一目了然。KES-Operator 支持KES 集群的扩容与缩容管理。用户根据实际需求调整集群节点规模修改集群配置即修改自定义资源中的期望状态后KES-Operator 根据新的配置自动完成相应的资源调整。这个看似简单的能力背后是 Operator 对数据库拓扑知识的完整理解扩容时它不是简单地多拉一个 Pod 了事。新节点要经过完整的入伙流程申请独立存储卷 → 启动 KES 实例 → 从主节点建立复制通道 → 追平数据 → 正式纳入集群提供服务。顺序不能错状态没就绪之前不能对外。缩容时它同样懂得规避风险先确认目标节点不是主节点或者先执行主备切换再安全摘除节点、回收复制关系最后清理对应的 Kubernetes 资源避免出现主节点被误删这类灾难性事故。对比一下传统做法虚拟机环境里扩容一个数据库备节点通常要走申请资源、装库、配复制、全量恢复、验证、接入监控等一长串人工流程周期以天计而在 KES-Operator 的管理下这变成了一次配置修改分钟级完成。弹性不再只是无状态应用的专利有状态的数据库集群也拥有了随业务伸缩的能力。八、能力四物理备份与监控管理要保障数据库长期稳定运行除了日常状态管理还必须有完善的数据保护与可观测能力。KES-Operator 在这两个方向上同样给出了体系化的答案。8.1 物理备份数据安全的最后防线KES-Operator 支持 KES 物理备份管理用户可以通过配置创建和管理备份任务。这里强调物理备份是有讲究的。相比导出 SQL 的逻辑备份物理备份直接对数据库的物理存储做一致性拷贝恢复时可以直接将数据库还原到指定时间点而不是重放一遍建库脚本。对于动辄几百 GB、上 TB 的生产库物理备份在恢复速度和完整性上都有不可替代的优势——它是数据库故障恢复的最后防线。更关键的是备份任务本身也被纳入了 Kubernetes 的声明式管理体系备份策略以配置形式声明创建、调度、执行、清理由 Operator 统一管理。备份不再依赖某台备份机上的 crontab 和一堆散落的脚本备份策略即代码随集群配置一起被版本化管理永远不会出现备份脚本在哪台机器上没人说得清的尴尬。8.2 KMonitor 监控看得见的健康状态KES-Operator 同时支持 KMonitor 监控组件管理用于查看 KES 集群的运行状态。上面这张监控大盘截图信息量很大我们可以逐块解读资源水位CPU 使用率9.2%、内存使用率34.3%、CPU 核数20、物理内存总量38.9 GiB、CPU iowait4.0%——实时掌握宿主资源消耗iowait 指标对数据库尤其敏感它往往是磁盘瓶颈的第一信号运行时长与授权服务器运行时长13 week、数据库运行时长、授权有效期90 天——授权临期提前可见避免业务中断集群拓扑健康数据库节点信息表清晰列出节点角色——node61为standby活备、node62为primary主节点两个节点的复制状态均为活跃整体流复制状态健康。主备拓扑是否正常一眼可判容量趋势整体总容量与平均 CPU/内存/磁盘使用率的历史曲线——容量规划从拍脑袋变成看曲线业务吞吐QPS TPS 实时曲线、每秒各类 DML 语句影响行数——数据库到底忙不忙、忙在什么类型的操作上有了量化依据。这些监控信息与备份任务一样都收敛在 Kubernetes 环境中统一管理。部署、状态、扩缩容、备份、监控五类运维动作从此有了同一个入口、同一套范式。九、范式之变从跑脚本到改配置把前面的能力串起来看KES-Operator 带来的不只是几个新功能而是一次运维范式的迁移。我们把新旧两种模式放在一起对比运维场景传统人工模式KES-Operator 模式部署集群装库、建复制、配服务逐台手工操作编写一份集群声明 YAMLkubectl apply一键拉起日常巡检登录各节点手工检查、盯监控告警控制循环持续比对期望/实际状态偏差自动修复扩缩容申请资源→装库→建复制→验证以天计修改 replicas 配置分钟级自动完成入伙/摘除故障恢复值班人员按应急预案手工处置系统自动重建/切换按声明收敛回目标状态备份管理备份机上散落的 crontab 脚本声明式备份任务统一创建、调度与清理监控查看多套工具拼凑、口径不一KMonitor 统一大盘与集群同体系管理对比的核心差异在于知识的位置传统模式下运维知识存在于人脑、文档和脚本里系统状态依赖人的持续照看Operator 模式下运维知识被固化进控制器代码期望状态被固化进 CRD 配置系统具备了自我维护的能力。这也是云原生数据库区别于数据库跑在云上的分水岭——前者是数据库真正理解并融入了云的平台机制后者只是换了个地方装数据库。KES-Operator 的发布意味着 KES 属于前者。十、落地建议让 Operator 发挥最大价值结合 Operator 模式的普遍实践经验给计划使用 KES-Operator 的团队几点建议第一先补课存储选型。Operator 解决的是管的问题但数据最终落在哪个盘上取决于集群的存储方案。生产环境务必为数据库准备性能达标、支持动态供给的持久化存储本地盘、分布式块存储或企业级 CSI 驱动这是数据库在 K8s 上稳定运行的地基。第二把集群声明当代码管。kingbase_deploy.yaml这类配置文件建议全部纳入 Git 版本管理配合评审流程变更。每一次集群形态调整都留下痕迹出问题可回溯、可回滚——这正是声明式管理红利的兑现方式。第三监控先行再谈信任。上线初期保持对 KMonitor 大盘的高频关注观察控制循环在各类事件重启、扩容、故障下的真实行为建立对自动化边界的正确认知。信任要建立在验证之上。第四人要升级而不是退场。Operator 接管的是确定性、重复性的操作但容量规划、性能调优、架构演进这些高阶判断依然需要数据库工程师。从操作员升级为策略制定者才是这个工具给人带来的正确定位。十一、结语KES-Operator 正式发布后KES 集群可以完整纳入 Kubernetes 体系进行管理部署、状态维护、扩缩容、备份和监控等操作有了统一的管理方式。从更大的视角看这也是国产数据库拥抱云原生的一个标志性节点数据库不再把 Kubernetes 当作一个能跑容器的宿主机而是把整个集群的生命周期郑重地托付给了 Kubernetes 的声明式管理体系。对于正在或者计划把 KES 部署到 Kubernetes 环境的团队KES-Operator 值得认真试用——它把 DBA 的经验变成了集群的本能把运维的操作变成了配置的声明。未来电科金仓也将继续完善 KES-Operator 相关能力覆盖 KES 在 Kubernetes 环境中更多的使用和运维需求。 当国产数据库遇上云原生：深入解读 KES-Operator，让 KES 集群真正“长“在 Kubernetes 上
当国产数据库遇上云原生深入解读 KES-Operator让 KES 集群真正长在 Kubernetes 上一、写在前面数据库上云的最后一公里过去几年云原生的浪潮几乎重塑了整个软件基础设施的形态。微服务、容器化、DevOps这些曾经的前沿概念如今已经成为绝大多数业务系统的默认选项。而作为这一切底座的 Kubernetes也早已从一个容器编排工具成长为事实上的数据中心操作系统——计算、存储、网络、调度所有资源都收敛到了一套统一的 API 体系之下。应用为了适配这套体系纷纷完成了容器化改造。但有一类软件的改造始终没有那么顺利那就是数据库。作为典型的有状态应用数据库进入 Kubernetes 环境之后如何适配 Kubernetes 的管理方式给原有的运维模式带来了全新的要求。在传统的虚拟机或者物理机环境中数据库集群的管理已经是一套成熟的体系DBA 装库、建集群、配置流复制、写监控脚本、定期做备份演练。而一旦迁入 Kubernetes数据库集群管理就不再只涉及数据库自身还需要协调计算、存储、网络等一系列相关的资源对象——Pod 怎么编排、存储卷怎么挂载、服务怎么暴露、节点宕掉之后主备怎么切换每一个环节都要和 Kubernetes 的资源模型对齐。随着集群规模的扩大如果这些工作依然依赖人工逐项完成——写 YAML、起 Pod、配存储、盯状态——操作的复杂度和出错概率都会快速上升。数据库团队的运维经验如何沉淀到集群内部变成 7×24 小时不眨眼的自动化能力这正是 Operator 模式要解决的问题。针对用户在 Kubernetes 环境下管理金仓 KESKingbaseES集群的实际需求电科金仓正式推出了 KES K8s 运维工具——KES-Operator。它基于 Kubernetes Operator 技术和声明式管理方式将 KES 集群纳入 Kubernetes 管理体系提供集群部署、状态管理、扩缩容、物理备份等能力让用户可以按照 Kubernetes 原生的管理方式完成 KES 集群的部署和日常运维。这篇文章我们不打算停留在功能列表的罗列上而是从技术原理出发把 KES-Operator 的架构设计、核心能力和运维范式变迁拆开揉碎讲清楚看看数据库交给 Kubernetes 管这件事到底是怎么发生的。二、老问题为什么数据库是 Kubernetes 上最难管的住户要理解 KES-Operator 的价值得先理解数据库在 Kubernetes 上的管理为什么难。这个问题的根源在于Kubernetes 最初是为无状态应用设计的而数据库是典型的有状态应用。2.1 无状态应用的幸运对于一个无状态的 Web 服务Kubernetes 的管理模型非常简单Pod 挂了就重建一个任何一个副本都可以随时被替换反正它们彼此完全等价数据要么不存在要么在外部的 Redis、对象存储里。Deployment 控制器只需要维护副本数这一个数字就能把整个系统管理得井井有条。2.2 有状态应用的四座大山数据库完全不同。一个 KES 集群通常由一个主节点和若干备节点组成备节点通过流复制从主节点同步数据。这套拓扑结构一旦跑进 Kubernetes就会立刻撞上四座大山第一座山网络身份。数据库主备复制要求每个节点拥有稳定、可预期的网络标识。备节点要始终知道主节点在哪主节点切换后所有备节点要能跟上新的主。而原生 Pod 的 IP 和主机名都是随机的重启一次就面目全非。第二座山存储生命周期。数据库的数据必须落盘而且每个节点的数据盘是独立的、专属的。Pod 被重新调度到另一个节点时它的数据卷必须跟着走节点被删除时磁盘又不能被误删。PVC持久卷声明与 Pod 的绑定关系需要非常小心地维护。第三座山拓扑约束。数据库节点不是对等的主节点只有一个备节点可以多个扩容一个备节点要先从主节点做一次全量基础备份再增量追赶缩容时又不能随手删掉主节点。这些先后顺序和约束条件是 Deployment 控制器完全不理解的知识。第四座山故障恢复的专家经验。主节点宕机后如何选出新主如何防止旧主恢复后出现双主脑裂备节点数据落后太多怎么办这些判断和处理逻辑过去都装在资深 DBA 的脑子里写在一篇篇应急预案文档里。Kubernetes 自带的控制器不懂这些它只会机械地把 Pod 拉起来而不知道拉起来之后该让它当主还是当备。这四座大山就是数据库不敢直接上 K8s的根本原因也是所有数据库 Operator 试图翻越的地方。三、Operator 模式Kubernetes 的自我进化Operator 这个概念由 CoreOS 的工程师在 2016 年提出最初的实践是 etcd Operator。它的核心思想用一句话概括就是“An Operator is a software extension to Kubernetes that makes use of custom resources to manage applications and their components.”—— Operator 是 Kubernetes 的软件扩展通过自定义资源Custom Resource来管理应用及其组件。这句话里藏着两个关键技术点值得展开讲讲。3.1 CRD给 Kubernetes 的 API 增加新词汇Kubernetes 的 API Server 维护着一整套资源类型Pod、Service、ConfigMap、StatefulSet……每一种资源都是一句声明。但 Kubernetes 并不认识数据库集群这种概念——没有任何一个内置资源叫KesCluster。CRDCustom Resource Definition自定义资源定义解决了这个问题。通过 CRD用户可以向 API Server 注册全新的资源类型让KES 集群成为 Kubernetes 世界里的一等公民。注册之后你就可以像操作 Pod 一样操作它# 一个示意性的声明描述我要一个什么样的 KES 集群kubectl apply-fkingbase_deploy.yaml# 像查看原生资源一样查看 KES 集群状态kubectl get kesclusters这就是声明式 API 的本质用户不再描述操作步骤而是描述期望结果。你不需要告诉系统先创建这个、再配置那个、然后启动什么你只需要说我要一个三节点的 KES 集群版本是 V009R001C010PS009存储 100Gi剩下的交给控制器。3.2 控制循环向期望状态持续收敛的永动机光有资源定义还不够得有人来兑现这些声明。这个人就是控制器Controller而它的工作方式是一个永不停歇的闭环业内俗称Reconcile Loop调谐循环观察Observe→ 比对Diff→ 执行Act→ 再观察……观察通过 ListWatch 机制监听 API Server 上自定义资源的变化事件同时读取集群的实际运行状态比对把用户声明的期望状态和集群的实际状态放在一起对比算出差异执行针对差异执行协调动作——该建 StatefulSet 建 StatefulSet该挂 PVC 挂 PVC该拉起新备节点就拉起新备节点循环然后回到观察直到实际状态与期望状态收敛一致。这个循环的美妙之处在于幂等与自愈无论系统因为什么原因偏离了目标——节点宕机、误操作、网络抖动——控制循环都会在下一次调谐时发现偏差并自动把系统拉回正轨。用户声明的期望状态成了整个系统永恒的引力中心。3.3 Operator把 DBA 的经验装进集群把 CRD 和控制循环组合起来再注入特定领域的运维知识就得到了 Operator。一个数据库 Operator 相当于把资深 DBA 的运维经验编译成了代码以 Pod 的形式部署在集群内部7×24 小时值守。部署怎么做、主备怎么切换、扩容怎么编排、备份怎么执行这些知识不再依赖值班人员的临场发挥而是变成了机器执行的确定性逻辑。KES-Operator 正是这一模式在金仓 KES 上的完整落地。四、KES-Operator 架构解析它是如何嵌进 Kubernetes 的上图是 KES-Operator 的整体架构我们可以自上而下拆解。交互入口层。图的最上方是两个入口REST API 和 kubectl/CLI。这延续了 Kubernetes 的一贯设计——所有操作最终都汇入 API Server。无论你是用脚本调用 REST 接口还是运维人员敲kubectl命令操作的都是同一套资源对象地位完全对等。这意味着 KES 集群的管理动作可以无缝融入企业现有的 K8s 自动化流水线CI/CD 工具、发布系统、审计系统全部照常工作。Kubernetes 控制平面。图的中部是 Kubernetes Master包含 Controller Manager、API Server 和 Scheduler 三个核心组件。值得强调的是KES-Operator 并不绕开这些原生组件而是站在它们之上工作——它自己也是一个部署在集群里的工作负载通过监听 CRD 事件图中橙色箭头感知用户的配置变更。KingbaseES Operator 本体。图右侧红色的 KingbaseES Operator 是整个体系的大脑。它持续监听 CRD 事件一旦发现用户创建或修改了 KES 集群的自定义资源就立刻进入调谐循环根据期望状态与实际状态的差异执行调度 Pod图中绿色箭头等一系列协调动作——创建 StatefulSet 管理数据库节点、申请存储卷、维护主备拓扑。数据平面KES 集群本体。图的中下部是 Kubernetes Node 层。可以看到KES 集群的各个数据库实例以 Pod 形态分布在多个 Node 上图中 Node1 上有 Pod-0、Pod-1 到 Pod-N 的序列NodeX 上同样部署了一组 KES Pod每个 Node 上由 kubelet 负责容器生命周期、dns 负责服务发现。Pod 编号序列体现了典型的 StatefulSet 特征——每个数据库实例拥有稳定、有序、可预期的身份标识这正是第二部分提到的网络身份问题的标准解法。存储层。图的最底部是存储卷。数据库的数据持久化在独立的存储卷上Pod 的销毁与重建不会影响数据重建后的 Pod 重新挂回原来的卷数据原样归来。整个架构可以概括为一句话用户声明期望 → API Server 记录声明 → Operator 监听并调谐 → 原生资源StatefulSet/PVC/Service落地 → KES 集群按需运行。数据库的运维知识全部收敛在 Operator 这一层而对用户暴露的是纯净、标准的 Kubernetes 使用体验。五、能力一自动化部署让 KES 集群快速运行上面这组动图展示了 KES-Operator 的部署现场管理员登录到 K8s 管理节点图中终端为k8s-204对应 KingbaseES V009R001C010PS009 x86_64 的部署目录目录里可以看到三个关键的 YAML 清单文件all_crd.yaml—— 注册 KES 集群相关的自定义资源定义kingbase_deploy.yaml—— 描述要部署的 KES 集群的期望状态节点数、版本、存储等kingbase_backup.yaml—— 定义备份相关的配置。在 Kubernetes 环境中数据库集群部署原本涉及多个资源对象的配置——StatefulSet、Service、PVC、ConfigMap、Secret环环相扣漏一个都起不来。而 KES-Operator 采用声明式管理方式把这些复杂性全部封装用户只需通过配置文件定义 KES 集群的期望状态执行kubectl apply提交配置完成后由 KES-Operator 自动创建所有相关资源。从提交那一刻起一系列动作在集群内部自动展开API Server 接收并持久化集群声明 → Operator 监听到事件开始调谐 → 按声明创建 StatefulSet 与对应的存储卷 → Scheduler 把各个数据库 Pod 调度到合适的 Node → kubelet 拉起容器 → KES 实例完成初始化 → 主备复制关系自动建立 → 服务就绪。人工逐项配置的过程被压缩成了一份 YAML 和一条命令。更重要的是这份 YAML 本身就是集群的文档——它精确记录了集群的期望形态可评审、可版本化、可重复执行部署结果不再因人而异。六、能力二持续状态管理让数据库集群保持目标状态部署只是起点运行过程中的状态维护才是日常工作的重头。上面这组动图展示的是进入 KES 数据库 Pod 内部kingbase-cluster-kingbase-0正是 StatefulSet 分配的稳定节点标识进行状态核查的场景。KES-Operator 通过 Kubernetes 控制器机制持续监测数据库集群的实际运行状态并与用户定义的期望状态进行比对。这个机制的意义在于它管的不只是Pod 死没死这么粗粒度的问题而是数据库视角的集群健康实例级自愈某个 KES Pod 意外退出控制器检测到实际副本数低于期望自动重建并重新接入集群拓扑主备角色维护集群的期望状态里写着谁是主、谁是备当实际角色分配与声明出现偏差时Operator 按配置协调相关资源恢复正确的复制拓扑配置一致性用户修改了集群配置如资源额度、参数Operator 感知到声明变更后逐步将实际状态调整到新目标。这套机制的价值可以用一句话总结期望状态一旦声明维护它就不再是运维人员的任务而是系统的本能。过去需要值班人员定时巡检、手工比对的日常工作现在由控制循环 7×24 小时自动执行人工检查和被动救火的次数大幅减少。对运维团队来说这也是一种心理上的解放——数据库集群从需要时刻盯着的婴儿变成了会自己吃饭的成熟系统人的精力终于可以投向容量规划、性能优化这些更高价值的工作。七、能力三灵活扩缩容满足业务变化需求业务有波峰波谷数据库资源需求自然也要随之调整。上面这组动图展示的是扩缩容后的集群拓扑核查管理员在 KES 节点内执行/opt/kingbase/bin/repmgr cluster show直接查看集群当前的复制拓扑与各节点角色状态——新增的节点是否已加入、复制关系是否健康一目了然。KES-Operator 支持KES 集群的扩容与缩容管理。用户根据实际需求调整集群节点规模修改集群配置即修改自定义资源中的期望状态后KES-Operator 根据新的配置自动完成相应的资源调整。这个看似简单的能力背后是 Operator 对数据库拓扑知识的完整理解扩容时它不是简单地多拉一个 Pod 了事。新节点要经过完整的入伙流程申请独立存储卷 → 启动 KES 实例 → 从主节点建立复制通道 → 追平数据 → 正式纳入集群提供服务。顺序不能错状态没就绪之前不能对外。缩容时它同样懂得规避风险先确认目标节点不是主节点或者先执行主备切换再安全摘除节点、回收复制关系最后清理对应的 Kubernetes 资源避免出现主节点被误删这类灾难性事故。对比一下传统做法虚拟机环境里扩容一个数据库备节点通常要走申请资源、装库、配复制、全量恢复、验证、接入监控等一长串人工流程周期以天计而在 KES-Operator 的管理下这变成了一次配置修改分钟级完成。弹性不再只是无状态应用的专利有状态的数据库集群也拥有了随业务伸缩的能力。八、能力四物理备份与监控管理要保障数据库长期稳定运行除了日常状态管理还必须有完善的数据保护与可观测能力。KES-Operator 在这两个方向上同样给出了体系化的答案。8.1 物理备份数据安全的最后防线KES-Operator 支持 KES 物理备份管理用户可以通过配置创建和管理备份任务。这里强调物理备份是有讲究的。相比导出 SQL 的逻辑备份物理备份直接对数据库的物理存储做一致性拷贝恢复时可以直接将数据库还原到指定时间点而不是重放一遍建库脚本。对于动辄几百 GB、上 TB 的生产库物理备份在恢复速度和完整性上都有不可替代的优势——它是数据库故障恢复的最后防线。更关键的是备份任务本身也被纳入了 Kubernetes 的声明式管理体系备份策略以配置形式声明创建、调度、执行、清理由 Operator 统一管理。备份不再依赖某台备份机上的 crontab 和一堆散落的脚本备份策略即代码随集群配置一起被版本化管理永远不会出现备份脚本在哪台机器上没人说得清的尴尬。8.2 KMonitor 监控看得见的健康状态KES-Operator 同时支持 KMonitor 监控组件管理用于查看 KES 集群的运行状态。上面这张监控大盘截图信息量很大我们可以逐块解读资源水位CPU 使用率9.2%、内存使用率34.3%、CPU 核数20、物理内存总量38.9 GiB、CPU iowait4.0%——实时掌握宿主资源消耗iowait 指标对数据库尤其敏感它往往是磁盘瓶颈的第一信号运行时长与授权服务器运行时长13 week、数据库运行时长、授权有效期90 天——授权临期提前可见避免业务中断集群拓扑健康数据库节点信息表清晰列出节点角色——node61为standby活备、node62为primary主节点两个节点的复制状态均为活跃整体流复制状态健康。主备拓扑是否正常一眼可判容量趋势整体总容量与平均 CPU/内存/磁盘使用率的历史曲线——容量规划从拍脑袋变成看曲线业务吞吐QPS TPS 实时曲线、每秒各类 DML 语句影响行数——数据库到底忙不忙、忙在什么类型的操作上有了量化依据。这些监控信息与备份任务一样都收敛在 Kubernetes 环境中统一管理。部署、状态、扩缩容、备份、监控五类运维动作从此有了同一个入口、同一套范式。九、范式之变从跑脚本到改配置把前面的能力串起来看KES-Operator 带来的不只是几个新功能而是一次运维范式的迁移。我们把新旧两种模式放在一起对比运维场景传统人工模式KES-Operator 模式部署集群装库、建复制、配服务逐台手工操作编写一份集群声明 YAMLkubectl apply一键拉起日常巡检登录各节点手工检查、盯监控告警控制循环持续比对期望/实际状态偏差自动修复扩缩容申请资源→装库→建复制→验证以天计修改 replicas 配置分钟级自动完成入伙/摘除故障恢复值班人员按应急预案手工处置系统自动重建/切换按声明收敛回目标状态备份管理备份机上散落的 crontab 脚本声明式备份任务统一创建、调度与清理监控查看多套工具拼凑、口径不一KMonitor 统一大盘与集群同体系管理对比的核心差异在于知识的位置传统模式下运维知识存在于人脑、文档和脚本里系统状态依赖人的持续照看Operator 模式下运维知识被固化进控制器代码期望状态被固化进 CRD 配置系统具备了自我维护的能力。这也是云原生数据库区别于数据库跑在云上的分水岭——前者是数据库真正理解并融入了云的平台机制后者只是换了个地方装数据库。KES-Operator 的发布意味着 KES 属于前者。十、落地建议让 Operator 发挥最大价值结合 Operator 模式的普遍实践经验给计划使用 KES-Operator 的团队几点建议第一先补课存储选型。Operator 解决的是管的问题但数据最终落在哪个盘上取决于集群的存储方案。生产环境务必为数据库准备性能达标、支持动态供给的持久化存储本地盘、分布式块存储或企业级 CSI 驱动这是数据库在 K8s 上稳定运行的地基。第二把集群声明当代码管。kingbase_deploy.yaml这类配置文件建议全部纳入 Git 版本管理配合评审流程变更。每一次集群形态调整都留下痕迹出问题可回溯、可回滚——这正是声明式管理红利的兑现方式。第三监控先行再谈信任。上线初期保持对 KMonitor 大盘的高频关注观察控制循环在各类事件重启、扩容、故障下的真实行为建立对自动化边界的正确认知。信任要建立在验证之上。第四人要升级而不是退场。Operator 接管的是确定性、重复性的操作但容量规划、性能调优、架构演进这些高阶判断依然需要数据库工程师。从操作员升级为策略制定者才是这个工具给人带来的正确定位。十一、结语KES-Operator 正式发布后KES 集群可以完整纳入 Kubernetes 体系进行管理部署、状态维护、扩缩容、备份和监控等操作有了统一的管理方式。从更大的视角看这也是国产数据库拥抱云原生的一个标志性节点数据库不再把 Kubernetes 当作一个能跑容器的宿主机而是把整个集群的生命周期郑重地托付给了 Kubernetes 的声明式管理体系。对于正在或者计划把 KES 部署到 Kubernetes 环境的团队KES-Operator 值得认真试用——它把 DBA 的经验变成了集群的本能把运维的操作变成了配置的声明。未来电科金仓也将继续完善 KES-Operator 相关能力覆盖 KES 在 Kubernetes 环境中更多的使用和运维需求。