KubeBlocks 面试题库
30 道题- 分类
- Kubernetes
- 子分类
- db
- 题目数
- 30 道
1 KubeBlocks 的核心定位与架构设计理念
答案:
KubeBlocks 是一个基于 Kubernetes Operator 模式构建的开源数据库管控平台,核心定位是为 Kubernetes 上的数据库和有状态工作负载提供统一的运维自动化框架。
分层架构
| 层级 | 说明 |
|---|---|
| 基础设施层 | Kubernetes 原生资源(Pod/PVC/Service/ConfigMap/Secret) |
| 编排引擎层 | CRD 体系:ClusterDefinition / ComponentDefinition / Cluster / OpsRequest / Backup 等 |
| 协议适配层 | Lorry Sidecar 提供角色检测、配置重载、备份代理、高可用仲裁等数据库协议适配能力 |
| Addon 插件层 | 面向具体数据库的 Addon 封装(MySQL/PostgreSQL/Redis/MongoDB/Kafka 等),以 Helm Chart 形式打包发布 |
核心设计理念
- 引擎无关:通过 Addon 机制解耦数据库引擎,任一数据库均可通过新增 Addon 接入 KubeBlocks 管控体系。
- 声明式管理:所有运维操作通过 CRD 声明意图,Controller 通过 Reconcile Loop 将现状(Status)向期望(Spec)收敛。
- 组件化编排:将数据库拓扑拆解为 Component,每个 Component 由 ComponentDefinition 定义其工作负载类型、配置模板、角色、Service 等完整生命周期行为。
- Day-2 自动化:内置配置变更、版本升级、扩缩容、备份恢复、故障自愈、节点重建等运维操作,通过统一的 OpsRequest CRD 抽象。
- 多云可移植:基于 Kubernetes API 标准,不绑定特定云厂商,可在任意 Kubernetes 集群运行。
2 KubeBlocks 的 API 体系(ComponentDefinition / ComponentVersion / ClusterDefinition / Cluster)
答案:
KubeBlocks 的核心 API 体系由三层 CRD 构成:Cluster(集群实例层)、ClusterDefinition(引擎抽象层)、ComponentDefinition(组件定义层)。
CRD 职责矩阵
| CRD | 作用域 | 职责 | 典型内容 |
|---|---|---|---|
| ComponentDefinition | 引擎/Addon | 定义单个组件的工作负载、Pods、Service、配置模板、角色 Probe 脚本、生命周期 Action | workloadType、Probes(RoleProbe/StatusProbe)、VolumeProtectionSpec、LifecycleActions |
| ComponentVersion | 引擎/Addon | 组件版本与镜像映射 | Release、CompatibilityRules、ConfigSpecs(与该版本关联的配置模板) |
| ClusterDefinition | 引擎/Addon | 将多个 Component 组合为完整拓扑(如 Proxy + Compute + Storage 三层) | ComponentGroup、Topology、ClusterVersion |
| Cluster | 用户 | 用户创建的数据库实例,指定 Addon、版本、组件数量和规格 | ComponentSpecs(Replicas/Resources/VolumeClaimTemplates/TerminationPolicy) |
层级关系
ClusterDefinition (拓扑模板)
└── ComponentDefinition (组件定义)
└── ComponentVersion (版本与镜像)
└── Cluster (用户实例)
# 示例:Cluster 用户声明
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: my-mysql
spec:
clusterDefinitionRef: apecloud-mysql # 引用 ClusterDefinition
componentSpecs:
- name: mysql
componentDefRef: mysql # 引用 ComponentDefinition
replicas: 3
resources:
requests:
cpu: "4"
memory: 8Gi
volumeClaimTemplates:
- name: data
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 100Gi
3 KubeBlocks 的 Addon 插件机制
答案:
Addon 是 KubeBlocks 的数据库引擎接入方案,每个 Addon 将一种数据库的完整管控逻辑打包为 Helm Chart,通过 kbcli addon 子命令进行生命周期管理。
Addon 包的构成
postgresql-addon/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── clusterdefinition.yaml # 数据库拓扑定义
│ ├── componentdefinition.yaml # 组件工作负载与生命周期
│ ├── componentversion.yaml # 版本与镜像映射
│ ├── scripts.yaml # 配置模板(ConfigMap)
│ └── grafana-dashboard.yaml # 监控仪表板
Addon 管理命令
kbcli addon list # 列出已安装 Addon
kbcli addon search mysql # 搜索可用 Addon
kbcli addon install apecloud-mysql # 安装 MySQL Addon
kbcli addon enable apecloud-mysql # 启用 Addon
kbcli addon disable apecloud-mysql # 禁用 Addon
kbcli addon uninstall apecloud-mysql # 卸载 Addon
Addon 版本管理
| 特性 | 说明 |
|---|---|
| Addon 版本索引 | 官方维护 Addon 索引仓库(addon-index),每个 Addon 列出可用版本 |
| 版本锁定 | 用户通过 Cluster 的 componentVersion 字段锁定数据库引擎版本 |
| 升级路径 | 支持 X.Y.Z → X.Y.Z+1 的滚动升级与原地升级两种策略 |
4 ComponentDefinition 与组件编排
答案:
ComponentDefinition 是 KubeBlocks 的核心抽象之一,定义了单个数据库组件的完整生命周期行为。它描述了一个组件的运行时形态(Pod 规格)、配置(Config Template)、角色语义(Role/Readiness Probe)、状态检查(Status Probe)以及运维操作(Lifecycle Actions)。
ComponentDefinition 核心字段
| 字段 | 说明 |
|---|---|
| workloadType | 工作负载类型:Replication(RSM)/ Consensus(Raft-based)/ Stateless(Deployment) |
| probes | 探针配置,包括 RoleProbe、StatusProbe、RunningProbe |
| podSpec | Pod 模板,包含容器镜像、端口、Env、Liveness Probe、VolumeMounts |
| monitor | 监控 Exporter 配置(端口、路径) |
| configs | 配置模板引用,指定 ConfigMap 名和挂载路径 |
| lifecycleActions | 生命周期 Action:postProvision / preTerminate / switchover / memberJoin / memberLeave / dataDump / dataLoad |
| services | 为组件自动创建的 Service 定义(读写 Service / 只读 Service / 无头 Service) |
| volumes | 存储卷定义,由 VolumeClaimTemplate 或 HostPath 提供 |
| systemAccounts | 系统账号(如 root、replicator)及其密码生成策略 |
角色定义与探针
probes:
roleProbe:
failureThreshold: 3
periodSeconds: 2
commands:
polling:
- mysql
- -uroot
- -e
- "SELECT role FROM apecloud_mysql.consensus_info"
ComponentDefinition 通过内置的 Role Probe 脚本自动检测 Pod 的数据库角色(如 Primary / Secondary),并将角色写入 Pod Annotation 与 Label,供 Service Selector 的路由决策使用。
5 RSM(Replicated State Machine)工作负载
答案:
RSM 是 KubeBlocks 自定义的 Kubernetes 控制器(CRD),专用于管理有状态复制集群的工作负载,如数据库主从架构。它是 StatefulSet 的增强替代,提供了更精细的 Pod 生命周期控制。
RSM 与 StatefulSet 对比
| 特性 | StatefulSet | RSM |
|---|---|---|
| Pod 独立更新 | 仅支持 OnDelete / RollingUpdate(全局策略) | 支持按实例(Instance)粒度的更新策略 |
| 成员角色感知 | 不支持 | 原生支持 Primary/Secondary 角色管理 |
| 成员变更事件 | 不提供 | 触发 MemberJoin/MemberLeave Action |
| 实例排序 | 严格按序号启动(0→1→2) | 支持并行启动,仅保证角色顺序 |
| 角色驱动的 Service | 需手动管理 | 自动生成 ReadWrite / Readonly Service |
| 实例重试策略 | 固定 Backoff | 可配置 BackoffLimit 和重试策略 |
RSM 架构
RSM Controller
├── 管理 N 个 InstanceSet(分组管理 Pod)
├── 通过 Role Probe 检测每个 Pod 的角色
├── 根据角色调整 Pod 的就绪状态和 Service 路由
└── Pod 更新时按角色顺序执行(先 Secondary,后 Primary)
RSM 的核心价值在于将"数据库角色感知"内置到工作负载控制器中,使得升级、扩缩容等操作可以按数据库语义(而非 Pod 序号)安全执行。
6 Day-2 运维自动化实现
答案:
KubeBlocks 将 Day-2 运维操作统一抽象为 OpsRequest CRD,涵盖数据库上线后全生命周期的自动化运维场景。
Day-2 运维场景全景
| 场景 | OpsRequest 类型 | 触发方式 | 说明 |
|---|---|---|---|
| 垂直扩容 | VerticalScaling | kbcli / kubectl | 调整 Pod 的 CPU/Memory Request |
| 水平扩容 | HorizontalScaling | kbcli / kubectl | 增减副本数量 |
| 存储扩容 | VolumeExpansion | kbcli / kubectl | 扩容 PVC |
| 版本升级 | Upgrade | kbcli / kubectl | 升级数据库引擎镜像 |
| 配置变更 | Reconfiguring | kbcli / kubectl | 修改数据库运行时参数 |
| 重建实例 | RebuildInstance | kbcli / kubectl | 重建指定 Pod 的 PVC |
| 重启 | Restart | kbcli / kubectl | 滚动重启所有 Pod |
| 主从切换 | Switchover | kbcli / kubectl | 手动触发 Primary 切换 |
| 备份 | Backup | kbcli / kubectl | 按需创建备份 |
| 恢复 | Restore | kbcli / kubectl | 从备份恢复集群 |
执行流程
User → OpsRequest (Create)
→ OpsRequest Controller (Validate + Admission)
→ 将 OpsRequest 转化为针对 Pod/Component 的具体操作
→ 调用 RSM Controller 执行分批更新
→ Lorry Sidecar 在每个 Pod 上执行 Pre/Post Hook(如停写、切换 VIP)
→ 更新 OpsRequest.Status 反映阶段进展
opsDefinition:每个 ComponentDefinition 中声明该组件支持的运维操作类型和参数约束,作为 OpsRequest 的准入规则。
7 Configuration 参数模板热更新机制
答案:
KubeBlocks 通过 Configuration CRD 实现数据库参数的声明式管理和热更新。它将数据库配置文件(如 MySQL 的 my.cnf、PostgreSQL 的 postgresql.conf)模板化为 ConfigMap,并通过 ConfigConstraint 定义参数的取值范围和动态生效方式。
Configuration 架构
Configuration CR
├── ConfigConstraint(参数约束)
│ ├── StaticParameters(仅重启生效)
│ ├── DynamicParameters(可动态生效)
│ └── ImmutableParameters(不可变更)
├── ConfigSpec(引用 ConfigMap 模板)
└── Cluster(关联集群)
参数变更流程
# 步骤 1:创建 reconfiguring OpsRequest
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: my-mysql-config-change
spec:
clusterRef: my-mysql
type: Reconfiguring
reconfiguring:
- componentName: mysql
configFile: my.cnf
parameters:
- key: max_connections
value: "500"
- key: innodb_buffer_pool_size
value: "2G"
动态参数 vs 静态参数处理差异
| 参数类型 | 生效方式 | 示例 |
|---|---|---|
| DynamicParameter | Lorry Sidecar 调用 SET GLOBAL / pg_reload_conf() 即时生效 | max_connections、slow_query_log |
| StaticParameter | 更新 ConfigMap → 滚动重启 Pod 后生效 | innodb_buffer_pool_size(MySQL 旧版本) |
| ImmutableParameter | 创建集群时指定,创建后不可变更 | datadir、port |
热更新执行链路
OpsRequest → ConfigConstraint 校验 → 分类参数(Static/Dynamic)
→ Static: 更新 ConfigMap, 滚动重启 Pod
→ Dynamic: Lorry 调用引擎的运行时 API 应用参数
→ 同时更新 ConfigMap 保持声明与运行时一致
8 Backup CRD 与备份恢复
答案:
KubeBlocks 通过 Backup、BackupPolicy、BackupRepo、RestoreJob 四类 CRD 实现数据库备份恢复的声明式管理。
备份 CRD 体系
| CRD | 级别 | 职责 |
|---|---|---|
| BackupPolicyTemplate | ComponentDefinition 级 | 定义组件支持的备份方式(全量/增量/日志)、备份工具(xtrabackup/pg_dump/mongodump 等) |
| BackupPolicy | Cluster 级 | 关联备份仓库和调度策略(CronExpression、Retention) |
| BackupRepository | 集群级 | 备份存储后端(S3/GCS/OSS/NFS/PVC) |
| Backup | 实例级 | 单个备份任务的声明,引用 BackupPolicy |
| RestoreJob | 实例级 | 从 Backup 恢复为新集群 |
备份类型
| 类型 | 说明 | 工具 |
|---|---|---|
| Full Backup(全量) | 数据库的完整快照 | xtrabackup / pg_basebackup / mongodump / redis-check-rdb |
| Incremental Backup(增量) | 基于上次全量备份的增量变化 | xtrabackup –incremental |
| Log Backup(日志/WAL) | 连续归档 WAL/Redo Log/Binlog,支持 Point-in-Time Recovery | pg_receivewal / mysqlbinlog |
备份流程
# 创建备份策略
kbcli cluster edit-backup-policy my-pg \
--backup-repo s3-repo \
--cron "0 2 * * *" \
--retention 7
# 按需创建备份
kbcli cluster backup my-pg --backup-type full
# 从备份恢复到新集群
kbcli cluster restore my-pg-restored \
--backup-name my-pg-backup-20250101 \
--restore-to-time "2025-01-01T10:30:00Z" # PITR
BackupRepository 后端支持
- S3(AWS S3 协议兼容)
- GCS(Google Cloud Storage)
- OSS(Aliyun Object Storage Service)
- OBS(Huawei Cloud Object Storage)
- NFS(通过 PV 挂载)
- PVC(本地 PVC)
9 OpsRequest CRD(扩容/升级/重启/重建/配置变更)
答案:
OpsRequest 是 KubeBlocks 用于统一表达运维操作意图的 CRD,将所有 Day-2 运维场景标准化为一种资源类型,由 OpsRequest Controller 负责协调执行。
OpsRequest 类型全景
| 类型 | 触发场景 | 关键参数 |
|---|---|---|
| VerticalScaling | 调整 CPU/Memory | Components[].Resources.Requests/Limits |
| HorizontalScaling | 增减副本 | Components[].Replicas |
| VolumeExpansion | 扩容 PVC | Components[].VolumeClaimTemplates[].Storage |
| Upgrade | 版本升级 | ClusterVersionRef |
| Reconfiguring | 修改参数 | Components[].Parameters[] |
| Restart | 滚动重启 | Components[] |
| Stop | 停止集群 | Components[] |
| Start | 启动已停止集群 | Components[] |
| RebuildInstance | 重建实例 | Instances[] |
| Switchover | 主从切换 | ComponentName |
| Custom | 自定义运维(Addon 定义) | 取决于 addon |
OpsRequest 状态机
Pending → Creating → Running → Succeed / Failed
↓
Cancelling → Cancelled
示例:水平扩容
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: scale-out-mysql
spec:
clusterRef: my-mysql
type: HorizontalScaling
horizontalScaling:
- componentName: mysql
replicas: 5
示例:垂直扩容
kbcli cluster vscale my-pg --components pg=memory=8Gi,cpu=4
调用链路:OSSRequest Controller 将 vscale 请求转换为对 Cluster.Spec.ComponentSpecs[].Resources 的修改,通过 RSM Controller 按 Secondary → Primary 顺序滚动更新 Pod。
10 多组件拓扑与 ShardingDefinition
答案:
KubeBlocks 支持定义多组件的分布式数据库拓扑,将分片(Sharding)、代理(Proxy)、协调节点(Coordinator)等组件组合为一个统一的 Cluster。
ClusterDefinition 组件组
apiVersion: apps.kubeblocks.io/v1alpha1
kind: ClusterDefinition
metadata:
name: apecloud-mysql-cluster
spec:
componentDefs:
- name: mysql-compdef # 计算 + 存储组件
componentDefRef: apecloud-mysql
- name: proxy-compdef # 代理组件(读写分离)
componentDefRef: apecloud-mysql-proxy
topology: # 拓扑编排策略
- name: standalone
components:
- name: mysql
compDef: mysql-compdef
- name: replication
components:
- name: mysql
compDef: mysql-compdef
- name: proxy
compDef: proxy-compdef
- name: sharding
shardingSpec: # 分片编排
shardingDefRef: mysql-sharding
ShardingDefinition 字段
| 字段 | 说明 |
|---|---|
| shards | 分片数量 |
| template | 每个分片的组件模板(ComponentDefRef + 副本数 + 资源规格) |
| proxyComponent | 可选的代理组件,自动感知分片拓扑变化 |
分片集群创建
kbcli cluster create my-sharded-mysql \
--cluster-definition apecloud-mysql \
--topology sharding \
--shards 4 \
--set mysql.replicas=3 \
--set proxy.replicas=2
每个 Shard 是一个独立的 RSM 组,Proxy 组件(如 ProxySQL/Vitess VTGate)自动感知 Shard 的增减并更新路由配置。
11 KubeBlocks 对 MySQL 的支持与常见拓扑
答案:
KubeBlocks 通过 apecloud-mysql Addon 提供 MySQL 数据库全生命周期管理,底层使用 ApeCloud 基于 MySQL 开源分支构建的增强版本,集成 Raft Consensus 协议实现自动故障切换。
支持的 MySQL 版本
| 版本系列 | 内核类型 | 说明 |
|---|---|---|
| 8.0.x | apecloud-mysql(Raft-based) | 默认 Addon,内置共识协议,自动选主 |
| 8.0.x | oracle-mysql(官方 MySQL) | 基于 Orchestrator / MHA 的半同步复制 |
| 5.7.x | apecloud-mysql | 5.7 版本的 Raft 分支 |
常见拓扑
| 拓扑 | 组件组成 | 适用场景 |
|---|---|---|
| Standalone | 1 个 MySQL 实例,1 个 Proxy 实例 | 开发 / 测试环境 |
| Replication | 1 Primary + N Secondary,前面挂 Proxy(读写分离) | 生产 OLTP,读多写少 |
| Sharding | N 个 Shard(每Shard 3 副本)+ Proxy 层 | 大规模数据,水平扩展 |
架构示意(Replication 拓扑)
Client
|
[ProxySQL/VTTablet] ← 读写分离 (R + W)
/ | \
[Primary] [Secondary] [Secondary] ← RSM 管理,Raft Consensus 选主
|
[Lorry Sidecar] ← 角色检测, 配置热更新, 备份代理
创建 MySQL 集群
kbcli cluster create my-mysql \
--cluster-definition apecloud-mysql \
--topology replication \
--set mysql.replicas=3 \
--set mysql.resources.cpu=4 \
--set mysql.resources.memory=8Gi \
--set mysql.storage=100Gi
12 KubeBlocks 对 PostgreSQL 的支持与常见拓扑
答案:
KubeBlocks 通过 apecloud-postgresql Addon 提供 PostgreSQL 数据库的管控能力,支持流复制(Streaming Replication)和 Patroni-based 高可用架构。
支持的 PostgreSQL 版本
- PostgreSQL 12 / 13 / 14 / 15 / 16(官方社区版)
- 基于 Patroni 的高可用方案(Etcd 作为 DCS)
拓扑支持
| 拓扑类型 | 组件组成 | 说明 |
|---|---|---|
| Standalone | 1 个 PostgreSQL 实例 | 无高可用 |
| Replication | 1 Primary + N Standby | Patroni 自动选主 + VIP 漂移 |
| Distributed (Citus) | Coordinator + Workers | 分布式 PostgreSQL |
Replication 拓扑架构
Client
|
[PgBouncer] ← 连接池,读写分离
/ \
[Primary] [Standby-1] [Standby-2]
| | |
[Patroni] [Patroni] [Patroni] ← 高可用管理
| | |
Etcd Cluster (3 节点) ← DCS 分布式一致性存储
创建 PostgreSQL 集群
kbcli cluster create my-pg \
--cluster-definition apecloud-postgresql \
--topology replication \
--set postgresql.replicas=3 \
--set postgresql.resources.cpu=4 \
--set postgresql.resources.memory=8Gi \
--set postgresql.storage=200Gi
PostgreSQL 特有的 OpsRequest
| OpsRequest | 说明 |
|---|---|
| Switchover | Patroni 触发 patronictl switchover |
| RebuildInstance | 使用 pg_basebackup 重建 Standby |
| Restart | Patroni 协调重启(先 Standby 后 Primary) |
| Recovery / PITR | 支持基于 PITR 的时间点恢复 |
13 KubeBlocks 对 Redis 的支持
答案:
KubeBlocks 通过 Redis Addon 管理 Redis 集群的部署与运维,支持 Standalone、Replication(主从)、Cluster(分片集群)和 Sentinel(哨兵模式)四种拓扑。
拓扑模式
| 模式 | 说明 | 高可用 | 数据分片 |
|---|---|---|---|
| Standalone | 单实例 | 无 | 无 |
| Replication | 1 Master + N Slave | 手动切换 | 无 |
| Sentinel | Master-Slave + Sentinel 节点(3 或 5 个) | 自动故障切换 | 无 |
| Redis Cluster | N 个 Master + N 个 Slave,Hash Slot 分片 | 自动故障切换 | 16384 槽 |
Redis Cluster 架构
Client
|
[Redis Proxy / Smart Client]
|
+---------+---------+---------+
| | | |
[M1] [M2] [M3] [M4] [M5] ← 5 个 Master,各负责部分 Slot
[S1] [S2] [S3] [S4] [S5] ← 每个 Master 配一个 Slave
创建 Redis 集群
# Sentinel 模式
kbcli cluster create my-redis-sentinel \
--cluster-definition redis \
--topology sentinel \
--set redis.replicas=3 \
--set sentinel.replicas=3
# Redis Cluster 模式
kbcli cluster create my-redis-cluster \
--cluster-definition redis \
--topology cluster \
--shards 3 \
--set redis.replicas=2
Redis 特有配置管理
| 配置项 | 说明 | 生效方式 |
|---|---|---|
| maxmemory | 最大内存 | CONFIG SET(热更新) |
| maxmemory-policy | 淘汰策略 | CONFIG SET(热更新) |
| save(RDB) | 持久化策略 | 需重启 |
| cluster-node-timeout | 集群超时 | CONFIG SET(热更新) |
| appendonly | AOF 开关 | 需重启 |
14 KubeBlocks 对 MongoDB 的支持
答案:
KubeBlocks 通过 MongoDB Addon 管理 MongoDB 副本集(ReplicaSet)和分片集群(Sharded Cluster)两种拓扑,支持 MongoDB 4.x / 5.x / 6.x / 7.x 版本。
拓扑支持
| 拓扑 | 组件 | 说明 |
|---|---|---|
| Replicaset | 1 Primary + N Secondary(+ 可选的 Arbiter) | 基于 Raft 的副本集 |
| Sharded Cluster | Config Server Replicaset + N 个 Shard Replicaset + Mongos Router | 分片集群 |
MongoDB Sharded Cluster 架构
Application
|
[mongos-1] [mongos-2] ← 查询路由层
/ \
[Config Server Replicaset] ← 元数据存储(3 节点)
|
+--------+--------+--------+
| | | |
[Shard-1] [Shard-2] [Shard-3] [Shard-4] ← 数据分片层
(3 nodes) (3 nodes) (3 nodes) (3 nodes)
创建 MongoDB 副本集
kbcli cluster create my-mongo \
--cluster-definition mongodb \
--topology replicaset \
--set mongodb.replicas=3 \
--set mongodb.resources.cpu=2 \
--set mongodb.resources.memory=4Gi \
--set mongodb.storage=100Gi
MongoDB 特有操作
| 操作 | 实现方式 |
|---|---|
| 备份 | mongodump(逻辑)或文件系统快照(物理) |
| 恢复 | mongorestore 或物理文件恢复 |
| 新增 Shard | OpsRequest (HorizontalScaling) → 配置 Shard Replicaset → sh.addShard() |
| 均衡器管理 | Configuration CRD 控制 balancerStart / balancerStop |
15 KubeBlocks 对 Kafka 的支持
答案:
KubeBlocks 通过 Kafka Addon 管理 Kafka 集群的部署与运维,支持 KRaft(Kafka Raft Metadata Mode)和 ZooKeeper 两种元数据管理模式。
拓扑支持
| 模式 | 组件 | 说明 |
|---|---|---|
| Combined(KRaft) | Broker + Controller 合一 | Kafka 3.3+,Controller 内嵌于 Broker |
| Separated(KRaft) | Broker 独立 + Controller 独立(3 或 5 节点) | 生产推荐,Controller 与数据面隔离 |
| ZooKeeper | Broker + ZooKeeper 集群 | Kafka 3.5 前版本 |
KRaft Separated 模式架构
Producer / Consumer
|
+--------+--------+--------+
| | | |
[Broker-1][Broker-2][Broker-3] ← 数据面,处理消息读写
| | |
+--------+--------+
|
[Controller-1][Controller-2][Controller-3] ← 控制面,管理元数据
创建 Kafka 集群(KRaft 模式)
# Combined 模式
kbcli cluster create my-kafka \
--cluster-definition kafka \
--topology combined \
--set kafka.replicas=3 \
--set kafka.storage=200Gi
# Separated 模式
kbcli cluster create my-kafka \
--cluster-definition kafka \
--topology separated \
--set kafka.replicas=3 \
--set controller.replicas=3 \
--set kafka.storage=300Gi
Kafka 特有运维场景
| 场景 | 实现方式 |
|---|---|
| 增加 Broker | HorizontalScaling → 触发 Partition 重分配 |
| 分区重分配 | 通过 kafka-reassign-partitions.sh 工具 |
| Topic 管理 | 通过 CRD 或 kafka-topics.sh CLI |
| 日志清理策略 | Configuration CRD → log.retention.hours / log.segment.bytes |
| ACL 管理 | Configuration CRD → authorizer.class.name 等 |
16 高可用架构(Role/Readiness Probe/MemberJoin/MemberLeave)
答案:
KubeBlocks 的高可用架构基于三层机制协同工作:角色检测(Role Probe)、成员变更回调(MemberJoin/MemberLeave)、以及 Readiness Probe 驱动的 Service 路由。
高可用机制一览
| 机制 | 实现方式 | 作用 |
|---|---|---|
| Role Probe | Lorry Sidecar 定期执行角色检测脚本 | 将 Pod 角色(Leader/Primary/Secondary/Follower/Learner)写入 Pod Annotation |
| Readiness Probe | Lorry 根据 Role 动态设置 Pod Readiness | 非健康或非就绪角色的 Pod 不接收流量 |
| MemberJoin Action | ComponentDefinition LifecycleActions | 新 Pod 加入集群时的初始化逻辑(如创建复制用户、注册到 Proxy) |
| MemberLeave Action | ComponentDefinition LifecycleActions | Pod 离开集群前的清理逻辑(如从 Proxy 移除、数据重平衡) |
| Switchover Action | ComponentDefinition LifecycleActions | 主从切换时的执行逻辑(如调用 Patroni / Raft 切换 API) |
角色驱动的 Service 路由
# ReadWrite Service(仅路由到 Primary)
apiVersion: v1
kind: Service
metadata:
name: my-mysql-rw
spec:
selector:
app.kubernetes.io/instance: my-mysql
kubeblocks.io/role: primary # 仅匹配 Primary
# Readonly Service(路由到 Secondary)
apiVersion: v1
kind: Service
metadata:
name: my-mysql-ro
spec:
selector:
app.kubernetes.io/instance: my-mysql
kubeblocks.io/role: secondary # 仅匹配 Secondary
故障切换流程
1. Lorry Role Probe 检测到 Primary 不健康
→ 将 Primary Pod 标记为 Unknown / Failed
2. KubeBlocks Controller 触发故障切换
→ 如为 Raft 模式:等待 Raft 集群自动选出新 Leader
→ 如为 Patroni 模式:Patroni 通过 Etcd 协调切换
3. Controller 更新 Pod Label(role: primary → secondary, role: secondary → primary)
4. Service Selector 自动更新,流量切至新 Primary
5. MemberLeave Action 在旧 Primary Pod 上执行清理
6. MemberJoin Action 在新 Primary Pod 上执行初始化
17 存储管理(VolumeClaimTemplate / 动态 PV)
答案:
KubeBlocks 的存储管理基于 Kubernetes 原生 PVC/PV 机制,通过 VolumeClaimTemplate 在 ComponentDefinition 中声明存储需求,每个 Pod 独立绑定 PVC。
存储配置方式
| 方式 | 说明 |
|---|---|
| VolumeClaimTemplate(默认) | 每个 Pod 动态创建独立 PVC,通过 StorageClass 自动 Provisioning |
| HostPath | 仅用于开发/测试环境 |
| EmptyDir | 仅用于临时数据 |
VolumeClaimTemplate 示例
componentSpecs:
- name: mysql
volumeClaimTemplates:
- name: data # 数据目录
spec:
accessModes: [ReadWriteOnce]
storageClassName: ssd-storageclass
resources:
requests:
storage: 100Gi
- name: log # 日志目录(Binlog / WAL)
spec:
accessModes: [ReadWriteOnce]
storageClassName: hdd-storageclass
resources:
requests:
storage: 50Gi
PVC 生命周期管理
| 策略 | 说明 |
|---|---|
| Delete | 删除集群时同步删除 PVC(kubeblocks.io/termination-policy: Delete) |
| Retain | 删除集群时保留 PVC(kubeblocks.io/termination-policy: Retain) |
| DoNotTerminate | 阻止删除操作 |
存储扩容
kbcli cluster volume-expand my-mysql --components mysql=data=200Gi
扩容流程:Controller 先调用 StorageClass 的 AllowVolumeExpansion 能力 → 更新 PVC.Spec.Resources.Requests → CSI Driver 执行底层存储扩容 → 在 Pod 内热扩展文件系统(resize2fs 或 xfs_growfs)。
数据保护(Volume Protection)
ComponentDefinition 支持 VolumeProtectionSpec:定义 PVC 的保护策略,如设置 PVC Finalizer,防止误删数据。
18 滚动升级与原地升级
答案:
KubeBlocks 支持两种数据库引擎版本升级策略:滚动升级(Rolling Update)和原地升级(InPlace Update)。
两种升级策略对比
| 特性 | 滚动升级 | 原地升级 |
|---|---|---|
| 机制 | 逐个删除旧 Pod 并创建新 Pod | 在 Pod 内停止旧进程,替换二进制后启动新进程 |
| Pod IP 是否变化 | 是(重建 Pod) | 否(仅替换容器镜像) |
| 数据 PVC 是否重建 | 否(复用原有 PVC) | 否(完全复用) |
| 服务中断 | 每个 Pod 短暂中断(取决于切换时间) | 仅在重启进程时短暂中断 |
| 适用场景 | 跨大版本升级、内核替换 | 小版本升级(补丁更新) |
| 支持条件 | 所有数据库类型 | 需引擎支持(镜像内嵌多版本二进制) |
原地升级镜像结构
apecloud-mysql:8.0.30-20240101
├── /opt/mysql/
│ ├── 8.0.29/ ← 旧版本二进制
│ └── 8.0.30/ ← 新版本二进制
├── /opt/mysql/current → symlink to active version
└── switch-version.sh ← 版本切换脚本
原地升级时,Lorry 执行 switch-version.sh 切换符号链接,然后重启数据库进程,实现了同一 Pod 内无缝的版本切换。
升级 OpsRequest
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: pg-upgrade
spec:
clusterRef: my-pg
type: Upgrade
upgrade:
clusterVersionRef: postgresql-15.4.0
strategy: InPlace # 或 RollingUpdate
升级顺序:无论哪种策略,KubeBlocks 均按 Secondary → Primary 的顺序执行 Pod 升级,在 Primary 切换前完成数据同步校验。
19 Lorry Sidecar 容器
答案:
Lorry 是 KubeBlocks 为每个数据库 Pod 注入的 Sidecar 容器,承担数据库协议适配、命令代理、健康探测和运维执行的职责。
Lorry 功能全景
| 功能模块 | 说明 |
|---|---|
| Role Probe | 执行数据库专用的角色检测脚本,将结果写入 Pod Annotation |
| Status Probe | 检测 Pod 数据库进程的就绪状态(如可接受连接、复制延迟是否在阈值内) |
| Configuration Reload | 监听 ConfigMap 变化,调用数据库 API 热更新参数 |
| Backup/Restore Agent | 作为备份工具(xtrabackup/pg_dump)的执行代理,管理备份进程生命周期 |
| HA Orchestration | 执行 MemberJoin / MemberLeave / Switchover 等生命周期 Hook |
| Account Management | 管理系统账号的创建和密码轮换 |
Lorry 与主容器的交互
graph TD
subgraph Pod["Pod"]
Lorry["Lorry<br/>(Sidecar)"]
Main["MySQL/PG/etc<br/>(Main Container)"]
SharedVol["Shared Volume<br/>/var/lib/kubeblocks/"]
end
Lorry <-->|"Unix Socket"| Main
Lorry --> SharedVol
Main --> SharedVol
Lorry 通过 Unix Domain Socket 或本地 HTTP API 与主容器通信,避免了网络开销,也规避了从外部访问数据库的安全风险。
Lorry 配置示例
# ComponentDefinition 中的 Lorry 定义
runtime:
containers:
- name: lorry
image: apecloud/lorry:latest
ports:
- containerPort: 3501 # Lorry HTTP API
- containerPort: 50001 # Probe API
volumeMounts:
- name: scripts
mountPath: /kubeblocks/scripts # 角色检测脚本
- name: config # 挂载配置目录
mountPath: /kubeblocks/conf
20 角色检测与自动化 Leader 选举
答案:
KubeBlocks 通过 Role Probe 机制实现数据库角色的自动检测,结合不同数据库的高可用协议完成自动化 Leader 选举。
角色检测方式
| 数据库 | Role Probe 脚本 | 输出 |
|---|---|---|
| apecloud-mysql (Raft) | SELECT role FROM apecloud_mysql.consensus_info | Leader / Follower / Learner |
| Oracle MySQL | SHOW SLAVE STATUS + SELECT @@read_only | Primary / Secondary |
| PostgreSQL (Patroni) | patronictl list --format json | Leader / Replica / Sync Standby |
| Redis Cluster | redis-cli cluster nodes 解析 | master / slave |
| MongoDB | rs.status().members[].stateStr | PRIMARY / SECONDARY / ARBITER |
| Kafka | 读取 /tmp/kraft/state 元数据 | broker / controller |
Leader 选举机制
| 数据库 | 选举机制 | 说明 |
|---|---|---|
| apecloud-mysql | Raft Consensus | 内嵌 Raft 协议,自动选举,无需外部依赖 |
| Oracle MySQL | Orchestrator / MHA | 外部组件基于 GTID 判断最优候选 Standby |
| PostgreSQL | Patroni + Etcd | Patroni 通过 Etcd 锁竞争 Leader 身份 |
| Redis Cluster | Gossip + Raft-like | 节点间通过 Gossip 协议发现故障,Raft 风格选举 |
| MongoDB | Raft(Replica Set 内) | 副本集内部通过 Raft 选举 Primary |
| Kafka | KRaft(Controller Quorum) | Controller 节点通过 KRaft 协议选举 Active Controller |
Role Probe 更新流程
1. Lorry 每 periodSeconds 执行一次 Role Probe 脚本
2. 解析脚本输出,获取当前 Pod 角色
3. 将角色写入 Pod Labels: kubeblocks.io/role={leader,follower,learner}
4. 触发 Controller 同步 Service Selector
5. 角色变更时触发 MemberJoin/MemberLeave Action
21 网络与服务暴露
答案:
KubeBlocks 在每个 Component 启动时自动创建多个 Kubernetes Service,分别承担不同的流量路由职责。
自动创建的 Service 类型
| Service 名称模式 | 类型 | 选择器 | 用途 |
|---|---|---|---|
<cluster>-<component> | ClusterIP(读写) | role: primary / leader / master | 写流量入口 |
<cluster>-<component>-ro | ClusterIP(只读) | role: secondary / follower / slave | 读流量入口 |
<cluster>-<component>-headless | Headless | 所有 Pod(无角色筛选) | Pod DNS 解析(StatefulSet-like) |
<cluster>-<component>-external(可选) | LoadBalancer / NodePort | role: primary | 外部访问 |
网络接入模式
| 模式 | 说明 | 使用场景 |
|---|---|---|
| 集群内访问 | 通过 ClusterIP Service 或 Headless Service DNS | 同集群内应用连接数据库 |
| NodePort | Service 绑定宿主机端口 | 开发调试、临时外部访问 |
| LoadBalancer | 通过云厂商 LB 暴露 | 生产环境跨集群 / 跨 VPC 访问 |
| Ingress | 通过 Ingress Controller 暴露 | TCP/UDP 流量代理(如 ngrok/HAProxy) |
连接字符串示例
# 读写
mysql -h my-mysql-mysql.default.svc.cluster.local -u root -p
# 只读
mysql -h my-mysql-mysql-ro.default.svc.cluster.local -u readonly -p
网络策略集成
KubeBlocks 支持通过 NetworkPolicy CRD 限制数据库组件的入站流量来源,ComponentDefinition 可声明 networkPolicy 字段定义允许的 Namespace / Pod Selector,实现最小权限网络访问控制。
22 监控仪表板集成(Grafana Dashboard)
答案:
KubeBlocks 在每个 Addon 中内嵌 Grafana Dashboard JSON,部署集群时自动创建 Prometheus PodMonitor / ServiceMonitor,将指标暴露给 Prometheus 并导入预置仪表板。
监控集成架构
Database Pod (MySQL/PostgreSQL/Redis...)
├── Lorry Sidecar (Metrics Exporter 代理)
│ └── 暴露 /metrics (Prometheus 格式)
├── Prometheus PodMonitor / ServiceMonitor
│ └── 自动发现并抓取 /metrics
├── Prometheus Server
│ └── 存储时间序列数据
└── Grafana
└── 导入 Addon 预置 Dashboard
预置监控指标类别
| 监控类别 | 关键指标(Prometheus Metric) | 说明 |
|---|---|---|
| 连接数 | mysql_global_status_threads_connected | 当前活跃连接数 |
| QPS/TPS | mysql_global_status_questions (rate) | 查询/事务吞吐量 |
| 复制延迟 | mysql_slave_status_seconds_behind_master | 主从同步延迟 |
| 缓冲池命中率 | mysql_global_status_innodb_buffer_pool_read_requests / reads | InnoDB 缓存效率 |
| 慢查询 | mysql_global_status_slow_queries | 慢查询计数 |
| 锁等待 | mysql_global_status_innodb_row_lock_waits | 行锁等待 |
| 磁盘使用率 | node_filesystem_avail_bytes | 数据目录磁盘容量 |
| 资源使用 | container_cpu_usage_seconds_total / container_memory_working_set_bytes | CPU / Memory |
内置 Grafana Dashboard
每个 Addon 提供数据库专属仪表板,包含:
- Overview:连接数、QPS、TPS、延迟 P99、资源使用概览
- Replication:主从延迟、Binlog 位点差异、复制状态
- InnoDB / Storage(MySQL):缓冲池、行锁、事务、Redo Log
- Query Analysis(PostgreSQL):Query 耗时分布、索引命中率、死锁统计
- Cluster(Redis):内存使用、Key 数量、命中率、淘汰数
- Broker(Kafka):消息速率、ISR 收缩、Consumer Lag、磁盘使用
Dashboard 配置
# 查看集群的 Grafana Dashboard
kbcli cluster dashboard my-mysql
# 添加自定义监控仪表板
kbcli dashboard install --name custom-mysql --file ./custom-dashboard.json
23 KubeBlocks 与 KubeDB 对比
答案:
| 维度 | KubeBlocks | KubeDB |
|---|---|---|
| 架构理念 | Operator Framework(框架式),通过 Addon 机制接入任意数据库 | 面向特定数据库的独立 Operator,每个数据库类型有独立 Operator |
| 支持数据库 | MySQL、PostgreSQL、Redis、MongoDB、Kafka、Pulsar、StarRocks 等,可通过 Addon 持续扩展 | MySQL、PostgreSQL、MongoDB、Redis、Elasticsearch、MariaDB、Percona XtraDB、ProxySQL |
| API 抽象层次 | 多层抽象:ComponentDefinition → ClusterDefinition → Cluster | 单一层抽象:每种数据库一个 CRD(如 MySQL → MySQL CR) |
| 扩展能力 | 通过 Addon + ComponentDefinition 新增数据库,无需开发 Operator 代码 | 需编写新 Operator(Go 代码),扩展门槛较高 |
| 存储管理 | VolumeClaimTemplate 灵活声明多卷 | 固定卷结构 |
| 备份 | Backup CRD + BackupPolicy + 多种存储后端 | 通过 Stash 组件实现备份 |
| 配置管理 | Configuration CRD + ConfigConstraint(热更新 + 静态参数分类) | 通过 ConfigMap 直接挂载 |
| 监控集成 | 内嵌 Grafana Dashboard + Prometheus PodMonitor | 内置 Prometheus 监控,通过 ServiceMonitor |
| 开源协议 | AGPL-3.0 | AppsCode EULA(企业版收费) |
| 社区成熟度 | 较新(2022 年开源),社区快速增长 | 较成熟(2018 年起),文档体系完善 |
| 适用场景 | 需要统一 API 管理多种数据库、扩展新数据库类型需求频繁的团队 | 已确定使用少数几款数据库、偏好每个数据库独立 Operator 的团队 |
24 KubeBlocks 与 CloudNativePG 对比
答案:
| 维度 | KubeBlocks | CloudNativePG |
|---|---|---|
| 专注领域 | 多数据库通用 Operator Framework | 仅限 PostgreSQL |
| PostgreSQL 原生程度 | 包装 Patroni / 自研方案 | 100% 原生 Kubernetes Operator,无外部依赖(无需 Etcd/Patroni) |
| 高可用 | Patroni + Etcd / Raft-based | 直接管理 PostgreSQL 流复制 + Kubernetes API 选主 |
| 备份恢复 | Backup CRD + 多种后端 | 原生支持 Barman Cloud(S3/Azure/GCS),PITR |
| 配置管理 | Configuration CRD + 热更新 | 通过 PostgresCluster CRD 直接管理 postgresql.conf 和 pg_hba.conf |
| 写能力 | 通用框架,对每种数据库支持深度因 Addon 质量而异 | 对 PostgreSQL 的覆盖深度极高(细粒度参数、HBA 规则、扩展管理) |
| 多数据库支持 | 是 | 否(仅 PostgreSQL) |
| 学习曲线 | 需理解 ComponentDefinition / ClusterDefinition 多层抽象 | 单一 PostgresCluster CRD,学习曲线较平缓 |
| 适用场景 | 统一管控多种数据库的平台团队 | 以 PostgreSQL 为核心、需要深度定制 PG 参数的团队 |
选型建议:若团队仅使用 PostgreSQL,CloudNativePG 提供更原生的 PostgreSQL 体验。若需要统一管理 MySQL/PostgreSQL/Redis/Kafka 等多种数据库,KubeBlocks 的统一 API 和 Addon 扩展能力更具优势。
25 KubeBlocks 与 Vitess Operator 对比
答案:
| 维度 | KubeBlocks | Vitess Operator (PlanetScale) |
|---|---|---|
| 定位 | 通用数据库 Operator Framework | MySQL 水平分片集群的专用 Operator |
| 核心能力 | 多种数据库的 Day-1/2 运维自动化 | MySQL 的大规模水平分片(Sharding) |
| 架构 | CRD 多层抽象 + RSM 工作负载 | Vttablet + VTGate + VTOrc + Topology Service |
| 分片 | 通过 ShardingDefinition 支持,分片拓扑相对固定 | Vitess 原生支持 Resharding(动态增减 Shard,在线数据迁移) |
| 连接管理 | Proxy 组件(如 ProxySQL) | VTGate(智能路由,查询计划生成,连接池) |
| SQL 兼容 | 原生 MySQL 协议 | MySQL 协议子集(部分 DDL/DML 受限) |
| 管理面依赖 | 无外部依赖 | 需要 Etcd(或 Consul/ZooKeeper)作为 Topology Service |
| 适用规模 | 中小规模数据库集群 | 超大规模 MySQL(万级实例),如 YouTube/GitHub 级别 |
| 学习成本 | 中等 | 较高(需理解 Vitess 整套架构和 SQL 限制) |
选型建议:KubeBlocks 适合通用场景的 MySQL 管理(含基本分片),Vitess Operator 适合需要超大规模 MySQL 水平扩展和在线 Resharding 的场景。
26 跨云可移植性(多云/混合云数据库管理)
答案:
KubeBlocks 基于 Kubernetes 标准 API 构建,通过统一的抽象层将数据库运维逻辑与底层基础设施解耦,实现多云和混合云环境中的数据库一致管理。
跨云可移植性架构
KubeBlocks API
|
+------------+------------+
| | |
[AWS EKS] [GCP GKE] [Azure AKS] [Aliyun ACK]
| | | |
gp3 / io2 pd-ssd Managed ESSD PL2
StorageClass StorageClass Disk StorageClass
| | | |
S3 GCS Azure OSS/ MinIO
(Backup) (Backup) Blob(Backup) (Backup)
实现多平台一致性的关键机制
| 机制 | 说明 |
|---|---|
| StorageClass 解耦 | VolumeClaimTemplate 通过 StorageClass 名引用底层存储,而非硬编码卷类型 |
| BackupRepo 抽象 | Backup 支持 S3/GCS/OSS/Azure Blob 等多种对象存储,通过 BackupRepo CRD 统一配置 |
| NodeSelector / Tolerations | 通过 Pod 亲和性策略适配不同云厂商的节点标签体系 |
| Service 类型适配 | 自动根据 LoadBalancer Service 类型创建各云厂商的 LB(AWS NLB / GCP LB / Azure LB) |
| 镜像仓库无关性 | 数据库镜像可从任意 Registry 拉取,不绑定特定镜像仓库 |
多集群管理模式
KubeBlocks 支持通过 kbcli 的多 Kubeconfig 管理:
# 添加多云集群上下文
kbcli context add aws-prod --kubeconfig ~/.kube/aws-config
kbcli context add gcp-prod --kubeconfig ~/.kube/gcp-config
# 切换并操作不同云环境
kbcli context use aws-prod
kbcli cluster list # 列出 AWS 上的数据库集群
kbcli context use gcp-prod
kbcli cluster list # 列出 GCP 上的数据库集群
跨云数据库迁移
KubeBlocks 通过 Backup + Restore 实现跨云数据迁移:在源集群创建备份到对象存储 → 在目标集群从同一对象存储恢复,完成数据库的跨云迁移。
27 故障自愈机制
答案:
KubeBlocks 内置多层故障检测与自愈能力,覆盖 Pod 级、节点级和集群级故障。
故障自愈层级
| 层级 | 故障类型 | 检测方式 | 自愈行为 |
|---|---|---|---|
| 容器/进程 | 数据库进程崩溃 | Liveness Probe | Kubernetes 重启容器 |
| Pod | Pod 不可达 | Readiness Probe + Role Probe | 移除 Service 流量 → 若为 Primary 则触发故障切换 |
| PVC | 磁盘满 | Status Probe(Lorry 检测磁盘用量) | 告警 → 手动触发 VolumeExpansion |
| Node | 节点宕机 | Kubernetes Node Controller | 触发 Pod 漂移到其他节点(PVC 跟随) |
| 集群 | 脑裂 | Role Probe 检测到多 Leader | Raft / Patroni 自动选主,旧 Leader 降级 |
| 数据 | 数据损坏 | 数据库自检(如 InnoDB 恢复) | Lorry 触发 RebuildInstance OpsRequest |
核心自愈流程
graph TD
S1["1. Role Probe 检测到 Primary Pod 不可达(连续 3 次)"]
S2["2. Lorry 将 Pod 标记为 Unknown"]
S3["3. 引擎自动选主<br/>Raft: Raft 集群自动发起 Leader Election<br/>Patroni: 通过 Etcd 发起选主"]
S4["4. 新 Primary 的 Label 更新"]
S5["5. MemberLeave Action 在旧 Pod 执行清理"]
S6["6. Service Selector 自动更新,流量切至新 Primary"]
S1 --> S2 --> S3 --> S4 --> S5 --> S6
Pod 级别故障自愈时间
| 阶段 | 耗时(典型值) |
|---|---|
| Role Probe 检测故障 | 6 秒(2 秒间隔 x 3 次失败阈值) |
| Leader Election(Raft) | 1-3 秒 |
| Service Selector 更新 | < 1 秒 |
| 新 Primary Ready | 取决于数据库启动时间(通常 5-30 秒) |
| 故障切换总时长 | 10-40 秒 |
28 生产环境最佳实践
答案:
集群部署建议
| 实践 | 建议 |
|---|---|
| 副本数 | 生产环境至少 3 副本(Raft Majority: N/2+1),容忍 1 节点故障 |
| 反亲和性 | 配置 PodAntiAffinity,确保副本分布在不同 Worker Node |
| 资源预留 | 使用 Guaranteed QoS(Request = Limit),避免 CPU Throttle 和 OOM Kill |
| 存储 | 使用 SSD 类 StorageClass,IOPS >= 3000,数据目录和日志目录分离 |
| 监控 | 部署 Prometheus + Grafana,启用预置 Dashboard,配置告警规则 |
| 备份 | 配置定期全量备份 + 连续日志归档,保留策略 >= 7 天 |
| 网络 | 使用 NetworkPolicy 限制数据库端口访问来源 |
| 密码管理 | 使用 Secret 管理数据库凭证,启用密码轮换 |
| 删除保护 | 设置 terminationPolicy: DoNotTerminate 防止误删 |
资源规格参考
| 数据库 | 场景 | CPU | Memory | Storage | StorageClass |
|---|---|---|---|---|---|
| MySQL 8.0 | 中等 OLTP | 4-8 Core | 8-16 Gi | 200-500 Gi | SSD |
| PostgreSQL 15 | 中等 OLTP | 4-8 Core | 8-16 Gi | 200-500 Gi | SSD |
| Redis 7 | 缓存 | 2-4 Core | 4-16 Gi | 50-100 Gi | SSD |
| MongoDB 6 | 文档存储 | 4-8 Core | 8-32 Gi | 500 Gi - 2 Ti | SSD |
| Kafka 3.x | 消息队列 | 4-8 Core | 8-32 Gi | 500 Gi - 2 Ti | SSD(高吞吐用 NVMe) |
运维规范
- OpsRequest 变更(特别是大版本升级和缩容)先在预发环境验证。
- 配置变更使用 Configuration CRD,避免直接登录 Pod 修改参数(防止 Drift)。
- 备份恢复定期演练,确保 RPO 达标(日志归档的 PITR 链完整)。
- KubeBlocks Operator 和 Lorry 跟随社区 Release 定期升级,关注 CVE 修复。
- 数据库版本不跨多个 LTS 大版本直接升级(如 MySQL 5.7 → 8.0 需按升级路径操作)。
29 社区与生态
答案:
KubeBlocks 由 ApeCloud(北京猿力科技)发起并开源,托管于 GitHub,是 CNCF Landscape 收录项目。
项目概况
| 项目 | 说明 |
|---|---|
| 开源协议 | AGPL-3.0 |
| 代码仓库 | https://github.com/apecloud/kubeblocks |
| 文档 | https://kubeblocks.io/docs |
| 首发时间 | 2022 年 6 月 |
| 主要语言 | Go |
| 标星数 | 持续增长中(GitHub Stars > 2k) |
| CNCF | Landscape 收录(Application Definition & Image Build 类目) |
社区参与方式
| 渠道 | 说明 |
|---|---|
| GitHub Issues | 提交 Bug、Feature Request |
| GitHub Discussions | 技术讨论、使用问题 |
| Slack | 社区实时交流(#kubeblocks) |
| 社区双周会 | 社区例会(英文/中文),Roadmap 和设计讨论 |
Addon 生态
| 类别 | Addon |
|---|---|
| 关系型 | apecloud-mysql、oracle-mysql、postgresql、oceanbase、starrocks |
| 键值型 | redis |
| 文档型 | mongodb |
| 消息队列 | kafka、pulsar |
| 时序 | greptimedb |
| 分析 | clickhouse、doris |
| 图 | nebula |
KubeBlocks 在云原生数据库管理生态中的定位
Database Management on K8s
├── 通用框架:KubeBlocks (Operator Framework)
├── 专用 Operator
│ ├── PostgreSQL:CloudNativePG / Zalando / Crunchy Data
│ ├── MySQL:Vitess Operator / MySQL Operator (Oracle) / Percona Operator
│ ├── MongoDB:MongoDB Community Operator / Percona Operator for MongoDB
│ └── Redis:Redis Operator (OT-CONTAINER-KIT)
└── 平台集成
└── KubeDB (AppsCode)
Roadmap 方向(基于社区公开路线)
- 更多数据库引擎 Addon 支持。
- 增强分片管理能力(动态 Resharding)。
- 多集群联邦管理。
- GitOps 工作流集成(ArgoCD/Flux)。
- 安全增强(TLS 证书自动管理、Audit Log、RBAC 细粒度控制)。
30 CLI 工具(kbcli)常用命令
答案:
kbcli 是 KubeBlocks 的命令行管理工具,提供集群全生命周期管理、运维操作触发、Addon 管理、Playground 演示等功能。
安装
curl -fsSL https://kubeblocks.io/installer/install_cli.sh | bash
集群生命周期
# 创建集群
kbcli cluster create my-mysql \
--cluster-definition apecloud-mysql \
--topology replication \
--set mysql.replicas=3 \
--set mysql.storage=100Gi
# 列出集群
kbcli cluster list
# 查看集群详情
kbcli cluster describe my-mysql
# 查看集群组件
kbcli cluster list-components my-mysql
# 查看集群实例(Pod 级别)
kbcli cluster list-instances my-mysql
# 查看集群事件
kbcli cluster list-events my-mysql
# 删除集群
kbcli cluster delete my-mysql
运维操作(OpsRequest)
# 垂直扩容
kbcli cluster vscale my-pg --components pg=memory=8Gi,cpu=4
# 水平扩容
kbcli cluster hscale my-mysql --components mysql=5
# 存储扩容
kbcli cluster volume-expand my-mysql --components mysql=data=200Gi
# 重启
kbcli cluster restart my-mysql
# 停止 / 启动
kbcli cluster stop my-mysql
kbcli cluster start my-mysql
# 版本升级
kbcli cluster upgrade my-pg \
--cluster-version postgresql-15.4.0
# 配置变更
kbcli cluster configure my-mysql \
--component mysql \
--config-file my.cnf \
--set max_connections=500
备份恢复
# 查看备份策略
kbcli cluster list-backup-policy my-mysql
# 编辑备份策略
kbcli cluster edit-backup-policy my-mysql \
--cron "0 2 * * *" \
--retention 7
# 创建备份
kbcli cluster backup my-mysql --type full
# 查看备份
kbcli cluster list-backups my-mysql
# 恢复
kbcli cluster restore my-restored \
--backup-name my-mysql-backup-20250101
Addon 管理
kbcli addon list # 列出已安装 Addon
kbcli addon search mysql # 搜索可用 Addon
kbcli addon install apecloud-mysql # 安装
kbcli addon enable apecloud-mysql # 启用
kbcli addon disable apecloud-mysql # 禁用
kbcli addon uninstall apecloud-mysql # 卸载
Playground(本地体验)
# 使用 Kind 在本地快速启动 KubeBlocks + MySQL
kbcli playground init
集群连接
# 获取连接信息
kbcli cluster connect my-mysql --show-password
# 端口转发到本地
kbcli cluster connect my-mysql --port-forward
Dashboard
# 打开 Grafana Dashboard
kbcli cluster dashboard my-mysql
故障排查命令
kbcli cluster logs my-mysql # 查看集群日志
kbcli cluster describe-ops <ops-name> # 查看运维操作详情
kbcli cluster list-ops my-mysql # 列出集群运维操作历史
附录:术语对照表
| 术语 | 说明 |
|---|---|
| Addon | 数据库引擎插件包(Helm Chart) |
| ClusterDefinition | 数据库集群拓扑的 CRD 模板 |
| ComponentDefinition | 数据库组件定义 CRD |
| ComponentVersion | 数据库组件版本与镜像映射 |
| RSM | Replicated State Machine,有状态复制集工作负载 |
| Lorry | KubeBlocks 的 Sidecar 容器 |
| Day-2 Operations | 数据库上线后的运维操作(升级、扩容、备份、故障处理) |
| OpsRequest | 运维操作请求 CRD |
| PITR | Point-In-Time Recovery,时间点恢复 |
| Role Probe | 数据库角色检测探针 |
| VCT | VolumeClaimTemplate,存储卷声明模板 |
| Raft | 一致性共识算法,用于自动选主 |
| Patroni | PostgreSQL 高可用管理组件 |