DNS不能通過pod上的TCP工作

Question

我有一個Openshift Origin安裝（v.1.2.1，但也在1.3.0上重現了這個問題），並且我試圖通過服務名稱從DNS獲取pod的IP 。假設我的節點IP爲192.168.58.6，並且在項目'hz-test'中尋找無頭服務'hz'的pod。當我嘗試發送到的dnsmasq DNS請求（這是安裝在節點和將請求轉發到Kubernetes' SkyDNS）在UDP上，一切順利的話：

# 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的DNS（避免使用dnsmasq），並且此查詢也可以。

那麼，爲什麼節點上的dnsmasq忽略來自pod的TCP請求，以及爲什麼其他通信沒問題？它應該是行爲嗎？

任何幫助和想法表示讚賞。

Answer 1

最後，原因是dnsmasq被配置爲偵聽節點的IP（listen-adress = 192.168.58.6）。通過這種配置，dnsmasq綁定到全部節點的網絡接口，但試圖拒絕用戶空間（即它自己）的「錯誤」連接。

我真的不明白，爲什麼的dnsmasq決定，從莢192.168.58.6要求用這樣的配置被禁止的，但我得到了它，通過改變「聽地址」努力

interface=eth0 
bind-interfaces 

迫使dnsmasq實際上只綁定到IP爲192.168.58.6的網卡。之後，dnsmasq開始接受所有的TCP請求。