无法在我的Kubernetes Windows设置中解析其他服务的主机名

时间:2017-08-03 14:07:39

标签: kubernetes azure-container-service

我最近遵循了有关如何将Kubernetes与Windows pods(https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough)一起使用的教程。我决定将示例扩展到两个服务,一个前端调用后面的一个。简化为:

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

但是现在当我连接到其中一个前节点时:

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

我无法ping通其他服务:

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

我听说可能是因为选择了两个网络接口和错误的DNS服务器,但我没有找到在部署中指定任何内容的方法。

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

2 个答案:

答案 0 :(得分:1)

  

无法在我的Kubernetes中解析其他服务的主机名。

这是一种设计行为。因为群集IP不存在。

在Kubernetes中,群集中的所有服务都由 kube-proxy 处理。 kube-proxy在集群中的每个节点上运行,它为每个服务编写 iptables 规则(Linux节点,与windows相同)。这些iptables规则管理朝向服务IP的流量。他们实际上没有任何ICMP规则,因为它不需要。

但我们可以ping pod IP或pod的DNS。

例如,我们可以使用此命令列出pod的IP地址:

root@k8s-master-9F42C511-0:~# kubectl get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP           NODE
azure-vote-back-3048739398-8zx8b   1/1       Running   0          18m       10.244.1.2   k8s-agent-9f42c511-0
azure-vote-front-837696400-tglpn   1/1       Running   0          18m       10.244.1.3   k8s-agent-9f42c511-0

然后我们使用一个pod来ping这些IP地址:

root@k8s-master-9F42C511-0:~# kubectl exec -it azure-vote-front-837696400-tglpn -- /bin/bash
root@azure-vote-front-837696400-tglpn:/app# ping 10.244.1.3
PING 10.244.1.3 (10.244.1.3): 56 data bytes
64 bytes from 10.244.1.3: icmp_seq=0 ttl=64 time=0.063 ms
64 bytes from 10.244.1.3: icmp_seq=1 ttl=64 time=0.052 ms
^C--- 10.244.1.3 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.052/0.057/0.063/0.000 ms
root@azure-vote-front-837696400-tglpn:/app# ping 10.244.1.4
PING 10.244.1.4 (10.244.1.4): 56 data bytes
64 bytes from 10.244.1.4: icmp_seq=0 ttl=64 time=0.102 ms
64 bytes from 10.244.1.4: icmp_seq=1 ttl=64 time=0.098 ms
^C--- 10.244.1.4 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.098/0.100/0.102/0.000 ms

另外,我们可以ping pod的A记录。在kubernetes中,pod的记录形式为pod-ip-address.my-namespace.pod.cluster.local

例如,名称空间为1.2.3.4且IP名称为default的IP cluster.local的容器会有一个条目:1-2-3-4.default.pod.cluster.local

在我的实验室中,我的pod的A记录如下:

root@k8s-master-9F42C511-0:~# kubectl exec -it azure-vote-front-837696400-tglpn -- /bin/bash
root@azure-vote-front-837696400-tglpn:/app# ping 10-244-1-2.default.pod.cluster.local                                                                                                              
PING 10-244-1-2.default.pod.cluster.local (10.244.1.2): 56 data bytes
64 bytes from 10.244.1.2: icmp_seq=0 ttl=64 time=0.103 ms
64 bytes from 10.244.1.2: icmp_seq=1 ttl=64 time=0.087 ms
64 bytes from 10.244.1.2: icmp_seq=2 ttl=64 time=0.096 ms
^C--- 10-244-1-2.default.pod.cluster.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.087/0.095/0.103/0.000 ms

因此,我们无法 ping群集IP地址,但我们可以使用网址对其进行测试。我们可以ping pod的IP地址和A记录。

<强>更新
对不起,我的错误是,k8s A记录规则适用于Linux Agent,但不适用于Windows代理。

enter image description here 有关Windows服务器容器的更多信息,请参阅此article

答案 1 :(得分:1)

因此,在尝试了不同的场景后,我想我会删除设置并再次尝试,指定特定版本的microsoft / iis - 并且它有效:

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

我的假设是,在重新创建资源组和群集之后,我或者落在一个性能更好的实例上,或者指定容器图像的哪个确切版本可以解决这个问题。