# 1. 数据库 Operator 的备份/恢复/故障转移自动化 A Operator 通过 reconcile 循环持续将集群实际状态收敛到声明的期望状态，从而自动化备份、恢复与故障转移 ✓ 正确答案 B Operator 依赖人工在故障时手动编辑 Pod 规格来触发切换 C Operator 只能做备份，不能做恢复与故障转移 D Operator 的故障转移需要重启整个 Kubernetes 集群
# 2. Operator 管理集群拓扑（主从/分片）的声明式 A 每次扩缩容都需要人工逐一对每个 Pod 执行命令 B 声明式拓扑与 Kubernetes 无关，只是文档约定 C 用户修改 spec 中的实例数/分片数，Operator 自动幂等地收敛拓扑并维护角色 ✓ 正确答案 D Operator 会强制所有实例都是主库
# 3. 数据库 Operator 的自定义备份策略与保留 A Operator 会结合保留策略与 WAL/增量依赖，安全清理过期备份并保留恢复链所需的集合 ✓ 正确答案 B 保留策略只负责删除过期的全量备份，不管 WAL C 保留策略一旦设置就永远无法修改 D 备份保留与 PITR 能力无关
# 4. Operator 的 CRD 与 Controller 调谐（reconcile）循环 A reconcile 只执行一次，出错了就停止 B CRD 的 spec 是只读的，无法被修改 C reconcile 由用户手动触发，不会自动运行 D reconcile 持续对比 spec 与实际状态，通过幂等操作收敛差异，并把结果写入 status ✓ 正确答案
# 5. 云原生数据库的 StatefulSet 与稳定网络标识 A StatefulSet 的 Pod 名随机，无法用于数据库 B StatefulSet 只能用于无状态应用 C StatefulSet 提供稳定 Pod 名、绑定 PVC 与 Headless Service 稳定 DNS，满足数据库有状态与主从识别的需求 ✓ 正确答案 D 稳定网络标识只对存储有意义，与主从复制无关
# 6. 开源 Operator（Zalando Postgres/CNPG）能力对比 A Zalando 依赖 etcd 做 leader 选举，CNPG 更贴近原生声明式与快照备份，选型需结合运维经验与云原生需求 ✓ 正确答案 B 两者都完全不支持备份与恢复 C CNPG 不支持 PITR 恢复 D 两者完全相同，无任何区别
# 7. Operator 的升级与版本兼容（k8s 版本） A 升级前需核对 Operator 与 Kubernetes/数据库版本兼容矩阵，并注意 CRD schema 兼容，通常先升级控制器再升级集群 ✓ 正确答案 B 升级 Operator 可以随意跳过兼容性检查 C 升级一定会中断所有数据库集群 D Operator 升级与 Kubernetes 版本完全无关
# 8. Operator 与 Helm Chart 部署的差异 A Helm 与 Operator 完全等价，没有区别 B Helm 擅长模板化一次性部署与升级，Operator 是常驻控制器支持持续自愈，实践中常以 Helm 安装 Operator、Operator 管理数据库 ✓ 正确答案 C Operator 只能做一次性部署，不能持续自愈 D Helm 具备数据库集群的故障转移能力
# 9. 数据库对有状态存储（PV/PVC/StorageClass）的要求 A 数据库可以使用任何存储，性能无关紧要 B PV 与 Pod 生命周期绑定，Pod 删除数据就丢失 C 数据库 Pod 必须共享同一个 PV D 数据库需要持久、高性能、可扩展的存储，通常用 ReadWriteOnce 的独立 PVC 与匹配的 StorageClass ✓ 正确答案
# 10. 本地盘（Local PV）与网络存储（云盘）的 IO 差异 A 本地盘延迟低、吞吐高，但受节点绑定与数据丢失风险限制；云盘持久性高、可扩展，但有网络延迟 ✓ 正确答案 B 云盘延迟一定低于本地盘 C 本地盘数据不会因节点故障丢失 D 网络存储无法支持持久化
# 11. 数据库 Pod 的 IO 隔离与限速（IO Throttle） A 可通过容器资源请求、cgroup blkio 限速与 CSI 存储 QoS 等保证数据库 IO 的确定性，防止吵闹邻居影响 ✓ 正确答案 B 只需要设置 CPU 超卖即可保证 IO 稳定 C IO 限速会导致数据库一定崩溃 D Kubernetes 无法对 IO 做任何限制
# 12. K8s 网络策略（NetworkPolicy）对数据库访问控制 A NetworkPolicy 只能限制出站流量，不能限制入站 B 创建 NetworkPolicy 后所有流量都放行 C NetworkPolicy 对数据库完全无效 D 默认拒绝 + 显式允许的规则可只放行带特定标签的应用访问数据库端口，缩小攻击面 ✓ 正确答案
# 13. 数据库 Service（Headless/ClusterIP）与发现 A Headless Service 也分配虚拟 IP 做负载均衡 B ClusterIP 提供稳定入口与负载均衡，Headless 提供各 Pod 稳定 DNS 身份便于节点间发现，数据库常两者并用 ✓ 正确答案 C Headless Service 无法用于数据库 D ClusterIP Service 的 DNS 不解析，只能通过 IP 访问
# 14. 节点亲和（Affinity）与反亲和避免同 AZ 共置 A 反亲和用于把 Pod 强制放在同一节点 B 用 podAntiAffinity 配合 topologyKey=zone 让数据库副本分散到不同可用区，结合 nodeAffinity 定向到合适节点，实现区域级高可用 ✓ 正确答案 C 亲和与反亲和与高可用无关 D required 反亲和是软性约束，可被忽略
# 15. Pod 拓扑分布约束（Topology Spread） A 它只用于无状态应用，不适用于数据库 B maxSkew 必须为 0 才能生效 C 它与反亲和完全相同 D 它让一组 Pod 在指定拓扑域（节点/AZ）上尽量均衡分布，可用 maxSkew 控制不均衡程度 ✓ 正确答案
# 16. 数据库 Pod 故障的探测（Liveness/Readiness） A Liveness 失败不会影响容器 B 探针越激进越好，频繁重启不影响数据库 C Readiness 负责摘除不可用 Pod 的流量，Liveness 决定是否重启容器；数据库应使用轻量探测并放宽 Liveness 阈值避免误杀 ✓ 正确答案 D Readiness 探针失败会立刻重启容器
# 17. Pod 驱逐（Eviction）与数据库优雅关闭 A 驱逐时直接 SIGKILL，数据库无需处理 B MariaDB 被驱逐时可以忽略 SIGTERM C 优雅关闭只对无状态应用有意义 D 通过 preStop 钩子、SIGTERM 处理与 terminationGracePeriod 让数据库 flush/checkpoint 后干净退出，主库被驱逐时先触发 failover 接走 ✓ 正确答案
# 18. Operator 驱动的自动化 failover 与脑裂防护 A 只要从库就绪就立即提升为新主，无需考虑旧主 B failover 无需更新 Service 端点 C 脑裂不会导致数据损坏 D 通过仲裁/共识选举唯一 leader，并在提升新主前对旧主做 fencing（隔离/降级）防止双写，从而避免脑裂 ✓ 正确答案
# 19. 数据库在 k8s 的 RPO/RTO 实践 A RPO/RTO 由复制模式与备份/恢复策略共同决定，需按业务分级并用演练实测 RTO 来持续优化 ✓ 正确答案 B RPO 由备份频率决定，RTO 由复制方式决定，两者独立 C RPO 越小越好，无需考虑成本 D 在 k8s 上无法控制 RPO/RTO
# 20. 数据库与 etcd 的选址（避免同故障域） A 应把 etcd 与数据库放在同一节点以加快访问 B 应让 etcd 与数据库处于不同故障域并各自跨可用区冗余，避免单故障域同时摧毁控制面与数据 ✓ 正确答案 C etcd 与数据库可以共用同一块存储 D 故障域隔离与高可用无关
# 21. 数据库在 k8s 的延迟敏感型调度 A 只有 CPU 超卖配置无关紧要 B 用 Guaranteed QoS、专用节点、CPU 亲和与反亲和隔离干扰，保证数据库资源与延迟的确定性 ✓ 正确答案 C 数据库应尽量与高负载任务共享节点以省资源 D 延迟敏感与调度无关
# 22. k8s 上数据库的主备切换与端点不变 A 通过 Service 的稳定地址 + 更新 selector/Endpoints，客户端无需改动即可自动连到新主 ✓ 正确答案 B 主备切换后客户端必须修改连接地址 C 端点一定随主备切换而变化 D 只有主库 Service 需要，从库 Service 不需要
# 23. 跨可用区部署与 Pod 反亲和的高可用 A 用 podAntiAffinity 的 topologyKey=zone 让主从副本分散到不同 AZ，单 AZ 故障时其他 AZ 副本接管，实现区域级高可用 ✓ 正确答案 B 只需把副本放在同一节点即可体现高可用 C 跨 AZ 部署会增加单点风险 D 反亲和不能跨节点生效
# 24. k8s 升级对数据库可用性的影响 A 节点升级会驱逐数据库 Pod，需通过 PDB、有序排空、优雅关闭与故障转移降低影响，在维护窗口滚动升级 ✓ 正确答案 B k8s 升级对数据库完全没有影响 C 升级一定会导致数据库数据丢失 D 升级无需任何策略
