我有一个Openshift Origin安装程序(1.2.1版，但在1.3.0版中也重现了此问题)，并且我正尝试通过服务名称从DNS获取pod的IP。假设我的节点的IP为192.168.58.6，并且在项目“hz-test”中寻找无头服务“hz”的容器。当我尝试通过UDP将DNS请求发送到dnsmasq(安装在节点上并将请求转发到Kubernetes的SkyDNS)时，一切顺利:
# dig +notcp +noall +answer hz.hz-test.svc.cluster.local @192.168.58.6
hz.hz-test.svc.cluster.local. 14 IN A 10.1.2.5
<and so on...>
但是，当我将传输协议(protocol)切换为TCP时，出现以下错误:
# dig +tcp +noall +answer hz.hz-test.svc.cluster.local @192.168.58.6
;; communications error to 192.168.58.6#53: end of file
查看tcpdump输出后，我发现在建立TCP连接(SYN-SYN / ACK-ACK)之后，dnsmasq立即发送回FIN / ACK，并且当DNS客户端尝试使用此连接发送其请求时，dnsmasq发送返回RST数据包而不是DNS应答。我试图从节点iteself上的TCP上执行相同的DNS查询，并且dnsmasq给了我通常的响应，即它在TCP上正常工作，并且仅当我尝试从pod执行请求时才出现问题。另外，我试图通过TCP直接将同样的查询从Pod发送到Kubernetes的DNS(避免使用dnsmasq)，并且该查询也可以。
那么，为什么节点上的dnsmasq会忽略来自Pod的TCP请求，为什么其他任何通信都可以呢？它应该是行为吗？
任何帮助和想法表示赞赏。
最佳答案
最后，原因是将dnsmasq配置为侦听节点的IP(listen-adress = 192.168.58.6)。通过这种配置，dnsmasq绑定(bind)到所有节点的网络接口(interface)，但是尝试拒绝用户空间中的“错误”连接(即，独自)。
我真的不明白，为什么dnsmasq决定使用这种配置禁止从pod到192.168.58.6的请求，但是我通过将“listen-address”更改为
interface=eth0
bind-interfaces
这迫使dnsmasq实际上仅绑定(bind)到IP为192.168.58.6的NIC。之后，dnsmasq开始接受所有TCP请求。
关于kubernetes - DNS无法通过pod的TCP进行工作，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40728110/