Search code examples
kubernetesazure-container-service

Can't resolve another service's hostname inside my Kubernetes Windows setup

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

https://gist.github.com/sebug/f478f1cfd0a793e8d556c6001bbbe142

But now when I connect to one of the front nodes:

kubectl exec -it samplefront-2836659004-4m824 -- powershell

I can't ping the other service:

PS C:\> ping sample-back
Ping request could not find host sample-back. Please check the name and try again.

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.

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
Solution

  • 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:

    https://gist.github.com/sebug/0f7776668fff4e0e6b3f3d313846afa6

    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<1ms TTL=128
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128
Reply from 10.0.216.120: bytes=32 time<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

    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.