前言随着信创改造进入深水区「信创 云原生」逐渐成为政务、金融、国企新一代 IT 架构的标准范式。将人大金仓、达梦等国产数据库部署在 Kubernetes 平台上实现弹性伸缩、故障自愈、统一编排是云原生信创的核心场景。 但国产数据库上 K8s 远非「跑个容器」这么简单存储性能、数据持久化、高可用架构、授权绑定、运维习惯五大问题让很多项目踩了大坑 —— 要么性能比物理机差好几倍要么故障切换数据不一致要么 Pod 一漂移授权就失效。本文基于金融与政务云原生信创项目落地经验从架构设计、部署实战、高可用方案、运维体系、避坑指南五个维度系统性讲解人大金仓 V9、达梦 DM9 在 Kubernetes 上的生产级部署与运维方案。所有 YAML、脚本、优化策略均经过生产环境验证可直接复制落地。一、适用范围与核心挑战1.1 适用环境数据库版本人大金仓 KingbaseES V9R6/V9R7、达梦 DM8/DM9K8s 版本v1.24兼容国产 K8s 发行版如华为云容器、东方通云平台底层操作系统银河麒麟 V10、统信 UOS 服务器版存储方案本地 SSD 存储、国产分布式块存储如杉岩、华为云存储适用场景非核心业务系统、开发测试环境、多租户数据库平台1.2 国产数据库上 K8s 的五大核心挑战这是所有方案设计的出发点也是很多项目翻车的根源存储性能瓶颈数据库是 IO 密集型业务普通分布式存储性能远不如物理机直接上容器会导致性能断崖式下降数据一致性风险K8s 原生自愈能力无法保障数据库数据一致性Pod 异常重启极易导致数据损坏高可用适配难达梦数据守护、金仓流复制原生依赖固定 IP / 主机名与 K8s 动态编排理念天然冲突授权绑定问题国产数据库 License 多绑定 IP/MAC/ 主机名Pod 漂移后授权失效业务中断运维体系断层传统 DBA 习惯命令行运维K8s 化后运维链路、排障路径完全改变学习成本高1.3 生产级设计原则存储优先数据库性能 70% 取决于存储必须优先保障 IO 性能状态可控尽量减少 Pod 自动漂移核心库通过节点亲和性固定运行节点数据库层高可用为主K8s 自愈为辅数据一致性靠数据库原生主从架构保障K8s 只负责进程级自愈运维兼容保留传统 DBA 的运维入口同时对接云原生监控体系分级部署核心交易库优先物理机 / 虚拟机非核心、测试库先行容器化二、总体架构设计2.1 部署架构选型部署模式实现方式适用场景推荐指数单节点 StatefulSet单 Pod 持久化存储开发测试、非核心系统⭐⭐⭐一主一备 StatefulSet两个 Pod数据库原生主从复制生产非核心系统⭐⭐⭐⭐Operator 全生命周期管理自定义 Operator 管控部署 / 备份 / 切换大规模多租户场景⭐⭐⭐⭐⭐现阶段落地建议绝大多数项目优先采用「StatefulSet 数据库原生主从」方案成熟稳定改造成本低大规模多租户场景再逐步建设 Operator。2.2 核心资源设计StatefulSet数据库实例本体保证稳定的网络标识、有序部署与销毁Headless Service提供稳定的 DNS 域名用于主备节点间通信ClusterIP Service对外提供统一访问入口主节点故障时手动 / 自动切换StorageClass对接高性能块存储动态供给持久化卷ConfigMap管理数据库配置文件支持热加载Secret管理数据库密码、License 等敏感信息节点亲和性将数据库 Pod 固定在指定高性能节点避免漂移三、人大金仓 V9 K8s 部署实战3.1 前置准备制作金仓 V9 镜像基于官方安装包制作 Docker 镜像包含数据库二进制、环境变量、启动脚本准备高性能 StorageClass推荐本地 SSD 或分布式块存储准备授权文件 license.dat3.2 完整部署 YAML第一步创建命名空间与配置apiVersion: v1 kind: Namespace metadata: name: kingbase --- # 配置文件 ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: kingbase-config namespace: kingbase data: kingbase.conf: | listen_addresses * port 54321 max_connections 500 shared_buffers 2GB effective_cache_size 6GB work_mem 8MB wal_level replica archive_mode on max_wal_size 4GB checkpoint_completion_target 0.9 log_min_duration_statement 1000第二步单节点 StatefulSet 部署apiVersion: apps/v1 kind: StatefulSet metadata: name: kingbase namespace: kingbase spec: serviceName: kingbase-headless replicas: 1 selector: matchLabels: app: kingbase template: metadata: labels: app: kingbase spec: # 节点亲和性固定到高性能数据库节点 nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role/database operator: In values: [true] # 禁止 Pod 被驱逐 priorityClassName: system-cluster-critical securityContext: fsGroup: 1000 containers: - name: kingbase image: kingbase:v9r6 imagePullPolicy: IfNotPresent ports: - containerPort: 54321 name: db env: - name: SYSTEM_PASSWORD valueFrom: secretKeyRef: name: kingbase-secret key: sysdba-password resources: requests: cpu: 4 memory: 8Gi limits: cpu: 8 memory: 16Gi volumeMounts: - name: data mountPath: /data/kingbase - name: config mountPath: /data/kingbase/kingbase.conf subPath: kingbase.conf - name: license mountPath: /data/kingbase/license.dat subPath: license.dat livenessProbe: exec: command: [ksql, -U, system, -d, test, -c, select 1;] initialDelaySeconds: 60 periodSeconds: 10 timeoutSeconds: 5 readinessProbe: exec: command: [ksql, -U, system, -d, test, -c, select 1;] initialDelaySeconds: 30 periodSeconds: 5 volumes: - name: config configMap: name: kingbase-config - name: license secret: secretName: kingbase-license volumeClaimTemplates: - metadata: name: data spec: accessModes: [ ReadWriteOnce ] storageClassName: ssd-sc resources: requests: storage: 100Gi --- # Headless 服务 apiVersion: v1 kind: Service metadata: name: kingbase-headless namespace: kingbase labels: app: kingbase spec: clusterIP: None selector: app: kingbase ports: - port: 54321 targetPort: db --- # 业务访问服务 apiVersion: v1 kind: Service metadata: name: kingbase-svc namespace: kingbase spec: type: ClusterIP selector: app: kingbase ports: - port: 54321 targetPort: db3.3 主从架构扩展在单节点基础上扩展为一主一备流复制架构StatefulSet 副本数改为 2新增 init 容器自动判断主备角色第一个 Pod 为主库第二个 Pod 通过 sys_basebackup 从主库拉取数据并启动备库配置 pg_hba.conf 白名单允许复制用户通信通过 Sidecar 容器监控主备状态主库故障时自动提升备库生产级建议主备切换逻辑复用金仓原生流复制能力不要自研切换逻辑避免脑裂风险。四、达梦 DM9 K8s 部署实战4.1 架构特点达梦数据守护原生依赖 MAL 同步链路、守护进程、确认监视器K8s 化时需重点保障每个实例有稳定的网络标识Headless Service 域名MAL 通信端口互通守护进程与数据库进程同 Pod 运行4.2 核心部署 YAMLapiVersion: apps/v1 kind: StatefulSet metadata: name: dameng namespace: dameng spec: serviceName: dameng-headless replicas: 2 selector: matchLabels: app: dameng template: metadata: labels: app: dameng spec: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-role/database operator: In values: [true] securityContext: fsGroup: 1000 containers: - name: dmserver image: dameng:dm9 imagePullPolicy: IfNotPresent ports: - containerPort: 5236 name: db - containerPort: 5336 name: mal env: - name: SYSDBA_PWD valueFrom: secretKeyRef: name: dameng-secret key: sysdba-password resources: requests: cpu: 4 memory: 8Gi limits: cpu: 8 memory: 16Gi volumeMounts: - name: data mountPath: /dm/data - name: dm-ini mountPath: /dm/data/DAMENG/dm.ini subPath: dm.ini - name: dm-key mountPath: /dm/data/DAMENG/dm.key subPath: dm.key command: [/bin/bash, -c] args: - | # 启动脚本首次启动初始化实例后续直接启动 if [ ! -f /dm/data/DAMENG/dm.ini ]; then dminit PATH/dm/data DB_NAMEDAMENG INSTANCE_NAME$HOSTNAME PORT_NUM5236 SYSDBA_PWD$SYSDBA_PWD fi dmserver /dm/data/DAMENG/dm.ini livenessProbe: exec: command: [disql, SYSDBA/${SYSDBA_PWD}, -c, select 1;] initialDelaySeconds: 90 periodSeconds: 10 volumes: - name: dm-ini configMap: name: dameng-config - name: dm-key secret: secretName: dameng-license volumeClaimTemplates: - metadata: name: data spec: accessModes: [ ReadWriteOnce ] storageClassName: ssd-sc resources: requests: storage: 100Gi4.3 数据守护集群扩展完整的达梦数据守护 K8s 部署需要额外部署守护进程容器与数据库实例同 Pod运行 dmwatcher监控实例状态确认监视器独立 Deployment部署在第三节点负责故障仲裁防止脑裂服务切换机制主库故障时自动更新 Service 标签选择器将流量指向新主库关键注意点MAL 配置中使用 Headless Service 域名如 dameng-0.dameng-headless替代固定 IP保证 Pod 重建后通信正常。五、云原生运维体系建设 5.1 监控告警体系指标采集人大金仓使用 postgres_exporter 适配兼容绝大多数 PG 系监控指标达梦数据库使用官方 dm_exporter 或自定义 SQL 采集核心指标监控面板Grafana 定制仪表盘覆盖连接数、TPS、缓存命中率、慢 SQL、主备延迟告警规则实例宕机、主备延迟过大、连接数满、磁盘使用率高、慢 SQL 突增日志采集EFK 栈收集数据库运行日志、审计日志支持全文检索与异常告警 5.2 备份与恢复物理备份定时任务 CronJob 调用数据库原生备份工具sys_basebackup /dmrman备份到对象存储快照备份利用存储卷快照能力快速创建时间点备份恢复速度快恢复验证定期启动临时 Pod 挂载备份卷验证备份可用性容灾方案跨可用区部署主备节点数据异步复制满足容灾要求⚙️ 5.3 日常运维操作运维操作K8s 环境实现方式启停实例kubectl scale / kubectl delete pod参数修改修改 ConfigMap滚动重启 Pod主备切换数据库内执行切换命令更新 Service 标签扩容存储修改 PVC 容量StorageClass 支持自动扩容版本升级滚动更新 StatefulSet 镜像先备后主日志查看kubectl logs / 日志平台检索 5.4 授权方案优化针对国产数据库绑定 IP / 主机名的问题生产级解决方案节点固定方案通过节点亲和性 容忍度将数据库 Pod 固定在指定节点IP / 主机名稳定适配传统授权模式最常用云授权模式申请厂商的云环境授权基于集群 UUID 或节点池授权支持 Pod 漂移硬件加密锁通过 USB 重定向或加密卡直通绑定硬件授权安全性最高六、十大生产避坑指南 以下是国产数据库上 K8s 最高频的踩坑点90% 的项目都栽过跟头。坑 1用 NFS / 普通文件存储跑数据库现象性能极差写入延迟几百毫秒数据库经常卡顿根因数据库是随机 IO 密集型NFS 协议延迟高、IOPS 低完全不适合数据库避坑生产必须用本地 SSD 或高性能分布式块存储IO 性能接近物理机再上线坑 2依赖 K8s 自愈不做数据库层高可用现象Pod 异常重启后数据库启动失败数据损坏根因K8s 只能保证进程重启无法保障数据库事务一致性异常断电级别的重启极易损坏数据页避坑必须部署数据库原生主从架构K8s 只做辅助自愈核心高可用靠数据库本身坑 3License 绑定 IPPod 漂移后授权失效现象节点故障后 Pod 漂移到其他节点数据库启动失败报授权错误根因传统授权绑定主机 IP/MACK8s 动态调度后环境变化避坑优先用节点亲和性固定 Pod 运行节点或申请云原生授权模式坑 4资源限制不合理触发 OOM现象数据库运行一段时间被 K8s 杀掉日志显示 OOMKilled根因只算了 shared_buffers没算连接进程内存、维护内存limits 设置过小避坑内存 limits 按 shared_buffers × 2.5 以上估算预留足够的连接进程内存禁止设置内存 Qos 为 Guaranteed坑 5配置文件修改不生效现象改了 ConfigMap重启 Pod 后配置还是旧的根因使用 subPath 挂载单个文件时ConfigMap 更新不会自动同步到容器内避坑修改配置后执行滚动重启或使用配置热加载命令数据库内动态生效坑 6数据守护 MAL 配置用 IP重建后通信中断现象Pod 重建后 IP 变化主备同步中断根因MAL 配置写死 IPPod 重建后 IP 变更避坑全部使用 Headless Service 的稳定域名进行通信IP 变化不影响坑 7没有数据备份PV 误删数据全丢现象误删 PVC / 命名空间存储卷被回收数据永久丢失根因过度依赖存储持久化没有独立的备份机制避坑定期全量备份 归档备份备份数据存到独立对象存储与 K8s 集群生命周期解耦坑 8探针设置不合理频繁重启数据库现象数据库启动慢存活探针超时K8s 反复杀掉重启陷入死循环根因initialDelaySeconds 设置太短数据库还没启动完就被判定为异常避坑延长初始化探测时间区分存活探针和就绪探针就绪探针失败不重启 Pod坑 9多实例混部资源争抢严重现象多个数据库 Pod 跑在同一节点高峰期互相争抢 IO整体性能都很差避坑数据库节点做专属池通过污点与容忍度隔离禁止其他业务混部单节点数据库实例数严格控制坑 10运维完全 K8s 化DBA 无法排障现象出了问题只会看 Pod 状态不会进数据库排查故障定位极慢避坑保留传统数据库运维入口DBA 可通过域名直连数据库K8s 只负责编排与自愈核心排障还是数据库原生思路七、全文总结国产数据库云原生化是大势所趋但现阶段不能为了云原生而云原生必须在保障数据安全、性能、稳定的前提下逐步拥抱云原生能力。落地时把握三个核心存储是底线IO 性能不达标一切都是空谈数据库层高可用为主不要迷信 K8s 自愈数据一致性永远靠数据库原生架构循序渐进先测试环境、再非核心、最后核心系统逐步积累经验稳步推进信创 云原生的组合最终目标是提升交付效率与资源利用率而不是牺牲稳定性追技术热点。找到适合自身业务的平衡点才是最优