无法在我的 Kubernetes Windows 设置中解析其他服务的主机名
Can't resolve another service's hostname inside my Kubernetes Windows setup
我最近学习了如何通过 Windows pods ( https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough ) 使用 Kubernetes 的教程。我决定将示例扩展到两个服务，一个在前面调用另一个在后面。简体：
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
Can't resolve another service's hostname inside my Kubernetes.
这是设计使然的行为。因为集群IP不存在
在 Kubernetes 中，集群中的所有服务都由 kube-proxy 处理。 kube-proxy 运行在集群中的每个节点上，它的作用是为每个服务写入 iptables 规则（Linux 节点，与 windows 相同）。这些 iptables 规则管理 流向 服务 IP 的流量。他们实际上没有任何 ICMP 规则，因为不需要它。
但是我们可以ping pod IP或者pod的DNS。
例如，我们可以使用此命令列出 pods 个 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的A记录形式为pod-ip-address.my-namespace.pod.cluster.local.
例如，在命名空间 default 中 IP 地址为 1.2.3.4 且 DNS 名称为 cluster.local 的 pod 将有一个条目：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 地址，但我们可以使用URL 来测试它。我们可以ping pod的IP地址，A记录。
更新:
抱歉我的错误，k8s A 记录规则适用于 Linux 代理，但不适用于 windows 代理。
更多关于windows服务器容器的信息，请参考这篇article.
因此，在尝试了不同的场景之后，我想我应该删除设置并重试，指定 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
我的假设是，要么我在重新创建资源组和集群后找到了一个性能更好的实例，要么指定了容器映像的确切版本就成功了。
我最近学习了如何通过 Windows pods ( https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough ) 使用 Kubernetes 的教程。我决定将示例扩展到两个服务，一个在前面调用另一个在后面。简体：
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
Can't resolve another service's hostname inside my Kubernetes.
这是设计使然的行为。因为集群IP不存在
在 Kubernetes 中，集群中的所有服务都由 kube-proxy 处理。 kube-proxy 运行在集群中的每个节点上，它的作用是为每个服务写入 iptables 规则（Linux 节点，与 windows 相同）。这些 iptables 规则管理 流向 服务 IP 的流量。他们实际上没有任何 ICMP 规则，因为不需要它。
但是我们可以ping pod IP或者pod的DNS。
例如，我们可以使用此命令列出 pods 个 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的A记录形式为pod-ip-address.my-namespace.pod.cluster.local.
例如，在命名空间 default 中 IP 地址为 1.2.3.4 且 DNS 名称为 cluster.local 的 pod 将有一个条目：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 地址，但我们可以使用URL 来测试它。我们可以ping pod的IP地址，A记录。
更新:
抱歉我的错误，k8s A 记录规则适用于 Linux 代理，但不适用于 windows 代理。
因此，在尝试了不同的场景之后，我想我应该删除设置并重试，指定 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
我的假设是，要么我在重新创建资源组和集群后找到了一个性能更好的实例，要么指定了容器映像的确切版本就成功了。