重启策略
RestartPolicy
📌 概念释义与技术定位 (Definition & Overview)
RestartPolicy 是容器化数据库集群中定义容器生命周期终止后重启行为的核心配置项，用于决定故障容器是自动重启、手动重启还是停止运行。
RestartPolicy 是容器编排系统（如 Kubernetes）中用于控制容器生命周期管理的关键策略配置。在数据库与大数据领域，它决定了当数据库容器因崩溃、OOM（内存溢出）或网络中断等原因退出运行时，系统应采取的后续动作。该策略通常包含三种标准模式：Always（始终重启，适用于无状态服务或可自愈的数据库节点）、OnFailure（仅当容器因错误退出时重启，适用于需要人工干预的故障场景）和Never（永不重启，适用于需要手动介入或已知的临时性故障）。其本质是在保证服务高可用性与运维可控性之间寻求平衡。
在现代云原生数据库架构中，RestartPolicy 是构建高可用（HA）集群的基石之一。随着容器化技术的普及，数据库服务从物理机迁移至容器环境，其稳定性高度依赖于编排器的自愈能力。RestartPolicy 通过自动化机制，确保在节点故障、网络抖动或软件异常时，数据库服务能迅速恢复，从而满足金融级、实时分析等场景对 SLA（服务等级协议）的严苛要求。然而，盲目启用 Always 策略可能导致资源浪费或掩盖深层架构问题，因此合理的策略选择需结合业务容忍度、故障根因分析及资源成本进行综合考量。
⚙️ 核心架构与工作机制 (Technical Mechanism)
RestartPolicy 的底层机制依赖于容器编排器（如 K8s）的控制器循环与事件驱动模型。当容器状态变为 Terminated 时，调度器会读取 Pod 的 Spec 配置中的 restartPolicy 字段。若策略为 Always，控制器会立即触发容器重启流程，并重新分配资源；若为 OnFailure，则需检查退出码（Exit Code），仅当非零码（表示错误）时才触发重启，否则保持终止状态；Never 策略则直接忽略重启指令。在数据库场景下，该机制常与资源限制（Resource Limits）和监控探针（Liveness/Readiness Probes）协同工作：探针检测到健康状态异常时触发容器退出，RestartPolicy 随即接管重启流程，形成闭环自愈。此外，该策略还影响 Pod 的驱逐（Eviction）行为，例如在节点资源紧张时，Always 策略的 Pod 可能被优先驱逐并重启，而 Never 策略的 Pod 则会被保留。
📖 权威专著深度引证与原文精粹 (Expert Book Insights)
2 本专著引用《Kubernetes权威指南：从Docker到Kubernetes实践全接触》
龚正等
“表 3.2 Pod 的状态 Pod的重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅 在Pod所处的Node上由kubelet进行判断和重启操作。”
《Kubernetes权威指南及应用（共7册）》
郑东旭 杜军 等
“表3.2 Pod的状态 Pod的重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。”
🚀 典型应用场景 (Industrial Applications)
云原生 MySQL/PostgreSQL 集群的节点自愈
Spark/Flink 任务容器的故障恢复
Redis 缓存服务的无状态节点替换
Elasticsearch 分片节点的动态扩容与故障迁移
⚖️ 技术优势与工程权衡 (Trade-offs & Pros/Cons)
🟢 核心优势与技术特性
- + 实现服务的高可用性与自动化恢复，减少人工干预
- + 灵活适配不同业务场景的故障容忍度与运维需求
- + 与容器编排生态深度集成，简化集群管理复杂度
🔴 工程考量与潜在挑战
- - 无限重启可能导致资源耗尽或掩盖底层架构缺陷
- - 频繁重启可能引发网络风暴或数据库连接池抖动
- - 无法区分临时故障与永久性故障，需依赖探针辅助判断
