一、时代背景：国产数据库的云原生之困
过去几年，在政策推动、产业升级和关键行业自主可控需求持续增强的背景下，国产数据库正在加速发展，从"可选项"走向"必选项"，从局部应用走向更广泛的生产场景，逐步成为越来越多企业数字基础设施的重要组成部分。
其中，人大金仓 KingbaseES（KES）已经成为国产数据库阵营中的重要代表之一，具备对标 Oracle 的能力。作为面向企业级场景的大型通用数据库产品，KingbaseES 正在政企、金融、制造等关键领域承载越来越多核心业务，也成为信创数据库落地过程中备受关注的产品之一。
从企业级服务角度考虑，数据库从来不只是一个独立的软件产品。在企业核心系统中，它更像是一整套服务能力的集合，既承载数据存储与事务处理，也承载高可用、备份恢复、安全审计、监控告警、参数治理和持续交付等关键职责。数据库是否真正可用，看的从来不只是内核能力，还包括它能否被稳定地交付、运营和治理。
也正因为如此，传统数据库运维模式的问题在今天变得越来越突出。长期以来，很多数据库系统仍然依赖人工脚本、主机环境配置和手动干预来完成部署与维护，运维流程高度依赖经验，标准化和自动化水平有限。对于数据库平台团队和企业用户而言，典型痛点非常明确：
- 部署繁琐。多副本集群安装配置依赖人工经验，环境差异大，标准化困难。
- 运维成本高。主备切换、扩缩容、备份恢复等操作流程长、风险高，往往需要 DBA 专家介入。
- 缺乏平台化能力。参数管理、监控、审计、安全配置分散在多个环节，难以形成统一运维入口。
- 难以适应云原生环境。数据库运维流程没有随着 Kubernetes 的资源调度和弹性体系同步升级，平台红利难以释放。
在这样的背景下，随着云原生技术的全面普及，企业技术架构正在加速向容器化、平台化演进，数据库也被推到了新一轮升级的关键位置。而此时，很多企业开始面临一个现实问题：当国产数据库普遍缺少完善的云原生能力时，如何推动数据库服务完成面向 Kubernetes 的架构升级。
这意味着，企业需要的不是简单地把数据库部署到容器里，而是补齐数据库在交付、运维、治理等方面的云原生能力，让其完成从传统软件形态到云原生服务形态的升级。也正是在这样的背景下，KubeBlocks 开始推动 Kingbase 的云原生化实践，把原本依赖人工脚本、经验判断和碎片化工具的数据库运维能力，沉淀为一套面向 Kubernetes 的产品化能力，进一步打通国产数据库与云原生基础设施之间的关键链路。
二、KubeBlocks 云原生化 Kingbase，做了什么
Kingbase 的云原生化并不是简单把数据库以 Pod 形式运行起来，而是要把数据库的核心能力和运维流程真正纳入云原生平台的管理体系之中。只有这样，数据库才能从传统软件形态升级为可持续交付、可统一运维、可平台化治理的云原生服务。
在这一过程中，声明式 API 是关键基础。KubeBlocks 通过声明式 API，将集群定义、生命周期管理、备份恢复、参数治理、监控审计和运维操作等能力统一抽象出来，让 Kingbase 能够以标准化、可编排的方式接入 Kubernetes 平台，并成为可被统一管理的数据库服务。
在声明式 API 的基础上，KubeBlocks 企业版进一步提供了图形化控制台，让原本偏底层、偏工程化的数据库管理能力，以更直观的方式呈现给用户，使数据库集群的创建、查看、运维和治理都拥有统一入口。KubeBlocks For Kingbase 的产品控制台如下：
而要真正支撑这样的云原生数据库服务，背后需要的并不是单一能力点，而是一整套围绕交付、运行、运维和治理展开的产品能力。具体来看，KubeBlocks 主要从以下几个方面完成了对 Kingbase 的云原生化升级：
1. 把复杂部署过程沉淀为标准化集群交付
KubeBlocks 的一个核心价值，在于它通过 Cluster、Component、InstanceSet 和 Instance 四层抽象模型，把数据库从一次性的安装对象，变成了可以被平台持续交付和统一管理的标准化服务对象。关于抽象模型的详细设计，可以参考文献【1】。
基于这套抽象模型，我们为 Kingbase 实现了面向不同版本和运行特性的对象定义，覆盖了 Kingbase 8 与 Kingbase 9 两个版本分支，并统一抽象出集群拓扑、组件角色、账号体系、配置管理和服务暴露方式。这样一来，Kingbase 不再依赖人为拼装脚本和环境，而是能够以声明式方式完成集群创建、版本适配、账号初始化、网络暴露和配置挂载。进一步结合控制台的实例创建页面，用户可以通过统一界面完成架构选择、版本选择、部署环境、资源规格、存储配置、集群参数和备份策略等关键配置。原本需要 DBA 和平台工程师分别处理的安装与初始化动作，被收敛为一套标准化、可复用、可审核的创建流程。对于平台团队来说，这一步非常关键，因为它把"会部署 Kingbase"变成了"平台能交付 Kingbase"。
2. 内建高可用能力，让主备切换更接近平台原生
在 Kingbase 的组件定义中，KubeBlocks 显式定义了 primary 和 standby 两类角色，并通过 roleProbe、switchover、memberLeave 等生命周期动作，把数据库角色识别和主备切换纳入平台控制面。
从实现上看，系统会持续探测节点角色，识别当前实例在复制拓扑中的位置；在切换场景下，可以基于候选节点执行主备 switchover；在节点离场时，也会配合复制关系和集群成员关系完成清理。这种做法的价值，不只是"能切换"，而是把高可用从一次性的运维动作，变成了系统内建能力。
为验证云原生场景下 Kingbase 的高可用能力，我们对其进行了全面的故障模式测试。从结果来看，在主库进程关闭、主库资源打满、主库网络抖动、AZ 故障、带宽限制等多类故障场景下，系统都能够完成主备切换，且测试结果中的 RPO 保持为 0，RTO 在不同场景下表现为秒级到百秒内恢复。
| 测试模块 | 用例名称 | 测试结果 | RPO | RTO | 说明 |
|---|---|---|---|---|---|
| 连接压力 | 连接数 Full | 主备不切换 | 0 | 0 | 1000 连接数测试打满之后，无法再创建新的连接5000 连接数测试达到 2924 左右，内存溢出，无法再创建更多连接 |
| 进程故障 | 主库进程关停 (delete pod) | 主备切换 | 0 | 62s | 数据库无法访问，55s 左右主库切换成功，62s 左右数据库访问正常 |
| 从库进程关停 (delete pod) | 主备不切换 | 0 | 0 | ||
| 所有主从进程关停(delete pod) | 主备不切换 | 0 | 88s | 数据库无法访问，88s 左右数据库访问正常 | |
| 资源故障 | 主库负载打满 (CPU 100%) | 主备不切换 | 0 | 0 | |
| 主库负载打满 (内存 100%) | 主备切换 | 0 | 29s | 数据库无法访问，28s 左右主库切换成功，29s 左右数据库访问正常 | |
| 主库负载打满 (磁盘容量 100%) | 主备切换 | 0 | 36s | 数据库无法访问，35s 左右主库切换成功，36s 左右数据库访问正常 | |
| 从库负载打满 (CPU 100%) | 主备不切换 | 0 | 0 | ||
| 从库负载打满 (内存 100%) | 主备不切换 | 0 | 0 | ||
| 从库负载打满 (磁盘容量 100%) | 主备不切换 | 0 | 0 | ||
| 网络故障 | 主库网络抖动 (丢包率导致角色探测失败) | 主备切换 | 0 | 73s | 数据库无法访问，71s 左右主库切换成功，73s 左右数据库访问正常 |
| 主库AZ故障 (断subnet网络) | 主备切换 | 0 | 113s | 数据库无法访问，105s 左右主库切换成功，113s 左右数据库访问正常 | |
| 主库网络延迟故障 | 主备切换 | 0 | 1s | 数据库访问延迟，1s 左右主库切换成功，1s 左右数据库访问正常 | |
| 主库包损坏故障（corrupt=100%损坏概率，-c相关性100%） | 主备切换 | 0 | 52s | 数据库无法访问，42s 左右主库切换成功，52s 左右数据库访问正常 | |
| 主库包重复故障 | 主备不切换 | 0 | 0 | ||
| 主库带宽限制 | 主备切换 | 0 | 70s | 数据库无法访问，68s 左右主库切换成功，70s 左右数据库访问正常 | |
| 从库网络抖动 (丢包率导致角色探测失败) | 主备不切换 | 0 | 0 | ||
| 从库AZ故障 (断subnet网络) | 主备不切换 | 0 | 0 | ||
| 从库网络延迟故障（ | 主备不切换 | 0 | 0 | ||
| 从库包损坏故障corrupt=100%损坏概率，-c相关性100%） | 主备不切换 | 0 | 0 | ||
| 从库包重复故障 | 主备不切换 | 0 | 0 | ||
| 从库带宽限制 | 主备不切换 | 0 | 0 | ||
| 存储故障 | 主库存储坏 (delete pv) | 主备不切换（不重启）主备切换（重启） | 0 | 68s | 实例不重启，数据库访问正常实例重启，数据库无法访问，67s 左右主库切换成功，68s 左右数据库访问正常 |
| 从库存储坏 (delete pv) | 主备不切换 | 0 | 0 | ||
| 服务器故障 | 末日故障所有节点宕机 (关机/停机) | 主备不切换 | 0 | 160s | 数据库无法访问，Node Ready 160s 左右数据库访问正常 |
3. 支持扩缩容，把数据库伸缩纳入统一运维流程
数据库上云之后，资源弹性不应只停留在计算层。Kingbase 的云原生化实现里，已经把扩容和缩容相关流程串联起来，包括新节点克隆、配置调整、备节点注册、监控纳管，以及缩容时的节点注销、数据库停止与 replication slot 清理。
通过声明式 API 或企业版控制台修改 Cluster 对象的特定参数，就可以触发扩缩容流程。Operator 会根据当前集群状态和目标状态自动计算出需要调整的节点数量，并执行相应操作完成扩缩容。这样一来，数据库的伸缩能力被纳入平台统一运维流程中，能够更好地适应云原生环境下的动态资源需求变化，而不再依赖人工干预或外部工具。对用户而言，这种能力带来的直接价值，就是扩缩容操作更加标准、过程更可控、风险更低。
4. 把备份、恢复和 PITR 变成默认能力，而不是额外工程
数据库真正进入核心生产后，备份恢复能力的重要性不亚于高可用。KubeBlocks For Kingbase 提供了完整的 BackupPolicyTemplate 与 ActionSet，支持全量备份、增量备份以及 PITR（Point-in-Time Recovery，时间点恢复）。这些能力并不是孤立存在，而是直接挂接在数据库组件生命周期中：
- 可以按策略定义全量、增量和持续归档备份。
- 支持 standby 优先备份，并在必要时回退到 primary。
- 支持 restore 流程拉取备份数据并恢复到目标实例。
- 支持基于恢复时间点执行数据库回放。
备份恢复是生产环境必须具备的可靠能力，KubeBlocks For Kingbase 通过提供不同的备份策略和灵活的恢复选项，让备份恢复成为一个内建的、可声明式管理的能力模块，大大降低数据丢失和服务中断的风险。
5. 参数治理能力进入平台层，提升可维护性与一致性
Kingbase 的云原生化并不止于部署和备份。在参数管理方面，KubeBlocks 为其提供了 ParametersDefinition，对静态参数、动态参数、不可变参数进行了分类定义，并支持参数变更后的 reload/restart 流程编排。参数变更通过声明式API方式下发，系统会根据参数类型和变更要求自动执行相应的操作来完成参数更新。所有的参数变更都可以通过平台进行统一管理和审计，避免了传统数据库中常见的"谁修改了参数"、"修改了什么参数"、"修改后系统状态如何"等不透明问题。
在平台化场景中，通过可视化的参数配置界面，用户可以直观地检索、修改参数并触发变更流程。参数能力只有被模型化、约束化、流程化，才能真正成为可运营能力。通过这种方式，将参数治理从"零散操作"升级为"规范一致的平台动作"，在提高参数一致性的同时，还提供了清晰的变更历史跟踪，降低了误操作的风险。
6. 将监控体系随数据库一体交付，提升可观测性
KubeBlocks 企业版在交付 Kingbase 时，已经将可观测能力一并集成进去。实例创建完成后，监控能力即可直接使用。与此同时，实例本身也保留了 exporter 接口，方便用户将已有监控体系继续接入，满足二次扩展需求。
在此基础上，平台还预置了一套默认告警规格，并提供自定义告警能力。当集群状态、性能指标或运行行为出现异常时，系统可以及时发出通知，让监控不只是"看得到"，也真正具备"能响应"的能力。
7. 将审计与安全相关能力纳入默认建设范围
SQL 审计是企业数据库治理中的关键能力。对于核心业务系统而言，只有把关键操作记录下来，才能在问题排查、责任追溯和合规审查时提供可靠依据。
KubeBlocks 企业版集成了 Kingbase 的审计能力，支持对 CREATE、ALTER、DROP、DML、事务等多类数据库操作进行审计。用户也可以控制审计日志开关、审计日志级别等参数，满足不同场景下的审计需求。
下图是 SQL 审计的统一入口。用户可以按实例、时间范围和关键字检索审计日志，查看数据库、账号、连接 IP、SQL 语句、执行时长和返回行数等信息，并支持日志下载，方便在异常定位、问题分析和事后审计中进一步留存和使用。
8. 将日常运维动作产品化，提升交付效率
除了常见的高可用、备份、监控之外，KubeBlocks 企业版把 Kingbase 的其他日常运维动作也统一纳入平台入口中，包括数据管理、账号管理、安全管理等等，这些往往都是数据库生产托管里最容易被忽略、但最消耗人力的部分。
当这些动作被纳入平台体系后，数据库运维不再是分散在脚本、命令和多个工具之间的零散动作，而是被整理为清晰的功能模块和标准化入口。对数据库交付来说，这种平台化方式让运维协作更顺畅，也让日常管理和问题处理更高效。
三、云原生化之后，Kingbase 获得了怎样的产品能力升级
如果把视角从单个功能点拉高，会发现 KubeBlocks 带给 Kingbase 的变化，主要集中在两个方面：一是云原生带来的产品能力提升，二是面向用户的使用体验提升。
云原生带来的能力提升
云原生化之后，Kingbase 获得的不只是部署方式的变化，而是一套更完整的服务能力。高可用切换、备份恢复、参数治理、监控告警、SQL 审计等原本分散的能力，被统一纳入声明式模型和平台框架中，形成可编排、可审计、可持续运营的数据库服务。
这种提升的关键不在于"把数据库跑在 Pod 里"，而在于让数据库具备了云平台需要的标准化能力边界，可以更自然地接入 Kubernetes 环境中的交付、管理和治理体系。
云原生带来的使用提升
对用户而言，云原生化也直接改变了使用方式。创建实例、查看状态、调整参数、执行备份、观察性能、检索审计日志等动作，都可以通过统一控制台和标准化入口完成，使用路径更清晰，操作门槛也更低。
用户获得的不再只是一个数据库产品，而是一套更容易使用、更容易管理、也更适合在现代平台环境中持续运行的数据库服务。
四、这会给用户和伙伴带来什么收益
这些云原生能力带来的收益是直接的，不仅体现在数据库本身的可用性和可管理性上，也体现在平台交付效率和生态适配能力上。
对企业用户
- 更快落地。通过标准化部署和内建运维能力，缩短 Kingbase 在 Kubernetes 环境中的上线周期。
- 更稳运行。高可用、备份恢复、参数治理和监控体系一体化，降低生产风险。
- 更低门槛。降低对少数专家型 DBA 的强依赖，让平台团队也能稳定运营数据库。
- 更易治理。安全、审计、配置和生命周期动作被统一纳入平台，便于制度化运维。
对平台团队
- 可以把 Kingbase 纳入统一数据库服务目录，实现与其他数据库的一致化管理。
- 可以通过标准 API 和声明式模型提升自动化水平，减少重复运维工作。
- 可以更容易支撑多租户、多环境和大规模数据库交付场景。
对生态伙伴与市场推广
- 云原生能力让 Kingbase 更容易进入现代化应用架构与容器平台项目。
- 产品叙事从"数据库替代"升级为"数据库平台能力升级"，更能体现长期价值。
- 对客户沟通时，不再只强调兼容性和基础性能，而是可以进一步强调生产可运营性与平台适配能力。
五、助力企业技术架构升级，扩展数据库应用边界
总体而言，云原生化并不是对数据库做一次外围包装，而是在帮助企业完成技术架构升级的同时，也推动国产数据库从单一产品能力走向更广泛的平台能力和场景能力。
这种变化带来的价值，一方面体现在企业侧。对于正在推进容器化、平台化和现代化架构升级的企业来说，数据库是否能够顺畅接入 Kubernetes 和统一控制平台，已经直接影响到整体技术架构的落地效率。另一方面，这也为 Kingbase 扩展了发展空间，让它不仅能服务传统数据库替代场景，也能够更自然地进入云平台、数据库平台以及更多现代应用基础设施场景，进一步扩展国产数据库的应用边界。
感谢 Kingbase 团队的支持，你们的专业和投入为这次云原生化实践提供了重要保障。也感谢所有贡献 KubeBlocks For Kingbase 的同学，正是大家的持续投入，才让这些能力真正落地成为产品。
KubeBlocks 企业版已经提供了包括 Kingbase 在内的多种国产数据库云原生化能力，覆盖达梦、万里、GaussDB、OceanBase 等多个数据库产品。欢迎访问 ApeCloud 官网了解并试用，也欢迎更多数据库厂商和生态伙伴一起加入，共同推动国产数据库在云原生时代拓展更广阔的应用空间。
六、参考文献
- K8S 的最后一片拼图：dbPaaS：mp.weixin.qq.com/s/XsXhreRFM...
- ApeCloud 官网：apecloud.cn/