Closed namliz closed 8 years ago
First, I'd like to see you write up a more detailed reproduction of this bug, either a new one or on one of those issues.
Second, I don't see why you can't continue work on the CNCF Community Cluster in the meantime.
Why is this closed? It would be good to link to what solution was proposed (if any).
kubernetes/kubernetes#17084, kubernetes/kubernetes#11204, kubernetes/kubernetes#20893, kubernetes/kubernetes#15932
It appears like this is the explanation for two related but separate show stopping problems.
One problem is that kubedns eventually forwards to the outside resolver, in AWS this would be something like 172.20.0.2 -- and AWS apparently doesn't respect traffic coming from a different subnet. Since the request is originating from a pod within an overlay network with an IP of '10.x.x.x' it hangs.
The second problem is that internal resolving via kubedns works when you lookup directly against the kubedns pod.
nslookup kubernetes.default <ip-of-kubednspod>
works.However routing to the kubedns service is broken. It seems for some environments and overlay settings the iptables kube-proxy writes are not quite right.