keepalived 不直接监控 kubernetes ingress，而是通过本地 http 健康检查（如访问 /healthz）探测 ingress-nginx 可用性，并基于结果触发 vip 漂移实现高可用；跨集群需借助 dns 或前置 lb，不可直接使用 vip。
Keepalived 本身不直接监控 Kubernetes Ingress 资源或其后端 Service 的健康状态，它只能基于网络层（TCP 连接、HTTP 状态码）或自定义脚本做探测。要实现“跨集群高可用”，关键不是让 Keepalived 去理解 Ingress 对象，而是让它可靠地感知承载 Ingress 控制器（如 ingress-nginx）的节点是否真正可提供服务。
核心思路：用 Keepalived 管理 VIP，靠真实流量探测判断节点可用性
Keepalived 的 VRRP 实例绑定一个虚拟 IP（VIP），通过优先级和健康检查决定谁持有 VIP。真正的高可用依赖于检查逻辑是否能反映业务可达性。对于 Ingress 场景，不能只 ping 通节点 IP 或端口，而应模拟用户请求——比如访问某个已知健康的服务路径（如 /healthz 或一个真实 backend 的探针端点）。
配置 Keepalived 健康检查的关键步骤
在部署了 ingress-nginx 的节点（例如 node01、node02）上安装并配置 Keepalived：
- 确保所有候选节点都运行着 hostNetwork 模式的 ingress-nginx DaemonSet，这样它的 80/443 端口直接暴露在宿主机网络上，Keepalived 才能本地探测
- 编写检测脚本（例如
/etc/keepalived/check_ingress.sh），内容类似：
#!/bin/bash
curl -f http://127.0.0.1:10254/healthz -o /dev/null -s -w "%{http_code}" | grep -q "200" - 给脚本加执行权限：
chmod +x /etc/keepalived/check_ingress.sh - 在
/etc/keepalived/keepalived.conf中定义 vrrp_script：
vrrp_script chk_ingress {
script "/etc/keepalived/check_ingress.sh"
interval 3
weight -5
fall 2
rise 2
}
再在 vrrp_instance 中引用它：
track_script {
chk_ingress
}
跨集群场景下的注意事项
如果目标是“跨物理集群”（比如同城双活），Keepalived 无法跨 L2 网络工作，此时需换用其他机制：
- VIP 方式仅适用于同一局域网（L2 可达）内的节点。跨机房必须用 DNS 轮询 + TTL 缩短 + 应用层健康反馈，或由云厂商 SLB 统一调度
- 若两个 Kubernetes 集群各自有独立的 ingress-nginx + Keepalived，可配合外部 DNS 实现故障切换，但切换延迟取决于 DNS TTL 和客户端缓存
- 更推荐方案：在两集群前端统一部署 HAProxy 或 Nginx（带主动健康检查），再由 Keepalived 保障这组 LB 节点自身的高可用 —— 即 Keepalived 管 LB，LB 管 Ingress
验证是否生效
完成配置后，执行以下操作确认逻辑闭环：
- 手动停掉一个节点上的 ingress-nginx Pod，观察 Keepalived 日志（
journalctl -u keepalived -f）是否触发权重下降并触发主备切换 - 用
ip a查看 VIP 是否漂移到另一节点 - 从外部 curl VIP 的 HTTP 服务，确认响应正常且返回的是存活节点的后端
- 恢复原节点服务后，检查 VIP 是否按预期（根据
preempt设置）回归
