<p>I have recently followed the tutorial on how to use Kubernetes with Windows pods ( <a href="https://learn.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough</a> ). I decided to extend the example to two services, one front calling the one in the back. Simplified:</p>

<p><a href="https://gist.github.com/sebug/f478f1cfd0a793e8d556c6001bbbe142" rel="nofollow noreferrer">https://gist.github.com/sebug/f478f1cfd0a793e8d556c6001bbbe142</a></p>

<p>But now when I connect to one of the front nodes:</p>

<pre><code>kubectl exec -it samplefront-2836659004-4m824 -- powershell
</code></pre>

<p>I can't ping the other service:</p>

<pre><code>PS C:\&gt; ping sample-back
Ping request could not find host sample-back. Please check the name and try again.
</code></pre>

<p>I heard that it may be because of the two network interfaces and the wrong DNS server being chosen, but I have not found a way to specify anything in the deployment.</p>

<pre><code>Windows IP Configuration


Ethernet adapter vEthernet (Container NIC 7baf5cc0):

Connection-specific DNS Suffix  . :
Link-local IPv6 Address . . . . . : fe80::f182:e2e7:7bce:ed60%33
IPv4 Address. . . . . . . . . . . : 10.244.0.211
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.244.0.1

Ethernet adapter vEthernet (Container NIC ae765bad):

Connection-specific DNS Suffix  . : 10jheu23yh0ujpey5vzw0q45qg.ax.internal.cloudapp.net
Link-local IPv6 Address . . . . . : fe80::c4dc:b785:9cd:2a7b%37
IPv4 Address. . . . . . . . . . . : 172.31.245.122
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.31.240.1
</code></pre>

<p>So after trying out different scenarios I figured I'd delete the setup and try again, specifying a specific version of microsoft/iis - and it worked:</p>

<p><a href="https://gist.github.com/sebug/0f7776668fff4e0e6b3f3d313846afa6" rel="nofollow noreferrer">https://gist.github.com/sebug/0f7776668fff4e0e6b3f3d313846afa6</a></p>

<pre><code>kripke:Documents/Projets/ScaledSample% kubectl exec -it samplefront-1226573881-21bbh -- ping sample-back


Pinging sample-back [10.0.216.120] with 32 bytes of data:
Reply from 10.0.216.120: bytes=32 time&lt;1ms TTL=128
Reply from 10.0.216.120: bytes=32 time&lt;1ms TTL=128
Reply from 10.0.216.120: bytes=32 time&lt;1ms TTL=128
Reply from 10.0.216.120: bytes=32 time&lt;1ms TTL=128

Ping statistics for 10.0.216.120:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
</code></pre>

<p>My hypothesis is that either I fell on a more well-behaved instance after having recreated the resource group and cluster or that this specifying which exact version of the container image did the trick.</p>
