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

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

  •  
  •   yingha · 2023-09-07 09:13:21 +08:00 · 3270 次点击
    这是一个创建于 457 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    总的来说,虽然 Kubernetes 提供了强大的自我修复和调度能力,但在某些场景下,使用 Redis 哨兵仍然是有必要的。
    ttwxdly
        5
    ttwxdly  
       2023-09-07 09:41:04 +08:00
    @ttwxdly GPT-4
    Cola98
        6
    Cola98  
       2023-09-07 09:44:28 +08:00
    还是需要的,K8S 只是一个调度系统
    orange2023
        7
    orange2023  
       2023-09-07 09:52:38 +08:00
    我觉得它俩不是一个层面的。
    K8S 的重启恢复只是应用程序层面的,比如单服务挂了,自动重启下,但是重启过程中无法提供服务。
    Redis 的哨兵实现的是一个分布式系统,集群里超过半数节点存活,整个系统还能提供服务。
    xomix
        8
    xomix  
       2023-09-07 10:07:24 +08:00   ❤️ 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  
       2023-09-07 10:08:41 +08:00
    回复格式我折腾了半天,凑合着看吧
    leogm9408leo
        10
    leogm9408leo  
       2023-09-07 10:22:40 +08:00
    虽然但是,可能我对 k8s 的理解肤浅了,但是有状态的服务,例如 redis 或者 db ,是不是不适合放在 k8s 中
    kd9yYw2RyhQwAwzn
        11
    kd9yYw2RyhQwAwzn  
       2023-09-07 10:57:02 +08:00
    可以试试 operator 的模式部署 redis 当 redis pod 发生异常时 由 operator 负责维护整个集群的工作状态
    github 上 starts 数量多的 redis operator 都尝试了 综合下来 https://github.com/ucloud/redis-cluster-operator 这个的使用体验最好
    手动删除 pod 后 redis 集群的状态没有出现过问题 扩充/缩减节点后还会自动进行 reshard ,备份功能可以配合一个 cronjob 进行处理
    redis >= 7.0 的话 需要修改下源码 不然部署会报错
    kd9yYw2RyhQwAwzn
        12
    kd9yYw2RyhQwAwzn  
       2023-09-07 10:59:49 +08:00
    george2077
        13
    george2077  
       2023-09-07 11:39:18 +08:00
    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  
       2023-09-07 11:52:19 +08:00 via iPhone
    @monlor 又没 taint ,分到其他 node 呀。
    vhwwls
        15
    vhwwls  
       2023-09-07 11:57:43 +08:00
    @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  
       2023-09-07 11:58:54 +08:00
    我们这里 etcd 的集群也有同样问题,结论是 statefulset 就能解决
    julyclyde
        17
    julyclyde  
       2023-09-07 13:39:49 +08:00
    会重启新的 和 永远不会有 pod 挂掉
    是同一个意思么?
    Cola98
        18
    Cola98  
       2023-09-07 15:50:42 +08:00
    @Cola98 纠正一下之前说的,当你的 master pod 如果挂了,K8S 不一定会重启成功,可能会出现 CrashLoopBackOff 这种错误,所以需要再去部署 slave pod 来完成新一轮的选举,选出 master 来解决 CrashLoopBackOff 问题,之后 pod 恢复正常。为上午的回答道歉 orz
    xomix
        19
    xomix  
       2023-09-07 16:41:04 +08:00
    @vhwwls 耐心看完我乱七八糟的排版真的感谢你。这个情况我确实忽略了。
    总之重启一个 pod 可不是 pod 永远不会挂掉。这种事在你分布式程序出问题的时候整个集群一个也无法启动,整个流水线发布大面积失效的时候是最明显的。
    luomu24
        20
    luomu24  
       2023-09-07 19:36:04 +08:00
    @ttwxdly GPT4 这个讲得感觉很可以啊。
    Achilless
        21
    Achilless  
       2023-09-07 20:22:22 +08:00
    数据库之类的基础设施感觉不要放 k8s 比较好。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2859 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 09:33 · PVG 17:33 · LAX 01:33 · JFK 04:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.