kube-proxy与CNI差异及Calico网络配置相关问题咨询

kube-proxy是Kubernetes内置的专属网络组件，核心职责单一：实现Service的负载均衡逻辑，将访问Service的流量按规则转发到后端对应Pod，它不负责Pod跨节点连通、不负责网络访问控制。
CNI是容器网络接口标准，符合该标准的网络插件（如Calico、Flannel、Cilium）核心职责是为Pod分配IP、搭建Pod跨节点通信的网络平面、落地NetworkPolicy访问控制规则；部分CNI的特定模式（如Calico eBPF模式、Cilium eBPF模式）也可以完全接管原本kube-proxy负责的Service负载均衡逻辑。

1. Calico是否使用iptables设置策略？与kube-proxy是否存在角色重叠、功能区别是什么？ #

默认非eBPF模式下的Calico确实会使用iptables写入规则，但二者不存在核心角色重叠，只是都把iptables作为数据面配置工具，负责的流量处理环节完全独立：

• kube-proxy的规则全部写入iptables的nat表，核心作用是监听集群Service、EndpointSlice资源变化，完成ClusterIP、NodePort、LoadBalancer类型Service的DNAT转换、后端Pod负载分发，完全不涉及Pod间访问控制、跨节点路由逻辑。
• Calico的规则绝大多数写入iptables的filter表，少量写入mangle表，核心作用是落地NetworkPolicy的访问控制逻辑（如跨命名空间访问隔离、端口级访问权限控制），同时Calico负责维护节点路由表实现跨节点Pod流量转发，不会触碰Service负载均衡相关的nat表规则。

二者的关系类似同一台服务器上两个不同的服务都调用系统防火墙接口配置规则，功能边界清晰，不存在重叠冲突。

2. 为什么Calico eBPF模式下需要禁用kube-proxy？是不是使用eBPF就必须禁用iptables模式的kube-proxy？ #

禁用kube-proxy和eBPF、iptables的技术兼容性无关，核心原因是Calico eBPF数据面已经完整实现了kube-proxy的所有Service负载均衡能力，留着kube-proxy会导致规则重复、流量异常：

• 首先纠正误区：eBPF程序和iptables规则完全可以在同一节点共存，不存在技术冲突。但只要kube-proxy进程在运行，就会持续向iptables写入Service转发规则，同时Calico的eBPF程序会在网卡TC钩子、套接字层hook流量做Service转发，同一流量被两套逻辑重复处理，会引发丢包、连接重置、性能损耗等问题。
• Calico eBPF模式的Service转发实现性能远高于iptables模式的kube-proxy：不需要遍历冗长的iptables规则链，还支持DSR直接返回、更精准的会话保持等优化，因此官方要求直接禁用kube-proxy，由Calico完全接管Service流量处理，避免规则冲突。
  如果使用的eBPF CNI没有实现Service负载均衡逻辑，完全可以正常运行iptables模式的kube-proxy，不需要禁用。

3. 如果禁用kube-proxy，节点上已有的iptables策略是否会被移除？ #

结果完全取决于禁用kube-proxy的操作方式：

• 如果只是手动将kube-proxy的DaemonSet副本缩为0、或直接停止节点上的kube-proxy进程，之前写入的iptables规则不会自动移除。iptables规则存储在内核netfilter模块的内存中，进程退出不会主动清理已写入的规则，残留的KUBE-*前缀规则会持续生效，极易引发Service流量异常。
• 如果按照Calico官方流程开启eBPF模式，Calico的node组件会自动检测并清理kube-proxy写入的所有KUBE-*前缀专属链和规则，不会触碰Calico自身的规则，也不会影响节点上其他服务（如系统防火墙、用户自定义）的iptables规则。
• 如果是手动部署且未开启Calico的自动清理配置，需要手动执行iptables清理命令删除所有KUBE-*相关的链和关联规则，否则残留规则会持续干扰流量转发。

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