主持人 > 博客 > 管理 > Kubernetes 中的 DNS 查找

Kubernetes 中的 DNS 查找

筆記。 翻譯。：Kubernetes中的DNS問題，或更準確地說是參數設定問題 ndots，出乎意料地受歡迎，而且已經 不是第一 年。 在關於這個主題的另一篇文章中，其作者，一位來自印度一家大型經紀公司的 DevOps 工程師，以非常簡單和簡潔的方式談論了對於操作 Kubernetes 的同事來說有用的知識。

Kubernetes 中的 DNS 查找

在 Kubernetes 上部署應用程式的主要好處之一是無縫應用程式發現。 由於服務理念（服務），這是一個支援一組 pod IP 位址的虛擬 IP。 例如，如果服務 vanilla 希望聯繫服務人員 chocolate，可以直接存取虛擬IP chocolate。 問題出現了：在這種情況下誰會解析 DNS 請求 chocolate 如何？

DNS 名稱解析是在 Kubernetes 叢集上設定的 核心DNS。 Kubelet 使用 CoreDNS 註冊一個 pod 作為檔案中的名稱伺服器 /etc/resolv.conf 所有豆莢。 如果你看一下內容 /etc/resolv.conf 任何 pod，它都會看起來像這樣：

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

DNS 用戶端使用此設定將請求轉送至 DNS 伺服器。 在文件中 resolv.conf 包含以下資訊：

  • 名稱服務器：DNS 請求將傳送到的伺服器。 在我們的例子中，這是 CoreDNS 服務的地址；
  • 搜索：定義特定網域的搜尋路徑。 有趣的是 google.com 或 mrkaran.dev 不是 FQDN (完全合格的域名）。 根據大多數 DNS 解析器遵循的標準約定，只有那些以點「.」結尾（代表根區域）的域才被視為完全限定 (FDQN) 域。 有些解析器可以自己加一個點。 因此， mrkaran.dev. 是完全限定網域名稱 (FQDN)，且 mrkaran.dev - 不;
  • 恩點：最有趣的參數（本文就是關於它的​​）。 ndots 指定請求名稱被視為「完全限定」網域名稱之前的閾值點數。 稍後我們分析 DNS 查找序列時會詳細討論這一點。

Kubernetes 中的 DNS 查找

讓我們看看當我們詢問時會發生什麼 mrkaran.dev 在吊艙中：

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

對於本實驗，我將 CoreDNS 日誌記錄等級設定為 all （這使得它相當冗長）。 讓我們來看看 pod 的日誌 coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

唷。 這裡有兩件事引起了您的注意：

  • 請求會經歷搜尋的所有階段，直到回應包含程式碼 NOERROR （DNS 客戶端理解它並儲存它作為結果）。 NXDOMAIN 表示沒有找到給定網域的記錄。 因為 mrkaran.dev 不是 FQDN 名稱（根據 ndots=5)，解析器查看搜尋路徑並確定請求的順序；
  • Записи А и АААА 並行到達。 事實上，一次性請求 /etc/resolv.conf 預設情況下，它們的配置方式是使用 IPv4 和 IPv6 協定執行平行搜尋。 您可以透過新增選項來取消此行為 single-request в resolv.conf.

注： glibc 可以配置為按順序發送這些請求，並且 musl - 不，所以 Alpine 用戶應該注意。

使用 ndot 進行實驗

讓我們多做一些實驗 ndots 讓我們看看這個參數的行為。 這個想法很簡單： ndots 決定 DNS 用戶端是否將網域視為絕對網域或相對網域。 例如，對於一個簡單的 google DNS 用戶端，它如何知道該網域是否是絕對的？ 如果你設定 ndots 等於 1，客戶會說：「哦，在 google 沒有一個點； 我想我會瀏覽整個搜索列表。” 然而，如果你問 google.com，後綴清單將被完全忽略，因為請求的名稱滿足閾值 ndots （至少有一點）。

讓我們確定一下：

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

核心 DNS 日誌：

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

自從在 mrkaran 沒有一個點，搜尋是在整個後綴列表中進行的。

註：實際中取最大值 ndots 僅限 15 名； Kubernetes 中預設值為 5。

生產中的應用

如果應用程式進行大量外部網路調用，則在活動流量的情況下，DNS 可能會成為瓶頸，因為名稱解析會產生許多不必要的查詢（在系統找到正確的查詢之前）。 應用程式通常不會為網域添加根區域，但這聽起來像是一種駭客行為。 也就是說，而不是問 api.twitter.com，你可以「硬編碼」它 api.twitter.com. （帶點）在應用程式中，這將提示 DNS 用戶端直接在絕對網域上執行權威查找。

此外，從 Kubernetes 版本 1.14 開始，擴展 dnsConfig и dnsPolicy 獲得了穩定的狀態。 因此，部署 pod 時，可以減少該值 ndots，比如說，最多 3 個（甚至最多 1 個！）。 因此，節點內的每條訊息都必須包含完整的域。 當您必須在性能和便攜性之間做出選擇時，這是典型的權衡之一。 在我看來，只有當超低延遲對您的應用程式至關重要時，您才應該擔心這一點，因為 DNS 結果也在內部快取。

引用

我第一次了解到這個功能是在 K8s 聚會，於25月XNUMX日舉行。 除其他事項外，還就這個問題進行了討論。

以下是一些進一步探索的連結：

  • 說明，為什麼 Kubernetes 中 ndots=5；
  • 好東西 更改 ndots 如何影響應用程式效能；
  • 差異 musl 和 glibc 解析器之間。

注意：我選擇不使用 dig 在這篇文章中。 dig 自動新增一個點（根區域標識符），使域「完全限定」（FQDN）， 沒有 首先透過搜尋列表運行它。 寫過這個 以前的出版物之一。 然而，令人驚訝的是，通常必須為標準行為指定一個單獨的標誌。

祝 DNS 解析愉快！ 回頭見！

譯者PS

另請閱讀我們的博客：

來源： www.habr.com

添加評論