DNS解析異常問(wèn)題排查
本文介紹關(guān)于DNS解析異常的診斷流程、排查思路、常見(jiàn)解決方案和排查方法。
索引
類(lèi)別 | 內(nèi)容 |
診斷流程 | |
排查思路 | |
常見(jiàn)排查方法 | |
常見(jiàn)問(wèn)題及解決方案 |
診斷流程
基本概念
集群內(nèi)部域名:CoreDNS會(huì)將集群中的服務(wù)暴露為集群內(nèi)部域名,默認(rèn)以
.cluster.local
結(jié)尾,這類(lèi)域名的解析通過(guò)CoreDNS內(nèi)部緩存完成,不會(huì)從上游DNS服務(wù)器查詢。集群外部域名:在第三方DNS服務(wù)商、阿里云DNS云解析、PrivateZone等產(chǎn)品注冊(cè)的權(quán)威解析,這類(lèi)域名由CoreDNS的上游DNS服務(wù)器負(fù)責(zé)解析,CoreDNS僅做解析請(qǐng)求轉(zhuǎn)發(fā)。
業(yè)務(wù)Pod:您部署在Kubernetes集群中的容器Pod,不包含Kubernetes自身系統(tǒng)組件的容器。
接入CoreDNS的業(yè)務(wù)Pod:容器內(nèi)DNS服務(wù)器指向了CoreDNS的業(yè)務(wù)Pod。
接入NodeLocal DNSCache的業(yè)務(wù)Pod:集群中安裝了NodeLocal DNSCache插件后,通過(guò)自動(dòng)或手動(dòng)方式注入DNSConfig的業(yè)務(wù)Pod。這類(lèi)Pod在解析域名時(shí),會(huì)優(yōu)先訪問(wèn)本地緩存組件。如果訪問(wèn)本地緩存組件不通時(shí),會(huì)訪問(wèn)CoreDNS提供的kube-dns服務(wù)。
異常診斷流程
判斷當(dāng)前的異常原因。具體信息,請(qǐng)參見(jiàn)常見(jiàn)客戶端報(bào)錯(cuò)。
如果以上排查無(wú)果,請(qǐng)按以下步驟排查。
檢查業(yè)務(wù)Pod的DNS配置,是否已經(jīng)接入CoreDNS。具體操作,請(qǐng)參見(jiàn)檢查業(yè)務(wù)Pod的DNS配置。
如果沒(méi)有接入CoreDNS,則考慮是客戶端負(fù)載原因或Conntrack表滿導(dǎo)致解析失敗。具體操作,請(qǐng)參見(jiàn)客戶端負(fù)載原因?qū)е陆馕鍪?/a>和Conntrack表滿。
如果接入了CoreDNS,則按以下步驟排查。
通過(guò)檢查CoreDNS Pod運(yùn)行狀態(tài)進(jìn)行診斷。具體操作,請(qǐng)參見(jiàn)檢查CoreDNS Pod運(yùn)行狀態(tài)和CoreDNS Pod運(yùn)行狀態(tài)異常。
通過(guò)檢查CoreDNS運(yùn)行日志進(jìn)行診斷。具體操作,請(qǐng)參見(jiàn)檢查CoreDNS運(yùn)行日志和集群外部域名解析異常。
確認(rèn)異常是否能夠穩(wěn)定復(fù)現(xiàn)。
如果異常穩(wěn)定復(fù)現(xiàn),請(qǐng)參見(jiàn)檢查CoreDNS DNS查詢請(qǐng)求日志和檢查業(yè)務(wù)Pod到CoreDNS的網(wǎng)絡(luò)連通性。
如果異常不能穩(wěn)定復(fù)現(xiàn),請(qǐng)參見(jiàn)抓包。
如果使用了NodeLocal DNSCache,請(qǐng)參見(jiàn)NodeLocal DNSCache未生效和PrivateZone域名解析異常。
如果以上排查無(wú)果,請(qǐng)提交工單排查。
常見(jiàn)客戶端報(bào)錯(cuò)
客戶端 | 報(bào)錯(cuò)日志 | 可能異常 |
ping |
| 域名不存在或無(wú)法連接域名服務(wù)器。如果解析延遲大于5秒,一般是無(wú)法連接域名服務(wù)器。 |
curl |
| |
PHP HTTP客戶端 |
| |
Golang HTTP客戶端 |
| 域名不存在。 |
dig |
| |
Golang HTTP客戶端 |
| 無(wú)法連接域名服務(wù)器。 |
dig |
|
排查思路
排查思路 | 排查依據(jù) | 問(wèn)題及解決方案 |
按解析異常的域名類(lèi)型排查 | 集群內(nèi)外域名都異常 | |
僅集群外部域名異常 | ||
僅PrivateZone 、vpc-proxy域名解析異常 | ||
僅Headless類(lèi)型服務(wù)域名異常 | ||
按解析異常出現(xiàn)頻次排查 | 完全無(wú)法解析 | |
異常僅出現(xiàn)在業(yè)務(wù)高峰時(shí)期 | ||
異常出現(xiàn)頻次非常高 | ||
異常出現(xiàn)頻次非常低 | ||
異常僅出現(xiàn)在節(jié)點(diǎn)擴(kuò)縮容或CoreDNS縮容時(shí) |
常見(jiàn)檢查方法
檢查業(yè)務(wù)Pod的DNS配置
命令
#查看foo容器的YAML配置,并確認(rèn)DNSPolicy字段是否符合預(yù)期。 kubectl get pod foo -o yaml #當(dāng)DNSPolicy符合預(yù)期時(shí),可以進(jìn)一步進(jìn)入Pod容器中,查看實(shí)際生效的DNS配置。 #通過(guò)bash命令進(jìn)入foo容器,若bash不存在可使用sh代替。 kubectl exec -it foo bash #進(jìn)入容器后,可以查看DNS配置,nameserver后面為DNS服務(wù)器地址。 cat /etc/resolv.conf
DNS Policy配置說(shuō)明
DNS Policy示例如下所示。
apiVersion: v1 kind: Pod metadata: name: <pod-name> namespace: <pod-namespace> spec: containers: - image: <container-image> name: <container-name> #默認(rèn)場(chǎng)景下的DNS Policy。 dnsPolicy: ClusterFirst #使用了NodeLocal DNSCache時(shí)的DNS Policy。 dnsPolicy: None dnsConfig: nameservers: - 169.254.20.10 - 172.21.0.10 options: - name: ndots value: "3" - name: timeout value: "1" - name: attempts value: "2" searches: - default.svc.cluster.local - svc.cluster.local - cluster.local securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 30
DNSPolicy字段值
使用的DNS服務(wù)器
Default
只適用于不需要訪問(wèn)集群內(nèi)部服務(wù)的場(chǎng)景。Pod創(chuàng)建時(shí)會(huì)從ECS節(jié)點(diǎn)/etc/resolv.conf文件繼承DNS服務(wù)器列表。
ClusterFirst
此為DNSPolicy默認(rèn)值,Pod會(huì)將CoreDNS提供的kube-dns服務(wù)IP作為DNS服務(wù)器。開(kāi)啟HostNetwork的Pod,如果選擇ClusterFirst模式,效果等同于Default模式。
ClusterFirstWithHostNet
開(kāi)啟HostNetwork的Pod,如果選擇ClusterFirstWithHostNet模式,效果等同于ClusterFirst。
None
配合DNSConfig字段,可用于自定義DNS服務(wù)器和參數(shù)。在NodeLocal DNSCache開(kāi)啟注入時(shí),DNSConfig會(huì)將DNS服務(wù)器指向本地緩存IP及CoreDNS提供的kube-dns服務(wù)IP。
檢查CoreDNS Pod運(yùn)行狀態(tài)
命令
執(zhí)行以下命令,查看容器組信息。
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns
預(yù)期輸出:
NAME READY STATUS RESTARTS AGE IP NODE coredns-xxxxxxxxx-xxxxx 1/1 Running 0 25h 172.20.6.53 cn-hangzhou.192.168.0.198
執(zhí)行以下命令,查看Pod的實(shí)時(shí)資源使用情況。
kubectl -n kube-system top pod -l k8s-app=kube-dns
預(yù)期輸出:
NAME CPU(cores) MEMORY(bytes) coredns-xxxxxxxxx-xxxxx 3m 18Mi
如果Pod不處于Running狀態(tài),可以通過(guò)
kubectl -n kube-system describe pod <CoreDNS Pod名稱>
命令,查詢問(wèn)題原因。
檢查CoreDNS運(yùn)行日志
命令
執(zhí)行以下命令,檢查CoreDNS運(yùn)行日志。
kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx
參數(shù) | 描述 |
| 持續(xù)輸出。 |
| 輸出最后500行日志。 |
| 同時(shí)顯示日志打印的時(shí)間。 |
| CoreDNS Pod副本的名稱。 |
檢查CoreDNS DNS查詢請(qǐng)求日志
命令
DNS查詢請(qǐng)求日志僅會(huì)在開(kāi)啟CoreDNS的Log插件后,才會(huì)打印到容器日志中。關(guān)于開(kāi)啟Log插件的具體操作,請(qǐng)參見(jiàn)CoreDNS配置說(shuō)明。
命令與檢查CoreDNS運(yùn)行日志相同,請(qǐng)參見(jiàn)檢查CoreDNS運(yùn)行日志。
檢查CoreDNS Pod的網(wǎng)絡(luò)連通性
操作步驟
登錄CoreDNS Pod所在集群節(jié)點(diǎn)。
執(zhí)行
ps aux | grep coredns
,查詢CoreDNS的進(jìn)程ID。執(zhí)行
nsenter -t <pid> -n bash
,進(jìn)入CoreDNS所在容器網(wǎng)絡(luò)命名空間,其中pid
為上一步得到的進(jìn)程ID。測(cè)試網(wǎng)絡(luò)連通性。
運(yùn)行
telnet <apiserver_clusterip> 6443
,測(cè)試Kubernetes API Server的連通性。其中
apiserver_clusterip為default命名空間下Kubernetes服務(wù)的IP地址。
運(yùn)行
dig <domain> @<upstream_dns_server_ip>
,測(cè)試CoreDNS Pod到上游DNS服務(wù)器的連通性。其中
domain
為測(cè)試域名,upstream_dns_server_ip
為上游DNS服務(wù)器地址,默認(rèn)為100.100.2.136和100.100.2.138。
常見(jiàn)問(wèn)題
現(xiàn)象 | 原因 | 處理方案 |
CoreDNS無(wú)法連通Kubernetes API Server | APIServer異常、機(jī)器負(fù)載高、kube-proxy 沒(méi)有正常運(yùn)行等。 | 可提交工單排查。 |
CoreDNS無(wú)法連通上游DNS服務(wù)器 | 機(jī)器負(fù)載高、CoreDNS配置錯(cuò)誤、專線路由問(wèn)題等。 | 可提交工單排查。 |
檢查業(yè)務(wù)Pod到CoreDNS的網(wǎng)絡(luò)連通性
操作步驟
選擇以下任意一種方式,進(jìn)入客戶端Pod容器網(wǎng)絡(luò)。
方法一:使用
kubectl exec
命令。方法二:
登錄業(yè)務(wù)Pod所在集群節(jié)點(diǎn)。
執(zhí)行
ps aux | grep <業(yè)務(wù)進(jìn)程名>
命令,查詢業(yè)務(wù)容器的進(jìn)程ID。執(zhí)行
nsenter -t <pid> -n bash
命令,進(jìn)入業(yè)務(wù)Pod所在容器網(wǎng)絡(luò)命名空間。其中
pid
為上一步得到的進(jìn)程ID。
方法三:如果頻繁重啟,請(qǐng)按以下步驟操作。
登錄業(yè)務(wù)Pod所在集群節(jié)點(diǎn)。
執(zhí)行
docker ps -a | grep <業(yè)務(wù)容器名>
命令,查詢k8s_POD_
開(kāi)頭的沙箱容器,記錄容器ID。執(zhí)行
docker inspect <沙箱容器 ID> | grep netns
命令,查詢/var/run/docker/netns/xxxx的容器網(wǎng)絡(luò)命名空間路徑。執(zhí)行
nsenter -n<netns 路徑> bash
命令,進(jìn)入容器網(wǎng)絡(luò)命名空間。其中
netns 路徑
為上一步得到的路徑。說(shuō)明-n
和<netns 路徑>
之間不加空格。
測(cè)試網(wǎng)絡(luò)連通性。
執(zhí)行
dig <domain> @<kube_dns_svc_ip>
命令,測(cè)試業(yè)務(wù)Pod到CoreDNS服務(wù)kube-dns解析查詢的連通性。其中
<domain>
為測(cè)試域名,<kube_dns_svc_ip>
為kube-system命名空間中kube-dns的服務(wù)IP。執(zhí)行
ping <coredns_pod_ip>
命令,測(cè)試業(yè)務(wù)Pod到CoreDNS容器副本的連通性。其中
<coredns_pod_ip>
為kube-system命名空間中CoreDNS Pod的IP。執(zhí)行
dig <domain> @<coredns_pod_ip>
命令,測(cè)試業(yè)務(wù)Pod到CoreDNS容器副本解析查詢的連通性。其中
<domain>
為測(cè)試域名,<coredns_pod_ip>
為kube-system命名空間中CoreDNS Pod的IP。
常見(jiàn)問(wèn)題
現(xiàn)象 | 原因 | 處理方案 |
業(yè)務(wù)Pod無(wú)法通過(guò)CoreDNS服務(wù)kube-dns解析 | 機(jī)器負(fù)載高、kube-proxy沒(méi)有正常運(yùn)行、安全組沒(méi)有放開(kāi)UDP協(xié)議53端口等。 | 檢查安全組是否放開(kāi)UDP 53端口,若已放開(kāi)請(qǐng)提交工單排查。 |
業(yè)務(wù)Pod無(wú)法連通CoreDNS容器副本 | 容器網(wǎng)絡(luò)異常或安全組沒(méi)有放開(kāi)ICMP。 | 檢查安全組是否放開(kāi)ICMP,若已放開(kāi)請(qǐng)提交工單排查。 |
業(yè)務(wù)Pod無(wú)法通過(guò)CoreDNS容器副本解析 | 機(jī)器負(fù)載高、安全組沒(méi)有放開(kāi)UDP協(xié)議53端口等。 | 檢查安全組是否放開(kāi)UDP 53端口,若已放開(kāi)請(qǐng)提交工單排查。 |
抓包
當(dāng)無(wú)法定位問(wèn)題時(shí),需要抓包進(jìn)行輔助診斷。
登錄出現(xiàn)異常的業(yè)務(wù)Pod、CoreDNS Pod所在節(jié)點(diǎn)。
在ECS(非容器內(nèi))執(zhí)行以下命令,可以將最近所有的53端口信息抓取到文件中。
tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap
結(jié)合業(yè)務(wù)日志的報(bào)錯(cuò)定位到精準(zhǔn)的報(bào)錯(cuò)時(shí)間的報(bào)文信息。
說(shuō)明在正常情況下,抓包對(duì)業(yè)務(wù)無(wú)影響,僅會(huì)增加小部分的CPU負(fù)載和磁盤(pán)寫(xiě)入。
以上命令會(huì)對(duì)抓取到的包進(jìn)行rotate,最多可以寫(xiě)200個(gè)20 MB的.pcap文件。
集群外部域名解析異常
問(wèn)題現(xiàn)象
業(yè)務(wù)Pod可以正常解析集群內(nèi)部域名,但無(wú)法解析某些集群外部域名。
問(wèn)題原因
上游服務(wù)器域名解析返回異常。
解決方案
檢查CoreDNS DNS查詢請(qǐng)求日志。
常見(jiàn)請(qǐng)求日志
CoreDNS接收到請(qǐng)求并回復(fù)客戶端后會(huì)打印一行日志,示例如下:
# 其中包含狀態(tài)碼RCODE NOERROR,代表解析結(jié)果正常返回。
[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s
常見(jiàn)返回碼RCODE
關(guān)于返回碼RCODE定義的具體信息,請(qǐng)參見(jiàn)規(guī)范。
返回碼RCODE | 含義 | 原因 |
NXDOMAIN | 域名不存在 | 容器內(nèi)請(qǐng)求域名時(shí),會(huì)被拼接上search后綴,若拼接的結(jié)果域名不存在,則會(huì)出現(xiàn)該請(qǐng)求碼。如果確認(rèn)日志中請(qǐng)求的域名內(nèi)容存在,則說(shuō)明存在異常。 |
SERVFAIL | 上游服務(wù)器異常 | 常見(jiàn)于無(wú)法連接上游DNS服務(wù)器等情況。 |
REFUSED | 拒絕應(yīng)答 | 常見(jiàn)于CoreDNS配置或集群節(jié)點(diǎn)/etc/resolv.conf文件指向的上游DNS服務(wù)器無(wú)法處理該域名的情況,請(qǐng)排查CoreDNS配置文件。 |
當(dāng)CoreDNS DNS查詢請(qǐng)求日志中顯示集群外部域名返回為NXDOMAIN
、SERVFAIL
、REFUSED
時(shí),說(shuō)明CoreDNS的上游DNS服務(wù)器返回異常。
默認(rèn)情況下,集群中CoreDNS的上游DNS服務(wù)器是VPC提供的DNS服務(wù)器(100.100.2.136 和 100.100.2.138)。您可以提交工單至云服務(wù)器ECS產(chǎn)品。提交工單時(shí)請(qǐng)注明以下信息。
字段 | 含義 | 示例 |
受損域名 | CoreDNS日志中返回碼RCODE異常的集群外部域名 | www.aliyun.com |
解析返回碼RCODE | 具體解析報(bào)錯(cuò)(NXDOMAIN、SERVFAIL、REFUSED) | NXDOMAIN |
受損時(shí)間 | 日志出現(xiàn)的時(shí)間(精確到秒) | 2022-12-22 20:00:03 |
受損ECS | CoreDNS各副本Pod所處的ECS實(shí)例ID | i-xxxxx i-yyyyy |
新增Headless類(lèi)型域名無(wú)法解析
問(wèn)題現(xiàn)象
接入CoreDNS的業(yè)務(wù)Pod無(wú)法解析新增的Headless類(lèi)型域名。
問(wèn)題原因
1.7.0以前版本CoreDNS會(huì)在API Server抖動(dòng)時(shí)異常退出,導(dǎo)致Headless域名停止更新。
解決方案
升級(jí)CoreDNS至1.7.0以上。具體操作,請(qǐng)參見(jiàn)【組件升級(jí)】CoreDNS升級(jí)公告。
升級(jí)CoreDNS后Headless類(lèi)型域名無(wú)法解析
問(wèn)題現(xiàn)象
部分較低版本開(kāi)源組件(低版本etcd、nacos、kafka等)在K8s 1.20及以上版本和 CoreDNS 1.8.4及以上版本的環(huán)境中無(wú)法正常工作。
問(wèn)題原因
1.8.4及以上版本的CoreDNS優(yōu)先使用EndpointSlice API同步K8s內(nèi)服務(wù)IP信息。一些開(kāi)源組件在初始化階段會(huì)使用Endpoint API 提供的注解service.alpha.kubernetes.io/tolerate-unready-endpoints
來(lái)發(fā)布尚未就緒的服務(wù)。該注解在EndpointSlice API中已經(jīng)廢棄,并被publishNotReadyAddresses
所替代。因此CoreDNS升級(jí)后,無(wú)法發(fā)布未就緒的服務(wù),導(dǎo)致這些組件無(wú)法進(jìn)行服務(wù)發(fā)現(xiàn)。
解決方案
檢查開(kāi)源組件的YAML或Helm Chart中是否包含service.alpha.kubernetes.io/tolerate-unready-endpoints
注解,如果包含則可能無(wú)法正常工作,您需要升級(jí)開(kāi)源組件或咨詢開(kāi)源組件社區(qū)。
StatefulSets Pod域名無(wú)法解析
問(wèn)題現(xiàn)象
Headless服務(wù)無(wú)法通過(guò)Pod域名解析。
問(wèn)題原因
StatefulSets Pod YAML中ServiceName必須和其暴露SVC的名字一致,否則無(wú)法訪問(wèn)Pod域名(例如pod.headless-svc.ns.svc.cluster.local),只能訪問(wèn)到服務(wù)域名(例如headless-svc.ns.svc.cluster.local)。
解決方案
修改StatefulSets Pod YAML中ServiceName名稱。
安全組、交換機(jī)ACL配置錯(cuò)誤
問(wèn)題現(xiàn)象
部分節(jié)點(diǎn)或全部節(jié)點(diǎn)上接入CoreDNS的業(yè)務(wù),Pod解析域名持續(xù)性失敗。
問(wèn)題原因
修改了ECS或容器使用的安全組(或交換機(jī)ACL),攔截了UDP協(xié)議下53端口的通信。
解決方案
恢復(fù)安全組、交換機(jī)ACL的配置,放開(kāi)其以UDP協(xié)議對(duì)53端口的通信。
容器網(wǎng)絡(luò)連通性異常
問(wèn)題現(xiàn)象
部分節(jié)點(diǎn)或全部節(jié)點(diǎn)上接入CoreDNS的業(yè)務(wù),Pod解析域名持續(xù)性失敗。
問(wèn)題原因
由于容器網(wǎng)絡(luò)或其它原因?qū)е碌腢DP協(xié)議53端口持續(xù)性不通。
解決方案
請(qǐng)提交工單排查。
CoreDNS Pod負(fù)載高
問(wèn)題現(xiàn)象
部分節(jié)點(diǎn)或全部節(jié)點(diǎn)接入CoreDNS的業(yè)務(wù),Pod解析域名的延遲增加、概率性或持續(xù)性失敗。
檢查CoreDNS Pod運(yùn)行狀態(tài)發(fā)現(xiàn)各副本CPU、Memory使用量接近其資源限制。
問(wèn)題原因
由于CoreDNS副本數(shù)不足、業(yè)務(wù)請(qǐng)求量高等情況導(dǎo)致的CoreDNS負(fù)載高。
解決方案
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負(fù)載。具體操作,請(qǐng)參見(jiàn)使用NodeLocal DNSCache。
適當(dāng)擴(kuò)充CoreDNS副本數(shù),使每個(gè)Pod的峰值CPU始終低于節(jié)點(diǎn)空閑CPU數(shù)。
CoreDNS Pod負(fù)載不均
問(wèn)題現(xiàn)象
部分接入CoreDNS的業(yè)務(wù)Pod解析域名的延遲增加、概率性或持續(xù)性失敗。
檢查CoreDNS Pod運(yùn)行狀態(tài)發(fā)現(xiàn)各副本CPU使用量負(fù)載不均衡。
CoreDNS副本數(shù)少于兩個(gè),或多個(gè)CoreDNS副本位于同節(jié)點(diǎn)上。
問(wèn)題原因
由于CoreDNS副本調(diào)度不均、Service親和性設(shè)置導(dǎo)致CoreDNS Pod負(fù)載不均衡。
解決方案
擴(kuò)容并打散CoreDNS副本到不同的節(jié)點(diǎn)上。
負(fù)載不均衡時(shí),可禁用kube-dns服務(wù)的親和性屬性。具體操作,請(qǐng)參見(jiàn)配置Kube-DNS服務(wù)。
CoreDNS Pod運(yùn)行狀態(tài)異常
問(wèn)題現(xiàn)象
部分接入CoreDNS的業(yè)務(wù)Pod解析域名的延遲增加、概率性或持續(xù)性失敗。
CoreDNS副本狀態(tài)Status不處于Running狀態(tài),或重啟次數(shù)RESTARTS持續(xù)增加。
CoreDNS運(yùn)行日志中出現(xiàn)異常。
問(wèn)題原因
由于CoreDNS YAML模板、配置文件等導(dǎo)致CoreDNS運(yùn)行異常。
解決方案
檢查CoreDNS Pod運(yùn)行狀態(tài)和運(yùn)行日志。
常見(jiàn)異常日志及處理方案
日志中字樣 | 原因 | 處理方案 |
| 配置文件和CoreDNS不兼容, | 從kube-system命名空間中CoreDNS配置項(xiàng)中刪除ready插件,其它報(bào)錯(cuò)同理。 |
| 日志出現(xiàn)時(shí)間段內(nèi),API Server中斷。 | 如果是日志出現(xiàn)時(shí)間和異常不吻合,可以排除該原因,否則請(qǐng)檢查CoreDNS Pod網(wǎng)絡(luò)連通性。具體操作,請(qǐng)參見(jiàn)檢查CoreDNS Pod的網(wǎng)絡(luò)連通性。 |
| 日志出現(xiàn)時(shí)間段內(nèi),CoreDNS無(wú)法連接到上游DNS服務(wù)器。 |
客戶端負(fù)載原因?qū)е陆馕鍪?/h2>問(wèn)題現(xiàn)象
業(yè)務(wù)高峰期間或突然偶發(fā)的解析失敗,ECS監(jiān)控顯示機(jī)器網(wǎng)卡重傳率、CPU負(fù)載有異常。
問(wèn)題原因
接入CoreDNS的業(yè)務(wù)Pod所在ECS負(fù)載達(dá)到100%等情況導(dǎo)致UDP報(bào)文丟失。
解決方案
建議提交工單排查原因。
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負(fù)載。具體操作,請(qǐng)參見(jiàn)使用NodeLocal DNSCache。
Conntrack表滿
問(wèn)題現(xiàn)象
部分節(jié)點(diǎn)或全部節(jié)點(diǎn)上接入CoreDNS的業(yè)務(wù),Pod解析域名在業(yè)務(wù)高峰時(shí)間段內(nèi)出現(xiàn)大批量域名解析失敗,高峰結(jié)束后失敗消失。
運(yùn)行
dmesg -H
,滾動(dòng)到問(wèn)題對(duì)應(yīng)時(shí)段的日志,發(fā)現(xiàn)出現(xiàn)conntrack full
字樣的報(bào)錯(cuò)信息。
問(wèn)題原因
Linux內(nèi)Conntrack表?xiàng)l目有限,無(wú)法進(jìn)行新的UDP或TCP請(qǐng)求。
解決方案
增加Conntrack表限制。具體操作,請(qǐng)參見(jiàn)如何提升Linux連接跟蹤C(jī)onntrack數(shù)量限制?。
AutoPath插件異常
問(wèn)題現(xiàn)象
解析集群外部域名時(shí),概率性解析失敗或解析到錯(cuò)誤的IP地址,解析集群內(nèi)部域名無(wú)異常。
高頻創(chuàng)建容器時(shí),集群內(nèi)部服務(wù)域名解析到錯(cuò)誤的IP地址。
問(wèn)題原因
CoreDNS處理缺陷導(dǎo)致AutoPath無(wú)法正常工作。
解決方案
按照以下步驟,關(guān)閉AutoPath插件。
執(zhí)行
kubectl -n kube-system edit configmap coredns
命令,打開(kāi)CoreDNS配置文件。刪除
autopath @kubernetes
一行后保存退出。檢查CoreDNS Pod運(yùn)行狀態(tài)和運(yùn)行日志,運(yùn)行日志中出現(xiàn)
reload
字樣后說(shuō)明修改成功。
A記錄和AAAA記錄并發(fā)解析異常
問(wèn)題現(xiàn)象
接入CoreDNS的業(yè)務(wù)Pod解析域名概率性失敗。
從抓包或檢查CoreDNS DNS查詢請(qǐng)求日志可以發(fā)現(xiàn),A和AAAA通常在同一時(shí)間的出現(xiàn),并且請(qǐng)求的源端口一致。
問(wèn)題原因
并發(fā)A和AAAA的DNS請(qǐng)求觸發(fā)Linux內(nèi)核Conntrack模塊缺陷,導(dǎo)致UDP報(bào)文丟失。
解決方案
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負(fù)載。具體操作,請(qǐng)參見(jiàn)使用NodeLocal DNSCache。
CentOS、Ubuntu等基礎(chǔ)鏡像,可以通過(guò)
options timeout:2 attempts:3 rotate single-request-reopen
等參數(shù)優(yōu)化。如果容器鏡像是以Alpine制作的,建議更換基礎(chǔ)鏡像。更多信息,請(qǐng)參見(jiàn)Alpine。
PHP類(lèi)應(yīng)用短連接解析問(wèn)題較多,如果使用的是PHP Curl的調(diào)用,可以使用
CURL_IPRESOLVE_V4
參數(shù)僅發(fā)送IPv4解析。更多信息,請(qǐng)參見(jiàn)函數(shù)說(shuō)明。
IPVS缺陷導(dǎo)致解析異常
問(wèn)題現(xiàn)象
當(dāng)集群節(jié)點(diǎn)擴(kuò)縮容、節(jié)點(diǎn)關(guān)機(jī)、CoreDNS縮容時(shí),出現(xiàn)概率性解析失敗,通常時(shí)長(zhǎng)在五分鐘左右。
問(wèn)題原因
若您集群的kube-proxy負(fù)載均衡模式為IPVS,在CentOS、Alibaba Cloud Linux 2內(nèi)核版本小于4.19.91-25.1.al7.x86_64的節(jié)點(diǎn)上,摘除IPVS UDP類(lèi)型后端后,一段時(shí)間內(nèi)若新發(fā)起的UDP報(bào)文源端口沖突,該報(bào)文會(huì)被丟棄。
解決方案
考慮采用NodeLocal DNSCache緩存方案,可以容忍IPVS丟包。具體操作,請(qǐng)參見(jiàn)使用NodeLocal DNSCache。
優(yōu)化IPVS UDP超時(shí)時(shí)間。具體操作,請(qǐng)參見(jiàn)配置IPVS類(lèi)型集群的UDP超時(shí)時(shí)間。
NodeLocal DNSCache未生效
問(wèn)題現(xiàn)象
NodeLocal DNSCache沒(méi)有流量進(jìn)入,所有請(qǐng)求仍在CoreDNS上。
問(wèn)題原因
未配置DNSConfig注入,業(yè)務(wù)Pod實(shí)際仍配置了CoreDNS kube-dns服務(wù)IP作為DNS服務(wù)器地址。
業(yè)務(wù)Pod采用Alpine作為基礎(chǔ)鏡像,Alpine基礎(chǔ)鏡像會(huì)并發(fā)請(qǐng)求所有nameserver,包括本地緩存和CoreDNS。
解決方案
配置DNSConfig自動(dòng)注入。具體操作,請(qǐng)參見(jiàn)使用NodeLocal DNSCache。
如果容器鏡像是以Alpine制作的,建議更換基礎(chǔ)鏡像。更多信息,請(qǐng)參見(jiàn)Alpine。
PrivateZone域名解析異常
問(wèn)題現(xiàn)象
對(duì)于接入NodeLocal DNSCache的業(yè)務(wù),Pod無(wú)法解析PrivateZone上注冊(cè)的域名,或無(wú)法解析包含vpc-proxy字樣的阿里云云產(chǎn)品API域名,或解析結(jié)果不正確。
問(wèn)題原因
PrivateZone不支持TCP協(xié)議,需要使用UDP協(xié)議訪問(wèn)。
解決方案
在CoreDNS中配置prefer_udp
。具體操作,請(qǐng)參見(jiàn)CoreDNS配置說(shuō)明。