Kubernetes 上的 Redis：K8s 的自愈能力能否替代哨兵（Sentinel）？

当我们将应用迁移到 Kubernetes (K8s) 的怀抱时，常常会为其强大的自愈和故障恢复能力感到惊叹。K8s 能够自动重启崩溃的容器、迁移宕机节点上的应用，这似乎为我们解决了所有关于“高可用”的烦恼。于是，一个自然而然的问题浮现在许多开发者脑海中：

“既然 K8s 如此强大，我还需要像以前在物理机上那样，为我的 Redis 部署一套复杂的哨兵（Sentinel）集群吗？”

这是一个极佳的问题，它触及了云原生时代应用高可用性设计的核心。简短的答案是：是的，你绝对仍然需要！ K8s 的高可用和 Redis Sentinel 的高可用是两个不同层面的能力，它们非但不能互相替代，反而是构建真正健壮服务的完美搭档。

---

理解两个层面的高可用

要弄清这个问题，我们必须先解构 K8s 和 Redis Sentinel 各自的职责。

Kubernetes 的职责：基础设施层的高可用

K8s 是一个容器编排平台，它关注的是“容器”和“节点”的健康，提供的是基础设施层面的保障。其核心能力包括：

• Pod 存活探测与重启：通过 livenessProbe，K8s 可以检测到 Redis 进程是否僵死或崩溃。如果探测失败，K8s 会果断地杀死这个 Pod 并尝试重新创建一个，实现“进程级”的自愈。
• 节点故障迁移：如果一个 K8s Node (物理机或虚拟机) 宕机，K8s 的控制器会检测到这一情况，并将该 Node 上的所有 Pod 调度到其他健康的 Node 上重新创建。
• 服务发现与负载均衡：通过 Service 对象，K8s 为一组功能相同的 Pods 提供一个稳定的虚拟 IP (ClusterIP) 和 DNS 名称。客户端只需访问这个 Service，K8s 就会将请求路由到后端某个健康的 Pod。

K8s 的核心视角是“应用无关性” (Application-Agnostic)。 它不知道一个 Redis Pod 是 Master 还是 Slave。在 K8s 眼里，它们都只是待运行的容器。

Redis Sentinel 的职责：应用层的高可用

与 K8s 不同，Redis Sentinel 是为 Redis 这一特定应用量身定制的。它深入理解 Redis 的主从复制架构，提供的是“应用感知型” (Application-Aware) 的高可用。其核心职责是：

• Master 状态的精准监控：Sentinel 专门监控 Redis Master 节点是否“真正可用”。这种监控比 K8s 的 livenessProbe 更智能，它能判断 Master 是否因为网络分区或负载过高而假死。
• 自动故障转移 (Automatic Failover)：这是 Sentinel 的王牌功能。当 Sentinel 集群确认 Master 宕机后，它会：
  1. 在所有 Sentinel 节点中进行投票选举。
  2. 从现有的 Slave 节点中选举出一个新的 Master。
  3. 命令新的 Master 升级，并命令所有其他 Slave 切换复制目标到新 Master。
• 配置提供者：Sentinel 还会对外提供当前 Redis Master 的准确地址。客户端可以向 Sentinel 查询谁是主节点，从而保证总能连接到正确的、可写的实例。

---

场景分析：为何只靠 K8s 不够？

让我们通过一个场景来直观地感受一下缺少 Sentinel 的后果。假设我们仅使用 K8s 的 StatefulSet 部署了一个 Redis Master 和两个 Slaves。

场景：Redis Master 所在的 Node 突然宕机。

1. K8s 的反应（分钟级）：

   • K8s 的 kube-controller-manager 需要一段时间（默认约5分钟）才能将该 Node 标记为 NotReady 或 Down。
   • 然后，它开始在另一个健康的 Node 上重新调度 Master Pod。
   • 如果使用了持久化存储 (PV/PVC)，还需要花时间完成存储卷的 detach 和 attach 操作。
   • 最终，新的 Master Pod 启动并恢复服务。

2. 期间的问题：

   • 漫长的服务中断：从 Node 宕机到 Master Pod 在新节点上完全恢复，整个过程可能耗时 5到10分钟甚至更长。在这段时间里，所有写操作都会失败。
   • 集群处于“只读脑裂”状态：在 Master 恢复之前，两个 Slave 节点仍然是只读的。它们无法自动晋升，整个 Redis 集群无法接受写入，服务处于严重降级状态。

对于绝大多数业务而言，长达数分钟的写服务中断是不可接受的。

---

完美搭档：K8s + Sentinel 的协同工作

现在，我们把 Sentinel 加回来，看看同样的场景会发生什么。

场景：Redis Master 所在的 Node 突然宕机。

1. Sentinel 的反应（秒级）：

   • Sentinel 集群通过高频心跳，在极短时间内（例如 30 秒，可配置）就判定 Master 失联。
   • Sentinel 们迅速完成投票，选举出新的 Master，并通知所有 Slave 切换主节点。
   • 整个故障转移过程通常在 30-60 秒内完成。你的应用的写服务中断时间从“分钟级”缩短到了“秒级”。

2. K8s 的反应（在后台默默进行）：

   • 与此同时，K8s 也在按部就班地做着它的工作。它最终会在一个新 Node 上重新创建那个“旧 Master”的 Pod。
   • 当这个旧 Master Pod 启动后，它会尝试重新加入集群。此时，Sentinel 会发现它，并智能地向它发送命令，强制其降级为当前新 Master 的一个 Slave。

结论显而易见：

通过 K8s 和 Sentinel 的结合，我们获得了一个两全其美的解决方案：

• Sentinel 提供了秒级的快速故障转移，保障了业务的连续性。
• K8s 提供了基础设施的自动修复，确保了集群实例数量的完整性，并将被 Sentinel 降级的旧 Master 自动以正确的角色（Slave）重新带回集群。

---

最佳实践：如何在 K8s 上部署高可用 Redis

1. 首选方案：使用 Redis Operator

   • 在 Kubernetes 生态中，Operator 是管理有状态应用的最佳模式。它将人类运维专家的知识代码化，变成一个自动化的控制器。
   • 使用如 Redis Enterprise Operator 或各种优秀的开源 Operator，你只需一个简单的 YAML 文件，就能声明式地部署一个包含 Redis、Sentinel、服务发现和故障转移逻辑的完整高可用集群。升级、扩容、备份等复杂操作也变得异常简单。

2. 手动部署方案：StatefulSet + Deployment

   • 如果你想深入理解其原理，可以手动部署：
     • 使用 StatefulSet 部署 Redis 节点，以获得稳定的网络标识和持久化存储。
     • 使用 Deployment 部署 Sentinel 节点（通常是3个或5个实例）。
     • 创建合适的 Service 来暴露 Redis Master 和 Sentinel 服务。

总结

不要将 Kubernetes 的容器编排能力与应用自身的 HA 机制混为一谈。 K8s 为 Redis 提供了坚实的运行基础和强大的容错兜底，而 Redis Sentinel (或 Redis Cluster) 则提供了应用层面的智能和快速响应。两者相辅相成，共同铸就了在云原生环境下的高可用 Redis 服务。

下次当你准备在 K8s 上部署 Redis 时，请毫不犹豫地拥抱 Sentinel 或 Redis Cluster 吧，它们依然是保障你数据服务高可用的中坚力量。