1. 先搞清楚云原生环境下为什么还需要keepalived1.1 高可用不是口号是事故后的救命稻草做运维和基础架构的朋友应该都有过这种经历凌晨三点被报警电话叫醒数据库主库挂了前端流量全打在一个不可用的IP上业务直接熔断。这种时候你脑子里想的不是为什么挂了而是怎么让流量赶紧走别的路。高可用集群要解决的本质问题就一句话当某一台机器挂掉时服务入口不能被切断。用户访问的是个IP或者域名这个入口背后可以有很多台机器但对外始终只有一个门牌号。这台机器挂了门牌号要自动挂到另一台活着的机器上整个过程用户无感知业务不中断。在云原生的大背景下很多人会觉得Kubernetes已经有原生的健康检查、Pod重启、多副本调度是不是就不需要keepalived了我个人的答案是需要而且场景比传统物理机时代更复杂。K8s解决的是容器和Pod级别的高可用但Pod跑在哪台Node上、Node之间的负载均衡入口怎么保持稳定、对外暴露服务的VIP怎么不丢这些依然是基础设施层面的问题。尤其是自建K8s集群、混合云架构、物理机虚拟机的过渡阶段keepalived依然是那个便宜、稳定、可靠的入口保障方案。1.2 keepalived在技术栈里的真实定位keepalived这个软件很多人只知道它和虚拟IP绑定在一起实际上它是基于VRRP协议实现的三层高可用方案。它做的事情很纯粹一组机器里选出一个老大持有VIP老大挂了老二自动顶上来。选主效率极高秒级切换配置简单不依赖额外的存储和中间件。有人会问现在云平台不是都提供SLB、VIP、浮动IP这些产品吗确实公有云上可以直接买负载均衡产品但现实是很多企业是自建机房、私有云、混合云或者出于成本和合规考虑不能把所有入口都托管给云厂商。即便在云上K8s集群的API Server高可用、自建Ingress Controller的高可用、数据库中间件的高可用都需要keepalived这类工具在底层兜底。说白了keepalived像是你家里总电闸前面的那个漏电保护器——平时你感觉不到它存在但真出问题的时候它是第一个跳出来保护全屋电路的。这篇文章我会从VRRP原理开始把keepalived的主备切换机制讲透然后给出完整的双机热备配置实战再聊聊云原生场景下的适配经验和坑最后整理一份排查速查表。不管你是刚接触高可用的小白还是被线上VIP抖动折磨过的老手都能找到能直接用的东西。2. keepalived核心原理VRRP、VIP和选主逻辑2.1 VRRP协议到底在做什么VRRP全称是Virtual Router Redundancy Protocol虚拟路由冗余协议。它最初是IETF为解决局域网内单网关故障而设计的标准后来被keepalived等开源项目发扬光大用在服务器层面的IP漂移上。用一个生活化的例子理解VRRP想象一个小区只有一个快递驿站驿站老板每天负责收发整个小区的快递这就是网关。驿站关门了整个小区快递就瘫痪了。VRRP做的事情是在旁边再准备一个备用驿站新驿站和老板约定好老板每天用对讲机喊一嗓子我还活着。哪天对讲机里没动静了备用驿站立刻把招牌挂上接手所有快递业务。在技术层面VRRP的工作机制是这样的一组服务器组成一个VRRP组组里有一个Master主节点和多个Backup备节点。每个VRRP组有一个虚拟IP这个IP不是绑定在物理网卡上的而是作为虚拟路由器的地址。Master节点会周期性发送VRRP报文组播地址224.0.0.18告诉所有Backup我活着。报文里包含优先级priority、VRRP组ID等关键信息。Backup节点如果在master_down_delay时间内没收到报文就认为自己应该接管开始竞选Master。这里有几个关键参数直接决定了故障切换的速度和行为后面配置部分我会详细展开。2.2 VIP漂移的完整过程VIP漂移听起来很玄实际拆开看就是三步第一步Master发现自己的健康检查脚本失败或者主动降级priority降低它会发送一个低优先级的VRRP报文主动让位。第二步Backup收到报文后发现对方的优先级比自己低同时自己这边一定时间内没有收到更高优先级的Master通告于是触发状态切换从Backup变成Master。第三步新的Master在自己的网卡上配置VIP并发送免费ARPGratuitous ARP通告整个二层网络这个IP的MAC地址现在是我了。交换机、路由器、防火墙会更新自己的ARP缓存表后续访问VIP的流量就被引导到新的节点上。整个过程通常在2到5秒内完成。为什么不是毫秒级因为VRRP有master_down_delay的定时器默认会等待3秒左右避免因为网络抖动导致频繁切换。这个时间是可以调优的但调太短会引入脑裂风险后面专门讲。2.3 keepalived的三大核心模块keepalived在代码层面主要由三个模块协作VRRP Stack负责VRRP协议报文的收发、状态机切换、VIP的配置与删除。这是keepalived的核心所有选主逻辑都在这里。Checkers负责健康检查。可以检查后端服务的端口存活、HTTP状态码、脚本执行结果等一旦发现服务异常就通知VRRP模块降低优先级或者直接自杀让位。Netlink/Interface Manager负责与内核交互配置和清理IP地址、路由规则。很多人在配置keepalived时只配置了VRRP实例没有配置健康检查脚本这是一个很大的误区。假如主节点本身还活着网络也通但上面的Nginx进程已经挂了这时候如果只靠VRRP的默认机制Master照样会通告我活着VIP不会漂移流量仍然打到一台服务已死的机器上。健康检查脚本才是保证VIP跟着健康状态走的关键。2.4 keepalived和LVS是什么关系很多老运维提到keepalived就会想到LVSLinux Virtual Server两者确实有很深的渊源。keepalived最初就是为LVS设计的守护进程负责LVS调度器和后端真实服务器的健康检查后来才把VRRP能力独立出来成为通用的高可用工具。现在keepalived有两种典型用法纯高可用模式两台机器跑同样的服务共享一个VIP主备切换。这也是本文重点讲的场景。LVSkeepalived模式keepalived管理LVS调度器的VIP并通过配置real_server做后端服务器的健康检查实现四层负载均衡和高可用一体化。如果你们公司有自建四层负载均衡的需求LVSkeepalived是比Nginx更高效的方案性能可以轻松跑到几百万并发连接。但要注意keepalived的LVS能力依赖内核的ip_vs模块需要提前确认内核是否支持。3. 部署规划从双机热备到多节点选主3.1 节点规划与VIP设计做高可用集群第一步不是装软件而是画一张清晰的拓扑图。以最常见的双机热备为例规划如下角色主机名IP地址虚拟IP(VIP)系统Masterha-node1192.168.10.11192.168.10.100CentOS 7.9 / Ubuntu 22.04Backupha-node2192.168.10.12192.168.10.100CentOS 7.9 / Ubuntu 22.04VIP设计有几个原则VIP与业务IP同网段VIP必须和两个节点的物理IP在同一个二层网络里否则ARP广播无法生效VIP无法正常漂移。如果跨三层网络需要配置VRRP的组播路由复杂度和坑都会大幅上升。VIP避开DHCP地址池如果内网用了DHCP确认VIP地址不在自动分配范围内避免地址冲突。两台机器尽量异构部署不同机柜、不同电源、不同交换机避免单点故障直接带走整个集群。有人会问能不能做三节点完全可以。VRRP支持多个Backup优先级最高的Backup会在Master故障时接管。三节点的好处是故障时可以由老二接管然后老三顶上变成新备份容错能力更强。但代价是VRRP报文交互更复杂脑裂判断也更麻烦。我的建议是普通业务双机足够核心数据库或网关可以上三机不要盲目追求节点数量。3.2 安装与内核参数准备keepalived的安装非常简单主流系统的软件源里都有。# CentOS / RHEL yum install -y keepalived # Ubuntu / Debian apt-get install -y keepalived但安装完成不等于能用需要先检查两个前置条件。第一VRRP报文是走组播的确保防火墙放行。这里有一个极易踩的坑很多人只记得放行vrrp协议却忘了主备节点之间的其他通信端口。用iptables配置时需要放行VRRP协议协议号为112并放行keepalived健康检查需要的端口。# 放行VRRP协议 iptables -I INPUT -p vrrp -j ACCEPT iptables -I OUTPUT -p vrrp -j ACCEPT第二确认网卡支持组播并且系统的反向过滤规则不会误杀VRRP报文。Linux默认的rp_filter反向路径过滤在某些场景下会丢弃从非对称路径回来的数据包表现为两台keepalived一直互相看不到对端。需要检查并调整# 查看当前的rp_filter设置 cat /proc/sys/net/ipv4/conf/all/rp_filter # 临时关闭生产环境建议按网卡精确配置 sysctl -w net.ipv4.conf.all.rp_filter0这些坑都是我在实际部署中真实踩过的典型的不是软件的问题是系统默认策略的问题。3.3 配置文件结构总览keepalived的主配置文件是/etc/keepalived/keepalived.conf整个文件按功能块组织。理解这些块之间的关系比死记配置项更重要global_defs全局配置包括日志级别、路由器ID、脚本执行用户名等。vrrp_script自定义的健康检查脚本定义检查逻辑和执行频率。vrrp_instanceVRRP实例将上述配置组合起来定义一个具体的VRRP组包括网卡、VIP、优先级等。一个常见的误区是把vrrp_instance理解成配置一个实例就够了两台机器一样。实际上两台机器上的vrrp_instance配置必须保持一致的state和virtual_router_id但priority必须不同。如果两台都是Master就会出现两台争抢VIP的脑裂问题后面详述。4. 核心配置实操主备双机热备完整落地4.1 Master节点配置详解下面是一份我多次用于生产环境的Master配置所有关键参数都带注释global_defs { router_id LVS_HA_01 # 本机标识在同一网络内必须唯一 enable_script_security # 启用脚本安全检查 script_user root # 指定执行脚本的用户 } # 定义健康检查脚本检查nginx进程是否存活 vrrp_script chk_nginx { script /etc/keepalived/check_nginx.sh interval 2 # 每2秒执行一次 timeout 3 # 脚本执行超时时间3秒 rise 2 # 连续成功2次才判定为健康 fall 2 # 连续失败2次才判定为异常 } # 定义一个VRRP实例 vrrp_instance VI_1 { state MASTER # 初始状态为MASTER interface eth0 # 承载VIP的网卡 virtual_router_id 51 # VRRP组ID主备必须一致 priority 150 # 优先级备节点必须低于此值 advert_int 1 # VRRP通告间隔默认1秒 nopreempt # 非抢占模式Master恢复后不主动抢回VIP # preempt_delay 60 # 如果不禁用抢占建议设置延迟时间 authentication { auth_type PASS # 认证类型 auth_pass 1234abc # 认证密码主备必须一致 } virtual_ipaddress { 192.168.10.100/24 dev eth0 label eth0:1 } track_script { chk_nginx # 关联健康检查脚本 } notify_master /etc/keepalived/notify_master.sh notify_backup /etc/keepalived/notify_backup.sh notify_fault /etc/keepalived/notify_fault.sh }这里有几个配置点值得展开说。advert_int决定主备之间的心跳频率默认1秒。如果网络环境稳定可以保持1秒。如果网络抖动频繁可以适当增大到2秒但切换时间会变长。这个参数要和master_down_delay配套考虑不能单方面调小。nopreempt这个参数很多人不理解。默认情况下keepalived是抢占模式一个节点从故障中恢复后如果它的优先级比别人高它会主动抢回VIP。这在某些场景下是好事但也会导致一个问题——主节点恢复时VIP来回漂移一次造成不必要的业务抖动。如果你的业务是无状态的建议开启nopreempt如果有状态依赖比如长连接、分布式锁建议根据业务容忍度决定。这里有个前提条件nopreempt只在state MASTER的节点上配置如果两个节点都配置nopreempt会导致故障后Backup不自动接管。4.2 Backup节点配置Backup节点的配置和Master结构相同主要区别在几个字段vrrp_instance VI_1 { state BACKUP # 初始状态为BACKUP interface eth0 virtual_router_id 51 # 必须与Master一致 priority 100 # 必须低于Master的优先级 advert_int 1 authentication { auth_type PASS auth_pass 1234abc } virtual_ipaddress { 192.168.10.100/24 dev eth0 label eth0:1 } track_script { chk_nginx } }state字段决定的是节点启动时的初始角色注意初始两个字。即使state BACKUP如果Master一直不存活Backup也会主动升级为Master。这里的关键是priority的数值比较谁高谁是Master。在实际运维中我强烈建议不要只跑双主备最好加一个第三节点作为观察者专门用来记录VRRP状态变化日志。因为双机模式下主备之间互相看到的视角有限出了问题很难判断是主挂了还是网络分区了。三节点虽然逻辑上复杂一点但排查问题时有第三者视角效率高很多。4.3 健康检查脚本这是最容易偷懒也最容易出事的地方我个人认为keepalived配置里最重要的不是VRRP实例而是健康检查脚本。前面说过VRRP本身只保证机器活着不保证服务活着。下面是我使用的nginx健康检查脚本示例#!/bin/bash if [ $(pgrep -c nginx) -ge 1 ]; then exit 0 else # 尝试拉起nginx再次检查 systemctl start nginx sleep 2 if [ $(pgrep -c nginx) -ge 1 ]; then exit 0 fi exit 1 fi脚本的核心逻辑是先判断进程是否存活如果不在则尝试拉起拉起失败再判定为不健康。这种自愈优先的思路是生产环境的经验之谈——很多时候服务只是临时抖动给它一次重启机会比直接切换VIP划算得多。因为VIP每漂移一次不仅是几秒钟的抖动还可能导致数据库连接池全部重建、缓存穿透等连锁反应。写脚本有几个注意事项脚本必须具有执行权限chmod x /etc/keepalived/check_nginx.sh脚本尽量使用绝对路径避免PATH环境变量问题避免在脚本里使用复杂的管道和grep因为keepalived执行脚本时会临时切换环境脚本的执行时间要小于interval配置否则会出现脚本堆积CPU飙升如果是数据库场景健康检查脚本会更复杂通常不只是检查进程还要检查主从复制延迟、连接数是否打满、磁盘空间等。记住一个原则健康检查的粒度决定了高可用的粒度。只查进程挂掉的是业务查磁盘和延迟才能避免机器活着但服务已经不可用的隐性故障。4.4 配置校验与启动顺序配置写好后先不要急着启动服务按下面顺序操作可以避免90%的低级错误第一步校验配置文件语法。keepalived -t -f /etc/keepalived/keepalived.conf出现Configuration OK后才说明语法没问题。这一步非常重要我见过太多同事直接systemctl start然后一脸懵地看日志最后发现是配置里少了个花括号。第二步先启动Backup节点再启动Master节点。这个顺序是有讲究的如果先启动MasterMaster会立刻配置VIP此时Backup还没起来整个环境是一台单点如果先启动BackupVIP暂时没人持有但网络层面没有问题等Master启动后会自动接管VIP。先启动Backup可以缩短业务无VIP的空窗期。第三步查看VIP是否正常绑定。ip addr show eth0正常情况下Master节点的eth0上会出现eth0:1这个子接口绑定VIP 192.168.10.100。Backup节点此时不应该有VIP。第四步查看keepalived状态和日志。systemctl status keepalived tail -f /var/log/messages # CentOS journalctl -f -u keepalived # Ubuntu日志里会出现Entering MASTER STATE或Entering BACKUP STATE的关键字这代表状态机切换正常。4.5 故障切换实测验证比配置更重要配置完成不代表高可用生效必须做一次拔线演练。我的做法是分三个层次逐步测试测试一停止keepalived服务。杀掉Master上的keepalived进程观察Backup是否在3-5秒内接管VIP。此时业务访问VIP的流量应该已经切换到Backup。测试二只停止业务服务。把Master上的nginx停掉但keepalived继续运行。这时健康检查脚本应该触发降级逻辑VIP漂移到Backup。这个测试验证的是服务高可用而不是机器高可用。测试三物理断网。直接把Master的网线拔掉或者用iptables模拟网络隔离观察VIP切换情况和日志。这个测试能暴露VRRP报文超时、防火墙拦截等隐藏问题。每次测试后我都建议记录一个切换时间线。比如我在一次线上拔线测试中记录的时间线是T0s拔除Master网线T2.8sBackup日志出现VRRP_Instance(VI_1) Transition to MASTER STATET3.2sVIP出现在Backup节点T3.5s业务侧探测恢复整个切换过程4秒内完成这个数据可以作为后续调优的基准。如果切换时间超过10秒就要排查是健康检查超时设置太长还是交换机ARP表老化时间过长。5. 云原生场景下的适配与踩坑记录5.1 云平台上的VRRP限制别被可用区忽悠了说到云原生必须先说一个很多人都会踩的坑在大多数公有云VPC环境里keepalived的VRRP组播报文是不通的。这不是keepalived的问题而是云平台在底层虚拟网络里默认不让组播通过。这意味着什么你按照传统物理机的配置方式在云主机上搭建keepalived大概率看到的现象是两台云主机上的VIP都看不到对方各自认为自己是MasterVIP被同时绑定在两台机器上。这在网络层面虽然不一定会造成IP冲突因为云平台的vSwitch可能做了隔离但完全是失效状态一旦流量打到错误的机器上就出问题。解决思路有这么几个如果必须要用keepalived选支持组播透传的私有云或专有网络环境比如自建OpenStack或者裸金属托管机房。在公有云上优先使用云平台自带的负载均衡产品或者使用支持单播模式的VRRP实现。keepalived新版本其实可以配置单播模式通过unicast_src_ip和unicast_peer指定对端IP不必依赖组播。这是我在混合云场景下比较推荐的方案。单播模式的配置片段vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 unicast_src_ip 192.168.10.11 unicast_peer { 192.168.10.12 } # 其余配置与组播模式相同 }注意单播模式下对端的IP必须是真实IP而不是VIP同时两个节点都需要互相指定对端地址。这个方案在AWS VPC、阿里云VPC等环境里实测是可以用的但云平台的安全组必须放行VRRP协议协议号112的入站规则。5.2 keepalived与Kubernetes的典型配合方式在K8s体系里keepalived最常见的用法是给多个API Server提供一个稳定入口。自建K8s集群通常会有3个控制平面节点每个节点上跑着apiserver但如果你的kubeconfig里只写了一个节点的IP这个节点挂了整个集群管理面就不可用了。很多生产事故就是这么来的。我的推荐实践是在3个控制平面节点上部署keepalivedVIP作为apiserver的访问入口。这样即使一个节点宕机kubeconfig里的地址始终可用kubectl和各类控制器不会断连。配置里的健康检查脚本要检查apiserver的6443端口#!/bin/bash nc -z 127.0.0.1 6443 exit $?如果apiserver挂了keepalived就把VIP从当前节点漂移到其他节点。这个方案结合kubeadm的external etcd或者stacked etcd都能实现控制面的高可用。还有一类场景是给自建的Ingress Controller做VIP。如果你的Ingress NGINX是跑在宿主机网络模式hostNetwork下的可以用keepalived给多个Ingress节点提供一个统一的入口IP。这样对外暴露的地址只有一个后端不管怎么扩容缩容入口不变。5.3 配置管理云原生时代的自动化适配传统环境里keepalived配置靠手工编辑、scp拷贝、人肉执行。云原生时代还这么干效率太低且容易出错。我建议把keepalived配置纳入配置管理或容器化的体系中。目前在云原生社区里比较成熟的方案是使用MetalLB的ARP模式或BGP模式作为K8s的负载均衡器替代品。但如果你的基础设施还没完全容器化处于虚拟机和容器并存的过渡期keepalived依然是最经济和成熟的选择。对于配置自动化可以这样处理把keepalived.conf模板化用Ansible、SaltStack或Terraform统一渲染分发。健康检查脚本单独管理做成标准化的shell脚本或二进制探针。状态切换的通知脚本notify_master / notify_backup接入企业IM或监控系统做到切换事件实时告警。我见过不少团队高可用切换本身做得很顺利但切换完没人知道直到用户反馈才发现VIP已经漂移了。高可用集群一定要配合告警通知否则自动切换就会变成静默故障。6. 常见问题与排查技巧实录6.1 高频问题速查表整理一份我实际运维中遇到的高频问题方便大家按图索骥现象可能原因排查思路与解决两台机器都绑定了VIP组播不通或单播未配置rp_filter拦截检查VRRP报文是否可达关闭rp_filter确认防火墙放行协议112VIP无法漂移健康检查脚本返回异常优先级配置错误nopreempt配置不当手动执行脚本看返回值检查主备priority确认nopreempt只在Master端keepalived频繁切换advert_int太小网络抖动健康检查脚本误判查看日志中的状态切换记录调大advert_int优化脚本判断逻辑VIP能ping通但业务端口不通健康检查脚本只查进程不查端口业务依赖未就绪脚本中增加端口检测和服务状态检测必要时做业务层HTTP探测主节点恢复后VIP不回切开启了nopreempt或主节点优先级低于备节点确认业务是否需要抢占模式若需回切需配置preempt_delay日志显示Sending gratuitous ARP but no VIP网卡接口名配置错误VIP绑定失败检查interface字段与实际网卡名是否一致用ip a确认网卡状态VRRP报文发送失败SELinux拦截防火墙规则未放行查看审计日志临时关闭SELinux测试放行协议112切换后业务连接中断长连接会话保持问题ARP缓存老化等ARP缓存刷新可在切换时发送免费ARP评估业务是否需要会话保持方案6.2 脑裂问题高可用集群最隐蔽的敌人脑裂Split-Brain是指主备节点都认为自己是Master同时持有VIP的情况。在keepalived里脑裂的典型触发原因是VRRP报文无法传递但两个节点都还活着。脑裂的危害在于两台机器同时接管VIP如果后端是数据库或共享存储类型的有状态服务两个Master同时写入大概率会导致数据损坏。这比单点故障严重得多。预防脑裂的核心思路启用VRRP认证配置auth_type和auth_pass防止其他设备非法加入VRRP组。保持advert_int的一致性如果主备的advert_int不一致会导致状态判断混乱。在上层再加一道保险比如数据库场景用Consul、etcd或ZooKeeper做分布式锁只有抢到锁的节点才能持有VIP。keepalived本身不提供数据一致性保障有状态服务不能只靠VRRP一个机制兜底。我在实际运维中还发现有些机房的交换机端口配置了端口安全策略会限制每端口MAC地址学习数量。VIP漂移后新MAC地址可能被交换机丢弃造成VIP不通。遇到这种问题要检查交换机的port-security配置必要时将VIP对应的MAC地址加入白名单。6.3 日志怎么看从一堆日志里快速定位问题keepalived的日志是排查问题的第一手材料但很多人不会看。这里分享我的日志阅读经验。正常运行时Master节点的日志应该是Keepalived_vrrp[12345]: Sending gratuitous ARP on eth0 for 192.168.10.100 Keepalived_vrrp[12345]: VRRP_Instance(VI_1) Sending/queueing gratuitous ARPs on eth0: 192.168.10.100这代表Master在周期性地发送免费ARP维持VIP的ARP缓存。当状态切换时Backup节点的日志会出现Keepalived_vrrp[12345]: VRRP_Instance(VI_1) Transition to MASTER STATE Keepalived_vrrp[12345]: VRRP_Instance(VI_1) Entering MASTER STATE Keepalived_vrrp[12345]: VRRP_Instance(VI_1) Sending gratuitous ARP on eth0 for 192.168.10.100如果一直出现VRRP_Instance(VI_1) Received higher prio advert说明本节点收到了对端更高优先级的通告此时本节点应该保持在BACKUP状态。如果两个节点都在打这条日志说明两个节点互相能看到但都无法稳定选主通常是优先级配置有问题或者advert_int不一致。日志中如果频繁出现Keepalived_vrrp[12345]: VRRP_Instance(VI_1) Master down说明本节点已经认为Master挂了但随后又收到了Master的通告这一般是网络抖动或VRRP报文丢失导致的。这种情况下调大advert_int和增加master_down_delay是更稳妥的做法而不是追求毫秒级切换。7. 最后分享几点实操体会从传统物理机时代到云原生时代keepalived这个老牌工具不仅没被淘汰反而在混合云、自建K8s等场景里找到了新位置。我个人的体会是工具本身的原理并不复杂真正拉开差距的是对细节的把控——健康检查脚本怎么写得既敏感又稳定VIP漂移时业务侧怎么配合脑裂风险怎么从架构上规避。如果只让我留三条经验我会选这三条第一健康检查脚本的价值远大于VRRP本身的配置。很多高可用方案在真正出故障时才发现VIP切了但服务还是不可用问题就出在健康检查粒度太粗。把健康检查做到业务层高可用才有意义。第二切换测试不能省而且要有预案。不要以为配置完keepalived就高枕无忧了。每三个月至少做一次故障演练把切换时间、业务影响、回滚方案都记录下来。这个习惯在真正出事的时候能救命——你会很清楚系统在故障时大概会怎么表现排查效率完全不一样。第三keepalived不是有状态服务高可用的终点。如果是数据库、缓存这类有状态服务光靠keepalived的VIP漂移是不够的必须结合分布式锁、同步复制、存储层双活等机制一起设计。keepalived负责入口不丢业务层负责数据不丢各司其职才能构建真正可信赖的高可用体系。希望这篇文章能帮你在云原生环境下把keepalived这个基础组件用得明明白白。如果你在生产环境里遇到过什么有意思的切换场景或者诡异的坑欢迎留言一起讨论踩坑经验这种东西交流起来最值钱。