V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
yingha
V2EX  ›  Kubernetes

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

  •  
  •   yingha · 174 天前 · 2760 次点击
    这是一个创建于 174 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    21 条回复    2023-09-07 20:22:22 +08:00
    br9852000
        1
    br9852000  
       174 天前
    看你数据量吧,如果数据量大加载到内存这个时间就得几分钟。
    monlor
        2
    monlor  
       174 天前
    如果 master 那台节点出问题了呢,那你 redis 就一直起不起来了
    orange2023
        3
    orange2023  
       174 天前
    是的,K8S 可以支持 Node 的迁移,但是 storge 你也就需要使用相应的分布式存储。
    ttwxdly
        4
    ttwxdly  
       174 天前
    GTP-4 :
    您的理解在一定程度上是正确的。Kubernetes ( k8s )确实提供了自动恢复和调度功能,这可以帮助应对节点或 Pod 故障。然而,即使在 Kubernetes 环境中,Redis 哨兵仍然有其价值。

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

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

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

    总的来说,虽然 Kubernetes 提供了强大的自我修复和调度能力,但在某些场景下,使用 Redis 哨兵仍然是有必要的。
    ttwxdly
        5
    ttwxdly  
       174 天前
    @ttwxdly GPT-4
    Cola98
        6
    Cola98  
       174 天前
    还是需要的,K8S 只是一个调度系统
    orange2023
        7
    orange2023  
       174 天前
    我觉得它俩不是一个层面的。
    K8S 的重启恢复只是应用程序层面的,比如单服务挂了,自动重启下,但是重启过程中无法提供服务。
    Redis 的哨兵实现的是一个分布式系统,集群里超过半数节点存活,整个系统还能提供服务。
    xomix
        8
    xomix  
       174 天前   ❤️ 1
    >在物理机上部署 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
        9
    xomix  
       174 天前
    回复格式我折腾了半天,凑合着看吧
    leogm9408leo
        10
    leogm9408leo  
       174 天前
    虽然但是,可能我对 k8s 的理解肤浅了,但是有状态的服务,例如 redis 或者 db ,是不是不适合放在 k8s 中
    kd9yYw2RyhQwAwzn
        11
    kd9yYw2RyhQwAwzn  
       174 天前
    可以试试 operator 的模式部署 redis 当 redis pod 发生异常时 由 operator 负责维护整个集群的工作状态
    github 上 starts 数量多的 redis operator 都尝试了 综合下来 https://github.com/ucloud/redis-cluster-operator 这个的使用体验最好
    手动删除 pod 后 redis 集群的状态没有出现过问题 扩充/缩减节点后还会自动进行 reshard ,备份功能可以配合一个 cronjob 进行处理
    redis >= 7.0 的话 需要修改下源码 不然部署会报错
    george2077
        13
    george2077  
       174 天前
    Claude-2-100k:

    你的理解基本正确。

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

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

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

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

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

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

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

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

    所以在 Kubernetes 中使用 Redis 仍然推荐结合哨兵来部署,以提高服务可靠性。但实现方式会有所不同,可以通过 Kubernetes 的 Operator 来统一管控哨兵和 Redis 的部署
    joesonw
        14
    joesonw  
       174 天前 via iPhone
    @monlor 又没 taint ,分到其他 node 呀。
    vhwwls
        15
    vhwwls  
       174 天前
    @xomix #8

    “ 如>果 master 挂了会被 k8s 检测到,会重启新的 pod ,可以说 k8s 中永远不会有 pod 挂掉,就算 node 挂了,pod 也会 >驱散到其他 node ”
    这个说法是错误的,默认情况下,k8s 检测到 node notready 十分钟之后才会启动 Pod 疏散的过程,并且在这个过程中,如果 node 上的 Pod 所关联的存储因为各种原因(例如,锁没有被及时释放)没办法被新的 node 重新绑定的情况下,这个 pod 会一直处于 Terminating 状态,新的 Pod 会卡在 ContainerCreating 状态,所以,所谓“永远不会有 pod 挂掉”的这个说法是错误的。
    winglight2016
        16
    winglight2016  
       174 天前
    我们这里 etcd 的集群也有同样问题,结论是 statefulset 就能解决
    julyclyde
        17
    julyclyde  
       174 天前
    会重启新的 和 永远不会有 pod 挂掉
    是同一个意思么?
    Cola98
        18
    Cola98  
       174 天前
    @Cola98 纠正一下之前说的,当你的 master pod 如果挂了,K8S 不一定会重启成功,可能会出现 CrashLoopBackOff 这种错误,所以需要再去部署 slave pod 来完成新一轮的选举,选出 master 来解决 CrashLoopBackOff 问题,之后 pod 恢复正常。为上午的回答道歉 orz
    xomix
        19
    xomix  
       174 天前
    @vhwwls 耐心看完我乱七八糟的排版真的感谢你。这个情况我确实忽略了。
    总之重启一个 pod 可不是 pod 永远不会挂掉。这种事在你分布式程序出问题的时候整个集群一个也无法启动,整个流水线发布大面积失效的时候是最明显的。
    luomu24
        20
    luomu24  
       174 天前
    @ttwxdly GPT4 这个讲得感觉很可以啊。
    Achilless
        21
    Achilless  
       174 天前
    数据库之类的基础设施感觉不要放 k8s 比较好。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1112 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 23:07 · PVG 07:07 · LAX 15:07 · JFK 18:07
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.