Communication with services sometimes failed

[vitaliy-leschenko]

Describe the bug
Windows pods can't communicate with services if target pod stay on different Windows node.
Maybe this is duplicate of another issues but symptoms are a little bit difference.

Windows pods can communicate with services from pods that run on Linux without any problem.
Linux pods can communicate with services from pods that run on Windows without any problem.

To Reproduce
Steps to reproduce the behavior:

1. Setup new cluster with 2 linux and 2 windows nodes using PrepareNode.ps1
2. Apply yaml
   It creates 2 daemonsets iis (on windows) and nginx (on linux) and 2 services for each daemonset.
3. Try to connect to one of iis pods and curl:
   curl -Ik nginx.issues.svc.cluster.local <-- will be success in 100% cases
   curl -Ik iis.isses.svc.cluster.local <-- will be success only in cases when it tries to curl from pod that runs on the same node.

Expected behavior
I expect that curl -Ik iis.isses.svc.cluster.local will be success in 100% cases

Kubernetes (please complete the following information):

• Windows Server version: 1809 (10.0.17763.1554)
• Kubernetes Version: 1.19.0 - 1.19.4
• CNI: flannel 0.13 vxlan

Additional context
All pods can ping each others by IP address.
All windows pods can curl from the Internet and ping each other.
Windows pods can curl from windows pods on different nodes by IP address but failed when I try to curl by Service name or Service IP address.

My PR #111 doesn't affect it because it reproduced without it.

[vitaliy-leschenko]

I tried yaml from step 2 on baremetal cluster (1.17.0) created by https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/kubeadm/KubeCluster.ps1 and this issue doesn't reproduced.

[vitaliy-leschenko]

It is truly interesting but the issue doesn't reproduced on Windows Server 1809 (10.0.17763.1294)

[vitaliy-leschenko]

It is look like a Windows issue.

[daschott]

Is this still active?

[vitaliy-leschenko]

@daschott Yes, it is.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[vitaliy-leschenko]

It looks like in 10.0.17763.1999 this issues was fixed. Maybe in one of previous updates but it doesn't matter. Currently we can use latest updates and don't have the issue.