kube-proxy 的 strictARP 默认配置及原因
kube-proxy 原生默认不启用 strictARP（即默认设为 false），主要原因与 Kubernetes 网络模型的兼容性、默认网络场景的适配以及避免对非 IPVS 场景的干扰有关，具体可从以下角度理解：
总结： （ECMP 配合路由）高可用（公网｜内网）vip 配合 ipvs 使用时才需要启用：屏蔽掉不同节点上的同样 IP 的 ARP，防止产生 ARP 冲突
一般都不会启用：比如 calico，，默认确实没用到
1. strictARP 的作用与适用场景
strictARP 是 IPVS 模式下的一个配置项，其作用是：
当启用 strictARP: true 时，kube-proxy 会在节点的网络接口上设置 arp_ignore=1 和 arp_announce=2 的内核参数。这两个参数的作用是：
-
arp_ignore=1：仅响应目标 IP 是本地接口上配置的 IP 地址的 ARP 请求（不响应其他 IP 的 ARP 请求）。 -
arp_announce=2：发送 ARP 应答时，仅使用发送接口上的 IP 地址作为源 IP（避免使用其他接口的 IP）。
核心目的：
在使用 IPVS 模式并结合 kube-keepalived-vip 等工具实现 VIP（虚拟 IP，如 LoadBalancer 类型 Service 的外部 IP）高可用时，防止节点错误响应其他节点 VIP 的 ARP 请求，避免 VIP 漂移时的网络混乱。
2. 默认不启用的原因
（1）兼容性优先：适配大多数网络场景
- strict arp 模式对于 iptables 场景无效
- 只要不使用高可用 VIP， 也无效 （strict arp 模式即使开始也没有意义）
Kubernetes 默认支持多种网络模式（如 iptables、IPVS），且集群可能使用不同的 CNI 插件（如 Calico、Flannel、Weave 等）。
-
对于 非 IPVS 模式（如默认的 iptables 模式），
strictARP配置是无效的，启用它不会产生任何作用，反而可能让用户混淆配置的意义。 -
对于 IPVS 模式但不使用 VIP 高可用 的场景（如仅用 Service ClusterIP 或 NodePort），
strictARP并非必需，甚至可能引入不必要的 ARP 限制，影响某些依赖 ARP 广播的网络场景（如传统局域网内的 IP 发现）。
因此，默认禁用 strictARP 是为了保证对大多数基础网络场景的兼容性，避免“过度配置”导致意外问题。
（2）避免干扰默认的 Service 网络模型
Kubernetes 的 Service 网络模型依赖于节点对 Service IP（ClusterIP）的 “共享响应” ：所有节点都会通过 iptables/IPVS 规则转发 Service IP 的流量（即使该 Service 后端 Pod 不在当前节点）。
在这种情况下，节点需要响应针对 Service IP 的 ARP 请求（尤其是在二层网络中）。如果默认启用 strictARP: true，会导致节点拒绝响应 Service IP 的 ARP 请求（因为 Service IP 并非节点接口上直接配置的 IP），从而破坏 Service 的正常通信。
只有在特定场景（如使用 VIP 且需要严格控制 ARP 响应）时，才需要手动启用 strictARP，并配合其他工具（如 keepalived）确保 VIP 仅在主节点上被响应。
（3）最小化默认配置原则
Kubernetes 的设计遵循“最小化默认配置”原则：仅启用必要的功能，避免默认开启可能影响兼容性的高级配置。
strictARP 属于针对特定场景（IPVS + VIP 高可用）的优化配置，而非通用场景的必需项，因此默认禁用，由用户根据实际需求手动启用。
总结
strictARP 是 IPVS 模式下为解决 VIP 高可用场景中 ARP 冲突而设计的配置，并非通用需求。由于 Kubernetes 需兼容多种网络模式和场景，默认禁用 strictARP 可避免对常规 Service 通信的干扰，保证基础网络模型的稳定性。当用户明确需要使用 VIP 并配合 IPVS 时，再手动启用即可。
