Kubernetes集群中为NodePort服务配置Keepalived的最佳实践咨询

针对你提到的K8s集群结合Keepalived搭建高可用架构的两个问题，我结合实际运维经验给你梳理下：

Keepalived的部署方式主要分两种，各有优劣，需要结合你的场景选择：

• 节点级部署（直接在K8s节点上安装Keepalived服务）
  优点是稳定性拉满——它不依赖K8s集群的运行状态，哪怕某个节点的kubelet、容器运行时出故障，Keepalived依然能正常工作，保障VIP的切换和服务入口的可用性，非常适合对外提供稳定访问入口的场景。
  缺点是运维成本稍高，需要单独维护每个节点上的Keepalived配置、版本和运行状态，没法借助K8s的统一管理能力（比如滚动更新、ConfigMap同步配置）。

• Pod形式部署（用DaemonSet在每个节点上运行Keepalived Pod）
  优点是完全融入K8s生态，用DaemonSet可以确保每个节点都自动运行一个实例，配置可以通过ConfigMap统一管理，更新、监控都能借助K8s的工具链完成，运维更统一便捷。
  缺点是依赖K8s节点的正常运行，如果节点的kubelet挂了，对应的Keepalived Pod也会停止，极端情况下可能影响VIP的可用性。

建议：如果你的核心需求是保障外部访问的高可用（哪怕K8s节点出现部分故障），优先选节点级部署；如果更看重运维的统一性和便捷性，且集群整体稳定性有保障，Pod形式的DaemonSet部署是更好的选择。

先明确：kube-ipvs0接口确实不能用于Keepalived配置。这个接口是K8s开启IPVS模式后自动创建的虚拟接口，它的状态为down是正常行为——它仅用来承载IPVS的规则，本身并不负责实际的流量收发，所以Keepalived无法通过它绑定VIP和进行VRRP通信。

如果是在节点上部署Keepalived，你需要使用节点的实际外部通信接口，也就是节点上用来对外提供服务、能接收外部流量的物理/虚拟网卡（比如常见的eth0、ens33、bond0等）。判断标准很简单：这个接口配置了节点的公网/内网可访问IP，NodePort服务的流量最终是通过这个接口进入节点的。

给你一个keepalived.conf的接口配置示例：

vrrp_instance VI_1 {
    state MASTER
    interface eth0  # 这里填写节点的外部接口名称
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.142.1.100/24 dev eth0  # VIP绑定到外部接口
    }
}

另外，如果选择Pod形式部署Keepalived，必须在Pod配置中开启hostNetwork: true，这样Pod才能直接使用节点的网络命名空间，访问到节点的外部接口，否则Pod无法操作节点网卡来绑定VIP。

最后补充一点：不管用哪种部署方式，都要确保集群内所有节点之间的VRRP通信不受防火墙拦截——VRRP使用IP协议号112，需要在节点上放开对应的规则（比如iptables -A INPUT -p 112 -j ACCEPT）。

内容的提问来源于stack exchange，提问作者TangHongWan