【51CTO.com快譯】一次我們?yōu)橥泄茉贙ubernetes集群上的一個(gè)應(yīng)用程序增加了HTTP請(qǐng)求，然后導(dǎo)致了5xx錯(cuò)誤的激增。在一個(gè)GraphQL服務(wù)器上的一個(gè)應(yīng)用程序，調(diào)用大量外部的API，然后返回聚合反應(yīng)。開始我們采用的應(yīng)對(duì)方法是增加應(yīng)用程序的副本數(shù)量，看它是否提高了性能并減少了錯(cuò)誤。

隨著我們進(jìn)一步的深入研究，發(fā)現(xiàn)大多數(shù)的失敗都與DNS解析有關(guān)。這就是我們開始在Kubernetes上深入研究DNS解析的原因。

CoreDNS指標(biāo)

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

CoreDNS成為Kubernetes 1.13+之后的默認(rèn)DNS服務(wù)。如今，當(dāng)使用托管Kubernetes集群或?yàn)閼?yīng)用程序工作負(fù)載自我管理集群時(shí)，通常調(diào)整應(yīng)用程序，而沒有過多的關(guān)注Kubernetes提供的服務(wù)或如何利用它們。

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

默認(rèn)情況下，集群應(yīng)該始終有一個(gè)儀表板盤觀察關(guān)鍵的CoreDNS指標(biāo)。為了獲得CoreDNS指標(biāo)，你應(yīng)該啟用Prometheus插件作為CoreDNS配置的一部分。

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

.: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
}

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

a.高速緩存命中百分比：使用CoreDNS高速緩存響應(yīng)的請(qǐng)求的百分比；

b.DNS請(qǐng)求延遲：

• CoreDNS：CoreDNS處理DNS請(qǐng)求所花費(fèi)的時(shí)間
• 上行服務(wù)器：處理轉(zhuǎn)發(fā)到上行的DNS請(qǐng)求所花費(fèi)的時(shí)間

c.轉(zhuǎn)發(fā)到上行服務(wù)器的請(qǐng)求數(shù)；

d.請(qǐng)求的錯(cuò)誤代碼：

• NXDomain：不存在的域
• FormErr：DNS請(qǐng)求格式錯(cuò)誤
• ServFail：服務(wù)器故障
• NoError：無錯(cuò)誤，已成功處理請(qǐng)求

e.CoreDNS資源使用情況：服務(wù)器消耗的不同資源，例如內(nèi)存，CPU等。

我們使用DataDog來監(jiān)視特定的應(yīng)用程序。下面是用DataDog構(gòu)建的一個(gè)示例儀表板：

??

減少DNS錯(cuò)誤

當(dāng)我們開始深入研究應(yīng)用程序如何向CoreDNS發(fā)出請(qǐng)求時(shí)，我們觀察到大多數(shù)出站請(qǐng)求都是通過應(yīng)用程序向外部API服務(wù)器發(fā)出的。

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

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嘗試通過不同級(jí)別的DNS查找來解析FQDN。

考慮到上述DNS配置，當(dāng)DNS解析器向CoreDNS服務(wù)器發(fā)送查詢時(shí)，它會(huì)根據(jù)搜索路徑嘗試搜索域。

如果我們正在尋找一個(gè)域boktube.io，它將執(zhí)行以下查詢來在最后一個(gè)查詢中接收成功的響應(yīng):

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

由于我們進(jìn)行了過多的外部查找，因此我們收到了很多NXDomain DNS搜索的響應(yīng)。為了優(yōu)化這一點(diǎn)，我們?cè)贒eployment對(duì)象中定制了spec.template.spec.dnsConfig。這是改變的樣子： 

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

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

這減少了對(duì)DNS服務(wù)器的查詢數(shù)量，也有助于減少應(yīng)用程序的5xx錯(cuò)誤。通過下圖可以看出NXDomain響應(yīng)次數(shù)的差異：

??

因此我們收到了許多NXDomain響應(yīng)DNS搜索。為了對(duì)此進(jìn)行優(yōu)化，我們?cè)贒eployment對(duì)象中自定義了spec.template.spec.dnsConfig。這是變化的樣子：

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

根據(jù)您的需要自定義CoreDNS

我們可以使用插件自定義CoreDNS。Kubernetes支持不同類型的工作負(fù)載，而標(biāo)準(zhǔn)的CoreDNS配置可能無法滿足你的所有需求。CoreDNS有兩個(gè)樹內(nèi)插件和外部插件。

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

我們應(yīng)該嘗試相應(yīng)地調(diào)整CoreDNS的旋鈕。假設(shè)您在特定的公共/私有云中運(yùn)行Kubernetes，并且大多數(shù)由DNS支持的應(yīng)用程序都在同一云中。在這種情況下，CoreDNS還提供特定的云相關(guān)或通用插件，可用于擴(kuò)展DNS區(qū)域記錄。

決定的關(guān)鍵因素之一是你是否在Kubernetes集群中運(yùn)行適當(dāng)數(shù)量的CoreDNS實(shí)例。建議至少運(yùn)行兩個(gè)CoreDNS服務(wù)器實(shí)例，以更好地保證DNS請(qǐng)求得到服務(wù)。

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

諸如被服務(wù)的請(qǐng)求數(shù)量、請(qǐng)求的性質(zhì)、在集群上運(yùn)行的工作負(fù)載數(shù)量以及集群大小等因素應(yīng)該有助于你決定CoreDNS實(shí)例的數(shù)量。

本強(qiáng)調(diào)了Kubernetes中DNS請(qǐng)求循環(huán)的重要性。很多時(shí)候，我們會(huì)覺得這不是DNS的問題，但最終會(huì)發(fā)現(xiàn)確實(shí)的DNS問題，小心這個(gè)坑。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】