Kubernetes：慢DNS

我有一個使用內部AWS的kube-up.sh腳本初始化的Kubernetes集羣，偶爾也從另一個吊艙內找到一個服務的時候是一個非常緩慢的DNS查找。這裏是基本的圖片：Kubernetes：慢DNS

(browser) 
     | 
     V 
     (ELB) 
     | 
     V 
(front-end service) 
     | 
     V 
    (front-end pod) 
     | 
     V 
(back-end service) 
     | 
     V 
    (back-end pod) 
     | 
     V 
    (database)

我已經安裝在前端時間記錄和後端的水平，他們的人數是一些請求大相徑庭。偶爾我們會看到一個請求，FE nginx日誌記錄所需的時間爲8.3秒，但後端的gunicorn進程需要30ms。

我可以exec到FE莢，做一個curl到後端終點獲得根據this blog post示例時序數據，它看起來像這樣：

 time_namelookup: 3.513 
      time_connect: 3.513 
     time_appconnect: 0.000 
     time_pretransfer: 3.513 
      time_redirect: 0.000 
    time_starttransfer: 3.520 
         ---------- 
      time_total: 3.520

所以緩慢似乎將來自DNS。我們有一個獨立的集羣用於分級，這種事情似乎並沒有發生，所以我不知道該怎麼做。大多數請求發生在合理的時間內，小於50ms，但每十分之一左右需要幾秒鐘才能解決。

我發現this thread這聽起來像SkyDNS的使用etcd可能是問題，但我不知道如何驗證或修復它。這種情況發生在的方式往往是週期性缺少配置值（我們的流量不是那麼高）。

來源

2015-09-16 Ben Straub

有已經被證明在Kubernetes集羣1.0.5及以上導致此問題在這裏（https://github.com/kubernetes/kubernetes/pull/13345）修正了一個錯誤。該問題在1.0.6 release中得到解決。

來源

2015-09-16 17:32:07

注到未來的讀者：**重啓KUBE-代理手動**上升級到1.0.6後，所有的爪牙。 'systemctl restart kube-proxy'在我的情況。 –

所以我運行1.0.6和仍然看到正在5秒 – Mike

@mike我們看到在v1.1.7同一個問題的DNS解析：5秒分辨率上的一些名字，不是全部。你找到根源了嗎？修復？ –

默認情況下，kubernetes配置莢同時使用skydns（解析服務名稱）以及底層基礎架構的解析器（解析外部請求）。泊塢窗容器內的解析程序庫將發送請求skydns或輪循方式外旋..它也試圖通過首先包括完整的名稱（例如service.namespace.svc.domain），然後修剪產生的請求名稱（例如service.namespace.svc; service.namespace）。如果第一個請求被髮送到錯誤的服務器，這可能導致更長的超時時間。

如果您不關心外部解析器，則可以使用kubelet標誌「--resolv-conf」覆蓋解析行爲，該標誌允許您指定一組備用外部解析器（或無）。

來源

2015-09-30 04:01:28

Kubernetes：慢DNS

回答

相關問題