Change:
proxier.deleteEndpointConnections(endpointUpdateResult.StaleEndpoints) } <ins> func (proxier *Proxier) acceptIPVSTraffic() { sets := []*IPSet{proxier.clusterIPSet, proxier.externalIPSet, proxier.lbIngressSet} for _, set := range sets { var matchType string if !set.isEmpty() { switch set.SetType { case utilipset.BitmapPort: matchType = "dst" default: matchType = "dst,dst" } writeLine(proxier.natRules, []string{ "-A", string(kubeServicesChain), "-m", "set", "--match-set", set.Name, matchType, "-j", "ACCEPT", }...) } } } </ins> // After a UDP endpoint has been removed, we must flush any pending conntrack entries to it, or else we // risk sending more traffic to it, all of which will be lost (because UDP). // This assumes the proxier mutex is held

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In a k8s cluster with IPVS proxy mode, when you create an ingress, the loadbalancer of this ingress can't be createautomatically, which caused the ipvs ci "gci-gce-ipvs" failed, link: http://k8s- The failed case is , with logs: Time out when waiting for for ingress to get an address. I'm not sure why, but I can see the pod keep restarting, And with container logs: AFAIK, ingress IP have nothing to do with kube-proxy, but when I change proxy mode to iptables, then ingress got it's IP in few seconds, though still in status. Is there any conflict between ipvs proxy rules and ingress controller? Maybe have this possibility. What you expected to happen: Ingress can got it's IP in ipvs proxy mode. How to reproduce it (as minimally and precisely as possible): a cluster in gce environment with proxy mode IPVS. . ingress with backends. for the ingress IP. TT Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: gce OS (e.g. from /etc/os-release): Ubuntu16.04.3 Kernel (e.g. ): 4.13.0-1008-gcp -Ubuntu SMP Thu Jan 25 11:08:44 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: cluster/kube-up Others:
/sig network /area ipvs
I found this maybe related with iptables rules , ingress-controller need to validate the default service by access . But the iptables like: That means the access of port will be directly DNAT to nginx-ingress-controller. In iptables proxy mode, DNAT will be done in chain, so the access of still functional. Thoughts?
I think the problem here is that the ingress controller is crash looping. You are correct that kube-proxy has nothing to do with the LB getting an ip address so I think we can rule out iptables / ipvs as the issue. I'm wondering why the nginx ingress controller in the test does not have permission to list objects in kube-system? Let me try reproducing and see what I find.

When you switched back to iptables mode, you say the container was still crashlooping. Was the error the same?
My mistake, actually the error log I pasted before is in iptables proxy mode, ipvs mode ingress-controller log are: I didn't notice the difference before. And now I'm sure the is created by kubenet, in host port map workaround. Problem is the access of is treated as , so match this rule:
So I'm confused. Why don't we see this problem in iptables mode then? What is the fix on the IPVS side?
I think that's because in iptables proxy mode, we don DNAT in , so traffic of service will never come to . Besides, iptables will match all virtual server IP in ipvs rules, make things even worse.
I think they are same issue.
/assign
Still get this issue with kubernetes 1.11.0. See below iptable rules in my host,