首页 文章

可以在我的Kubernetes Windows设置中使用't resolve another service'的主机名

提问于
浏览 次
0

我最近遵循了关于如何将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
kubernetes azure-container-service

2 回答

  • 1

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

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

    在Kubernetes中，集群中的所有服务都由 kube-proxy 处理 . kube-proxy在集群中的每个节点上运行，它为每个服务写入 iptables 规则（Linux节点，与windows相同） . 这些iptables规则管理流量 towards 服务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

    此外，我们可以以 pod-ip-address.my-namespace.pod.cluster.local 的形式ping pod 's A record. In kubernetes, pod'的A记录 .

    例如，名称空间为 default 且IP名称为 cluster.local 的IP为 1.2.3.4 的窗格将具有条目： 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

    所以，我们 can't ping集群IP地址，但我们可以使用URL来测试它 . 我们可以ping pod的IP地址和A记录 .

    Update ：
    抱歉我的错误，k8s A记录规则适用于Linux Agent，但不适用于Windows代理 .

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

    回复于
  • 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

    我的假设是，在重新创建资源组和集群之后，我或者落在一个性能更好的实例上，或者指定了容器映像的哪个确切版本 .

    回复于

相关问题