k8s 中部署 redis 主备还需要哨兵吗？

[yingha]

在物理机上部署 1 主 2 从的时候，为了高可用，防止 master 挂了，需要部署哨兵选举新的 master ；但是 k8s 中，如果 master 挂了会被 k8s 检测到，会重启新的 pod ，可以说 k8s 中永远不会有 pod 挂掉，就算 node 挂了，pod 也会驱散到其他 node 。

可能有人会说 pod 挂掉的时候到重新启动，这时候是无法访问的。可是就算有了哨兵，哨兵在感知到 master 挂掉以及选取新的 master 也是需要时间的，这段时间也是无法提供服务的。这样看来哨兵的作用似乎可有可无了，不知道我的理解对不对？

[br9852000]

看你数据量吧，如果数据量大加载到内存这个时间就得几分钟。

[monlor]

如果 master 那台节点出问题了呢，那你 redis 就一直起不起来了

[orange2023]

是的，K8S 可以支持 Node 的迁移，但是 storge 你也就需要使用相应的分布式存储。

[ttwxdly]

GTP-4 :
您的理解在一定程度上是正确的。Kubernetes （ k8s ）确实提供了自动恢复和调度功能，这可以帮助应对节点或 Pod 故障。然而，即使在 Kubernetes 环境中，Redis 哨兵仍然有其价值。

首先，虽然 Kubernetes 能够检测到 Pod 失败并重新启动它，但这个过程需要一些时间。在此期间，如果你的应用程序尝试连接到已经失败的主节点，那么将会遇到问题。使用哨兵可以更快地感知到主节点的失效，并立即开始选举新的主节点，从而减少服务中断的时间。

其次，Kubernetes 的健康检查机制可能无法完全替代 Redis 哨兵的角色。例如，一个 Redis 主节点可能由于内部错误而停止接受写入，但仍然保持运行状态，这种情况下 Kubernetes 可能无法检测到问题，而哨兵则可以。

最后，哨兵还提供了其他一些高级特性，如配置管理、通知等，这些都是 Kubernetes 本身不具备的。

总的来说，虽然 Kubernetes 提供了强大的自我修复和调度能力，但在某些场景下，使用 Redis 哨兵仍然是有必要的。

[ttwxdly]

@ttwxdly GPT-4

[Cola98]

还是需要的，K8S 只是一个调度系统

[orange2023]

我觉得它俩不是一个层面的。
K8S 的重启恢复只是应用程序层面的，比如单服务挂了，自动重启下，但是重启过程中无法提供服务。
Redis 的哨兵实现的是一个分布式系统，集群里超过半数节点存活，整个系统还能提供服务。

[xomix]

>在物理机上部署 1 主 2 从的时候，为了高可用，防止 master 挂了，需要部署哨兵选举新的 master ；但是 k8s 中，如>果 master 挂了会被 k8s 检测到，会重启新的 pod ，可以说 k8s 中永远不会有 pod 挂掉，就算 node 挂了，pod 也会 >驱散到其他 node 。
是的，你说的没错。
>可能有人会说 pod 挂掉的时候到重新启动，这时候是无法访问的。可是就算有了哨兵，哨兵在感知到 master 挂掉以及>选取新的 master 也是需要时间的，这段时间也是无法提供服务的。这样看来哨兵的作用似乎可有可无了，不知道我的>理解对不对？
这里就不对了，k8s 的 pod 重启是从头来一个 pod 加入集群，尝试按照 master 的方式从集群其他地方恢复数据，哨兵做的是发现 master 无响应，在集群中重新选择一个 node 来启动 master 服务，你看出区别了吗？这里一个是有数据，一个是无数据，一个是声明自己做 master ，一个是重新启动一个 master 。数据量不大的时候区别很小甚至重启 pod 的方式更快，数据量越大你就越发现重选 master 的时间是固定的同步数据的时间可不是。

[xomix]

回复格式我折腾了半天，凑合着看吧

[leogm9408leo]

虽然但是，可能我对 k8s 的理解肤浅了，但是有状态的服务，例如 redis 或者 db ，是不是不适合放在 k8s 中

[kd9yYw2RyhQwAwzn]

可以试试 operator 的模式部署 redis 当 redis pod 发生异常时 由 operator 负责维护整个集群的工作状态
github 上 starts 数量多的 redis operator 都尝试了 综合下来 https://github.com/ucloud/redis-cluster-operator 这个的使用体验最好
手动删除 pod 后 redis 集群的状态没有出现过问题 扩充/缩减节点后还会自动进行 reshard ，备份功能可以配合一个 cronjob 进行处理
redis >= 7.0 的话 需要修改下源码 不然部署会报错

[kd9yYw2RyhQwAwzn]

cluster 模式 https://github.com/ucloud/redis-cluster-operator
哨兵模式 https://github.com/ucloud/redis-operator

[george2077]

Claude-2-100k：

你的理解基本正确。

在 Kubernetes 中,使用 Deployment 或者 StatefulSet 来部署 Redis,可以实现自动重启、滚动更新等功能。当 Pod 出现问题时,Kubernetes 会重新调度 Pod,从而保证服务的高可用性。

所以从这个角度来看,Kubernetes 已经提供了高可用性的基础保障,不再像物理机上需要额外的哨兵来实现主备切换。

但是,我们还是会在 Kubernetes 中部署哨兵的主要原因如下:

哨兵可以实时监控主节点是否出现问题,主观下线和客观下线的快速切换可以提高可用性。而 Kubernetes 的健康检查和重启需要一定时间,故障转移会相对缓慢。

哨兵集群之间通过投票避免脑裂问题。而 Kubernetes 中如果主节点和从节点同时 callable,集群中可能会出现双主的情况。

通过哨兵可以实现读写分离,提高 Redis 性能。

哨兵支持更多的高可用配置,例如故障迁移、定向故障转移等。

将哨兵和 Kubernetes 结合,可以发挥两者的优势,既有哨兵的高可用,也有 Kubernetes 的便捷管理。

所以在 Kubernetes 中使用 Redis 仍然推荐结合哨兵来部署,以提高服务可靠性。但实现方式会有所不同,可以通过 Kubernetes 的 Operator 来统一管控哨兵和 Redis 的部署

[joesonw]

@monlor 又没 taint ，分到其他 node 呀。

[vhwwls]

@xomix #8

“ 如>果 master 挂了会被 k8s 检测到，会重启新的 pod ，可以说 k8s 中永远不会有 pod 挂掉，就算 node 挂了，pod 也会 >驱散到其他 node ”
这个说法是错误的，默认情况下，k8s 检测到 node notready 十分钟之后才会启动 Pod 疏散的过程，并且在这个过程中，如果 node 上的 Pod 所关联的存储因为各种原因（例如，锁没有被及时释放）没办法被新的 node 重新绑定的情况下，这个 pod 会一直处于 Terminating 状态，新的 Pod 会卡在 ContainerCreating 状态，所以，所谓“永远不会有 pod 挂掉”的这个说法是错误的。

[winglight2016]

我们这里 etcd 的集群也有同样问题，结论是 statefulset 就能解决

[julyclyde]

会重启新的 和 永远不会有 pod 挂掉
是同一个意思么？

[Cola98]

@Cola98 纠正一下之前说的，当你的 master pod 如果挂了，K8S 不一定会重启成功，可能会出现 CrashLoopBackOff 这种错误，所以需要再去部署 slave pod 来完成新一轮的选举，选出 master 来解决 CrashLoopBackOff 问题，之后 pod 恢复正常。为上午的回答道歉 orz

[xomix]

@vhwwls 耐心看完我乱七八糟的排版真的感谢你。这个情况我确实忽略了。
总之重启一个 pod 可不是 pod 永远不会挂掉。这种事在你分布式程序出问题的时候整个集群一个也无法启动，整个流水线发布大面积失效的时候是最明显的。

[luomu24]

@ttwxdly GPT4 这个讲得感觉很可以啊。