【51CTO.com快譯】一次我們為托管在Kubernetes集群上的一個應用程序增加了HTTP請求，然后導致了5xx錯誤的激增。在一個GraphQL服務器上的一個應用程序，調用大量外部的API，然后返回聚合反應。開始我們采用的應對方法是增加應用程序的副本數量，看它是否提高了性能并減少了錯誤。

隨著我們進一步的深入研究，發現大多數的失敗都與DNS解析有關。這就是我們開始在Kubernetes上深入研究DNS解析的原因。

CoreDNS指標

DNS服務器在其數據庫中存儲記錄，并使用該數據庫回答域名查詢。如果DNS服務器沒有此數據，它會嘗試從其他DNS服務器找到解決方案。

CoreDNS成為Kubernetes 1.13+之后的默認DNS服務。如今，當使用托管Kubernetes集群或為應用程序工作負載自我管理集群時，通常調整應用程序，而沒有過多的關注Kubernetes提供的服務或如何利用它們。

DNS解析是任何應用程序的基本要求，即使是在Kubernetes集群上，也要確保CoreDNS正確配置和運行。

默認情況下，集群應該始終有一個儀表板盤觀察關鍵的CoreDNS指標。為了獲得CoreDNS指標，你應該啟用Prometheus插件作為CoreDNS配置的一部分。

下面是使用Prometheus插件從CoreDNS實例中啟用度量集合的配置示例。

.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods verified
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}

以下是我們建議您在儀表板中使用的關鍵指標。如果你正在使用Prometheus、DataDog、Kibana等，可以從社區/提供者那里找到現成的儀表板模板。

a.高速緩存命中百分比：使用CoreDNS高速緩存響應的請求的百分比；

b.DNS請求延遲：

• CoreDNS：CoreDNS處理DNS請求所花費的時間
• 上行服務器：處理轉發到上行的DNS請求所花費的時間

c.轉發到上行服務器的請求數；

d.請求的錯誤代碼：

• NXDomain：不存在的域
• FormErr：DNS請求格式錯誤
• ServFail：服務器故障
• NoError：無錯誤，已成功處理請求

e.CoreDNS資源使用情況：服務器消耗的不同資源，例如內存，CPU等。

我們使用DataDog來監視特定的應用程序。下面是用DataDog構建的一個示例儀表板：

??

減少DNS錯誤

當我們開始深入研究應用程序如何向CoreDNS發出請求時，我們觀察到大多數出站請求都是通過應用程序向外部API服務器發出的。

這通常是resolv.conf在應用程序部署窗格中的外觀：

nameserver 10.100.0.10
search kube-namespace.svc.cluster.local svc.cluster.local cluster.local us-west-2.compute.internal
options ndots:5

Kubernetes嘗試通過不同級別的DNS查找來解析FQDN。

考慮到上述DNS配置，當DNS解析器向CoreDNS服務器發送查詢時，它會根據搜索路徑嘗試搜索域。

如果我們正在尋找一個域boktube.io，它將執行以下查詢來在最后一個查詢中接收成功的響應:

botkube.io.kube-namespace.svc.cluster.local <= NXDomain
botkube.io.svc.cluster.local <= NXDomain
boktube.io.cluster.local <= NXDomain
botkube.io.us-west-2.compute.internal <= NXDomain
botkube.io <= NoERROR

由于我們進行了過多的外部查找，因此我們收到了很多NXDomain DNS搜索的響應。為了優化這一點，我們在Deployment對象中定制了spec.template.spec.dnsConfig。這是改變的樣子： 

dnsPolicy: ClusterFirst
dnsConfig:
options:
- name: ndots
value: "1"

通過以上改變，pods上的resolve.conf也改變了。只對外部域執行搜索。

這減少了對DNS服務器的查詢數量，也有助于減少應用程序的5xx錯誤。通過下圖可以看出NXDomain響應次數的差異：

??

因此我們收到了許多NXDomain響應DNS搜索。為了對此進行優化，我們在Deployment對象中自定義了spec.template.spec.dnsConfig。這是變化的樣子：

針對此問題的更好解決方案是在Kubernetes 1.18+中引入的[Node Level Cache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)。

根據您的需要自定義CoreDNS

我們可以使用插件自定義CoreDNS。Kubernetes支持不同類型的工作負載，而標準的CoreDNS配置可能無法滿足你的所有需求。CoreDNS有兩個樹內插件和外部插件。

您嘗試解析的FQDN的類型可能會根據你在集群上運行的工作負載的類型而有所不同，例如應用程序之間是否相互通信或在Kubernetes集群外部進行交互的獨立應用程序。

我們應該嘗試相應地調整CoreDNS的旋鈕。假設您在特定的公共/私有云中運行Kubernetes，并且大多數由DNS支持的應用程序都在同一云中。在這種情況下，CoreDNS還提供特定的云相關或通用插件，可用于擴展DNS區域記錄。

決定的關鍵因素之一是你是否在Kubernetes集群中運行適當數量的CoreDNS實例。建議至少運行兩個CoreDNS服務器實例，以更好地保證DNS請求得到服務。

你可能需要為您的集群添加額外的CoreDNS實例或配置HPA (Horizontal Pod Autoscaler)，具體取決于服務的請求數量、請求的性質、在集群上運行的工作負載數量和集群的大小。

諸如被服務的請求數量、請求的性質、在集群上運行的工作負載數量以及集群大小等因素應該有助于你決定CoreDNS實例的數量。

本強調了Kubernetes中DNS請求循環的重要性。很多時候，我們會覺得這不是DNS的問題，但最終會發現確實的DNS問題，小心這個坑。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】