转自云原生社区
在iptables模式下，kube-proxy 会监视 Kubernetes control plane对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组后端（endpoint）中的某个 Pod 上面。 对于每个 Endpoints 对象，它也会配置 iptables 规则（这里取决于是否使用ipvs 如果是ipvs的话就会使用ipvs），这个规则会选择一个后端组合。kube-proxy 负责维护的有 ClusterIP、NodePort、ExternalIP(LoadBalancer) 相关的 iptables 规则生成，因此除了 ClusterIP（也就是我们在Pod内部直接去使用类似telnet cluster ip 的pod port），其他两种应该都会受到影响。
关于coredns, coredns 的作用是解析Service name到clusterip , 而因为没有kube-proxy，所有不会生成iptables或ipvs的规则，因此无法找到后端的endpoint。（也就是我们在Pod内部去使用svcname.namespace.svc.cluster.local是无法成功的）pod可以通过coredns找到svc 但是从svc向ep 做负载转发就会失败
关于Ingress这块，个别ingress是没有使用kube-proxy的，例如nginx-ingress 就没有用 kube-proxy，但是nginx-ingress用到了svc 然后用svc 去找endpoint了。为啥Ingress 不受影响，因为 endpoints 资源不是 kube-proxy 生成的，而是 endpoint controller 根据 Service、Pod 事件生成的。所以 Ingress 还是可以解析到 Service 对应的 Endpoints，功能也就不受影响了。
关于CNI， 在Pod内部，直接访问 PodIP，这部分功能是由 CNI 主要负责完成的，跟kube-proxy无关。