Question

我有一个Openshift Origin安装（版本1.2.1，但也在1.3.0上重现了这个问题），我试图获得pods＆＃39;来自DNS的IP按服务名称。假设我的节点有IP 192.168.58.6，我寻找无头服务的播客＆＃39; hz＆＃39;在项目＆＃39; hz-test＆＃39;。当我尝试通过UDP向dnsmasq（安装在节点上并将请求转发给Kubernetes＆＃39; SkyDNS）发送DNS请求时，一切顺利：

# 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...>

但是，当我将传输协议切换到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＆＃39; DNS（避免使用dnsmasq），此查询也可以。

那么，为什么节点上的dnsmasq会忽略来自pod的TCP请求，以及为什么其他任何通信都可以呢？它应该是行为吗？

感谢任何帮助和想法。

Answer 1

最后，原因是dnsmasq配置为监听节点的IP（listen-adress = 192.168.58.6）。使用这样的配置，dnsmasq绑定到所有节点的网络接口，但尝试拒绝用户空间中的“错误”连接（即单独使用）。

我真的不明白，为什么dnsmasq决定从pod到192.168.58.6的请求被禁止使用这样的配置，但我通过将“listen-address”更改为

来实现它的工作

interface=eth0
bind-interfaces

强制dnsmasq实际仅绑定到IP为192.168.58.6的NIC。之后，dnsmasq开始接受所有TCP请求。

DNS无法通过pod

1 个答案: