本文介紹關于DNS解析異常的診斷流程、排查思路、常見解決方案和排查方法。
索引
類別 | 內容 |
診斷流程 | |
排查思路 | |
常見排查方法 | |
常見問題及解決方案 |
診斷流程
基本概念
集群內部域名:CoreDNS會將集群中的服務暴露為集群內部域名,默認以
.cluster.local
結尾,這類域名的解析通過CoreDNS內部緩存完成,不會從上游DNS服務器查詢。集群外部域名:在第三方DNS服務商、阿里云DNS云解析、PrivateZone等產品注冊的權威解析,這類域名由CoreDNS的上游DNS服務器負責解析,CoreDNS僅做解析請求轉發。
業務Pod:您部署在Kubernetes集群中的容器Pod,不包含Kubernetes自身系統組件的容器。
接入CoreDNS的業務Pod:容器內DNS服務器指向了CoreDNS的業務Pod。
接入NodeLocal DNSCache的業務Pod:集群中安裝了NodeLocal DNSCache插件后,通過自動或手動方式注入DNSConfig的業務Pod。這類Pod在解析域名時,會優先訪問本地緩存組件。如果訪問本地緩存組件不通時,會訪問CoreDNS提供的kube-dns服務。
異常診斷流程
判斷當前的異常原因。具體信息,請參見常見客戶端報錯。
如果以上排查無果,請按以下步驟排查。
檢查業務Pod的DNS配置,是否已經接入CoreDNS。具體操作,請參見檢查業務Pod的DNS配置。
如果沒有接入CoreDNS,則考慮是客戶端負載原因或Conntrack表滿導致解析失敗。具體操作,請參見客戶端負載原因導致解析失敗和Conntrack表滿。
如果接入了CoreDNS,則按以下步驟排查。
通過檢查CoreDNS Pod運行狀態進行診斷。具體操作,請參見檢查CoreDNS Pod運行狀態和CoreDNS Pod運行狀態異常。
通過檢查CoreDNS運行日志進行診斷。具體操作,請參見檢查CoreDNS運行日志和集群外部域名解析異常。
確認異常是否能夠穩定復現。
如果異常穩定復現,請參見檢查CoreDNS DNS查詢請求日志和檢查業務Pod到CoreDNS的網絡連通性。
如果異常不能穩定復現,請參見抓包。
如果使用了NodeLocal DNSCache,請參見NodeLocal DNSCache未生效和PrivateZone域名解析異常。
如果以上排查無果,請提交工單排查。
常見客戶端報錯
客戶端 | 報錯日志 | 可能異常 |
ping |
| 域名不存在或無法連接域名服務器。如果解析延遲大于5秒,一般是無法連接域名服務器。 |
curl |
| |
PHP HTTP客戶端 |
| |
Golang HTTP客戶端 |
| 域名不存在。 |
dig |
| |
Golang HTTP客戶端 |
| 無法連接域名服務器。 |
dig |
|
排查思路
排查思路 | 排查依據 | 問題及解決方案 |
按解析異常的域名類型排查 | 集群內外域名都異常 | |
僅集群外部域名異常 | ||
僅PrivateZone 、vpc-proxy域名解析異常 | ||
僅Headless類型服務域名異常 | ||
按解析異常出現頻次排查 | 完全無法解析 | |
異常僅出現在業務高峰時期 | ||
異常出現頻次非常高 | ||
異常出現頻次非常低 | ||
異常僅出現在節點擴縮容或CoreDNS縮容時 |
常見檢查方法
檢查業務Pod的DNS配置
命令
#查看foo容器的YAML配置,并確認DNSPolicy字段是否符合預期。 kubectl get pod foo -o yaml #當DNSPolicy符合預期時,可以進一步進入Pod容器中,查看實際生效的DNS配置。 #通過bash命令進入foo容器,若bash不存在可使用sh代替。 kubectl exec -it foo bash #進入容器后,可以查看DNS配置,nameserver后面為DNS服務器地址。 cat /etc/resolv.conf
DNS Policy配置說明
DNS Policy示例如下所示。
apiVersion: v1 kind: Pod metadata: name: <pod-name> namespace: <pod-namespace> spec: containers: - image: <container-image> name: <container-name> #默認場景下的DNS Policy。 dnsPolicy: ClusterFirst #使用了NodeLocal DNSCache時的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服務器
Default
只適用于不需要訪問集群內部服務的場景。Pod創建時會從ECS節點/etc/resolv.conf文件繼承DNS服務器列表。
ClusterFirst
此為DNSPolicy默認值,Pod會將CoreDNS提供的kube-dns服務IP作為DNS服務器。開啟HostNetwork的Pod,如果選擇ClusterFirst模式,效果等同于Default模式。
ClusterFirstWithHostNet
開啟HostNetwork的Pod,如果選擇ClusterFirstWithHostNet模式,效果等同于ClusterFirst。
None
配合DNSConfig字段,可用于自定義DNS服務器和參數。在NodeLocal DNSCache開啟注入時,DNSConfig會將DNS服務器指向本地緩存IP及CoreDNS提供的kube-dns服務IP。
檢查CoreDNS Pod運行狀態
命令
執行以下命令,查看容器組信息。
kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns
預期輸出:
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
執行以下命令,查看Pod的實時資源使用情況。
kubectl -n kube-system top pod -l k8s-app=kube-dns
預期輸出:
NAME CPU(cores) MEMORY(bytes) coredns-xxxxxxxxx-xxxxx 3m 18Mi
如果Pod不處于Running狀態,可以通過
kubectl -n kube-system describe pod <CoreDNS Pod名稱>
命令,查詢問題原因。
檢查CoreDNS運行日志
命令
執行以下命令,檢查CoreDNS運行日志。
kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx
參數 | 描述 |
| 持續輸出。 |
| 輸出最后500行日志。 |
| 同時顯示日志打印的時間。 |
| CoreDNS Pod副本的名稱。 |
檢查CoreDNS DNS查詢請求日志
命令
DNS查詢請求日志僅會在開啟CoreDNS的Log插件后,才會打印到容器日志中。關于開啟Log插件的具體操作,請參見CoreDNS配置說明。
命令與檢查CoreDNS運行日志相同,請參見檢查CoreDNS運行日志。
檢查CoreDNS Pod的網絡連通性
您可以使用控制臺或命令行方式檢查CoreDNS Pod的網絡連通性。
控制臺
您可以通過集群下提供的網絡診斷能力進行診斷。
登錄容器服務管理控制臺,在左側導航欄選擇集群。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇巡檢和診斷>故障診斷。
在故障診斷頁面,單擊網絡診斷。
在網絡診斷頁面單擊診斷,然后在訪問信息面板,根據以下內容填寫診斷參數:
源地址:輸入CoreDNS Pod的IP。
目標地址:輸入上游DNS服務器地址,默認可選100.100.2.136或100.100.2.138。
端口:
53
協議:
udp
填寫完成后仔細閱讀注意事項,選中我已知曉并同意,然后單擊發起診斷。
在診斷結果頁面,能夠查看網絡診斷結果,并且在訪問全圖區域,會呈現出本次診斷訪問鏈路的全景圖。
命令行
操作步驟
登錄CoreDNS Pod所在集群節點。
執行
ps aux | grep coredns
,查詢CoreDNS的進程ID。執行
nsenter -t <pid> -n -- <相關命令>
,進入CoreDNS所在容器網絡命名空間,其中pod
為上一步得到的coredns
進程ID。測試網絡連通性。
運行
telnet <apiserver_clusterip> 6443
,測試Kubernetes API Server的連通性。其中
apiserver_clusterip為default命名空間下Kubernetes服務的IP地址。
運行
dig <domain> @<upstream_dns_server_ip>
,測試CoreDNS Pod到上游DNS服務器的連通性。其中
domain
為測試域名,upstream_dns_server_ip
為上游DNS服務器地址,默認為100.100.2.136和100.100.2.138。
常見問題
現象 | 原因 | 處理方案 |
CoreDNS無法連通Kubernetes API Server | APIServer異常、機器負載高、kube-proxy 沒有正常運行等。 | 可提交工單排查。 |
CoreDNS無法連通上游DNS服務器 | 機器負載高、CoreDNS配置錯誤、專線路由問題等。 | 可提交工單排查。 |
檢查業務Pod到CoreDNS的網絡連通性
您可以使用控制臺或命令行方式檢查業務Pod到CoreDNS的網絡連通性。
控制臺
登錄容器服務管理控制臺,在左側導航欄選擇集群。
在集群列表頁面,單擊目標集群名稱,然后在左側導航欄,選擇巡檢和診斷>故障診斷。
在故障診斷頁面,單擊網絡診斷。
在網絡診斷頁面單擊診斷,然后在訪問信息面板,根據以下內容填寫診斷參數:
源地址:輸入業務Pod的IP。
目標地址:輸入CoreDNS實例的PodIP或者ClusterIP。
端口:
53
協議:
udp
填寫完成后仔細閱讀注意事項,選中我已知曉并同意,然后單擊發起診斷。
在診斷結果頁面,能夠查看網絡診斷結果,并且在訪問全圖區域,會呈現出本次診斷訪問鏈路的全景圖。
命令行
操作步驟
選擇以下任意一種方式,進入客戶端Pod容器網絡。
方法一:使用
kubectl exec
命令。方法二:
登錄業務Pod所在集群節點。
執行
ps aux | grep <業務進程名>
命令,查詢業務容器的進程ID。執行
nsenter -t <pid> -n bash
命令,進入業務Pod所在容器網絡命名空間。其中
pid
為上一步得到的進程ID。
方法三:如果頻繁重啟,請按以下步驟操作。
登錄業務Pod所在集群節點。
執行
docker ps -a | grep <業務容器名>
命令,查詢k8s_POD_
開頭的沙箱容器,記錄容器ID。執行
docker inspect <沙箱容器 ID> | grep netns
命令,查詢/var/run/docker/netns/xxxx的容器網絡命名空間路徑。執行
nsenter -n<netns 路徑> bash
命令,進入容器網絡命名空間。其中
netns 路徑
為上一步得到的路徑。說明-n
和<netns 路徑>
之間不加空格。
測試網絡連通性。
執行
dig <domain> @<kube_dns_svc_ip>
命令,測試業務Pod到CoreDNS服務kube-dns解析查詢的連通性。其中
<domain>
為測試域名,<kube_dns_svc_ip>
為kube-system命名空間中kube-dns的服務IP。執行
ping <coredns_pod_ip>
命令,測試業務Pod到CoreDNS容器副本的連通性。其中
<coredns_pod_ip>
為kube-system命名空間中CoreDNS Pod的IP。執行
dig <domain> @<coredns_pod_ip>
命令,測試業務Pod到CoreDNS容器副本解析查詢的連通性。其中
<domain>
為測試域名,<coredns_pod_ip>
為kube-system命名空間中CoreDNS Pod的IP。
常見問題
現象 | 原因 | 處理方案 |
業務Pod無法通過CoreDNS服務kube-dns解析 | 機器負載高、kube-proxy沒有正常運行、安全組沒有放開UDP協議53端口等。 | 檢查安全組是否放開UDP 53端口,若已放開請提交工單排查。 |
業務Pod無法連通CoreDNS容器副本 | 容器網絡異?;虬踩M沒有放開ICMP。 | 檢查安全組是否放開ICMP,若已放開請提交工單排查。 |
業務Pod無法通過CoreDNS容器副本解析 | 機器負載高、安全組沒有放開UDP協議53端口等。 | 檢查安全組是否放開UDP 53端口,若已放開請提交工單排查。 |
抓包
當無法定位問題時,需要抓包進行輔助診斷。
登錄出現異常的業務Pod、CoreDNS Pod所在節點。
在ECS(非容器內)執行以下命令,可以將最近所有的53端口信息抓取到文件中。
tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap
結合業務日志的報錯定位到精準的報錯時間的報文信息。
說明在正常情況下,抓包對業務無影響,僅會增加小部分的CPU負載和磁盤寫入。
以上命令會對抓取到的包進行rotate,最多可以寫200個20MB的.pcap文件。
集群外部域名解析異常
問題現象
業務Pod可以正常解析集群內部域名,但無法解析某些集群外部域名。
問題原因
上游服務器域名解析返回異常。
解決方案
檢查CoreDNS DNS查詢請求日志。
常見請求日志
CoreDNS接收到請求并回復客戶端后會打印一行日志,示例如下:
# 其中包含狀態碼RCODE NOERROR,代表解析結果正常返回。
[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
常見返回碼RCODE
關于返回碼RCODE定義的具體信息,請參見規范。
返回碼RCODE | 含義 | 原因 |
NXDOMAIN | 域名不存在 | 容器內請求域名時,會被拼接上search后綴,若拼接的結果域名不存在,則會出現該請求碼。如果確認日志中請求的域名內容存在,則說明存在異常。 |
SERVFAIL | 上游服務器異常 | 常見于無法連接上游DNS服務器等情況。 |
REFUSED | 拒絕應答 | 常見于CoreDNS配置或集群節點/etc/resolv.conf文件指向的上游DNS服務器無法處理該域名的情況,請排查CoreDNS配置文件。 |
當CoreDNS DNS查詢請求日志中顯示集群外部域名返回為NXDOMAIN
、SERVFAIL
、REFUSED
時,說明CoreDNS的上游DNS服務器返回異常。
默認情況下,集群中CoreDNS的上游DNS服務器是VPC提供的DNS服務器(100.100.2.136 和 100.100.2.138)。您可以提交工單至云服務器ECS產品。提交工單時請注明以下信息。
字段 | 含義 | 示例 |
受損域名 | CoreDNS日志中返回碼RCODE異常的集群外部域名 | www.aliyun.com |
解析返回碼RCODE | 具體解析報錯(NXDOMAIN、SERVFAIL、REFUSED) | NXDOMAIN |
受損時間 | 日志出現的時間(精確到秒) | 2022-12-22 20:00:03 |
受損ECS | CoreDNS各副本Pod所處的ECS實例ID | i-xxxxx i-yyyyy |
新增Headless類型域名無法解析
問題現象
接入CoreDNS的業務Pod無法解析新增的Headless類型域名。
問題原因
1.7.0以前版本CoreDNS會在API Server抖動時異常退出,導致Headless域名停止更新。
解決方案
升級CoreDNS至1.7.0以上。具體操作,請參見【組件升級】CoreDNS升級公告。
Headless類型域名解析失敗
問題現象
接入CoreDNS的業務Pod無法解析Headless類型的域名。使用dig
解析時,返回中顯示tc
標志,表示響應消息過大。
問題原因
當Headless類型的域名對應的IP條目數量過多時,客戶端通過UDP方式發送DNS請求可能會超出UDP DNS報文的大小限制,導致解析失敗。
解決方案
為了避免解析失敗,您可以將客戶端業務調整為使用TCP方式進行DNS查詢。CoreDNS同時支持TCP和 UDP查詢,以下是根據不同業務場景的修改方式:
使用glibc相關的解析器。
如果您的客戶端業務使用的是glibc相關的Resolve解析器,可以在
dnsConfig
中增加use-vc
配置使用TCP進行DNS查詢。這些設置將在/etc/resolv.conf
中的映射到相應的options
配置。關于options
配置詳細說明請參見Linux man pages。dnsConfig: options: - name: use-vc
Golang實現的業務代碼邏輯
如果您使用Golang進行開發,可以參考以下代碼,使用TCP進行DNS查詢。
package main import ( "fmt" "net" "context" ) func main() { resolver := &net.Resolver{ PreferGo: true, Dial: func(ctx context.Context, network, address string) (net.Conn, error) { return net.Dial("tcp", address) }, } addrs, err := resolver.LookupHost(context.TODO(), "example.com") if err != nil { fmt.Println("Error:", err) return } fmt.Println("Addresses:", addrs) }
升級CoreDNS后Headless類型域名無法解析
問題現象
部分較低版本開源組件(低版本etcd、nacos、kafka等)在K8s 1.20及以上版本和 CoreDNS 1.8.4及以上版本的環境中無法正常工作。
問題原因
1.8.4及以上版本的CoreDNS優先使用EndpointSlice API同步K8s內服務IP信息。一些開源組件在初始化階段會使用Endpoint API 提供的注解service.alpha.kubernetes.io/tolerate-unready-endpoints
來發布尚未就緒的服務。該注解在EndpointSlice API中已經廢棄,并被publishNotReadyAddresses
所替代。因此CoreDNS升級后,無法發布未就緒的服務,導致這些組件無法進行服務發現。
解決方案
檢查開源組件的YAML或Helm Chart中是否包含service.alpha.kubernetes.io/tolerate-unready-endpoints
注解,如果包含則可能無法正常工作,您需要升級開源組件或咨詢開源組件社區。
StatefulSets Pod域名無法解析
問題現象
Headless服務無法通過Pod域名解析。
問題原因
StatefulSets Pod YAML中ServiceName必須和其暴露的SVC名字一致,否則無法訪問Pod域名(例如pod.headless-svc.ns.svc.cluster.local),只能訪問到服務域名(例如headless-svc.ns.svc.cluster.local)。
解決方案
修改StatefulSets Pod YAML中ServiceName名稱。
安全組、交換機ACL配置錯誤
問題現象
部分節點或全部節點上接入CoreDNS的業務,Pod解析域名持續性失敗。
問題原因
修改了ECS或容器使用的安全組(或交換機ACL),攔截了UDP協議下53端口的通信。
解決方案
恢復安全組、交換機ACL的配置,放開其以UDP協議對53端口的通信。
容器網絡連通性異常
問題現象
部分節點或全部節點上接入CoreDNS的業務,Pod解析域名持續性失敗。
問題原因
由于容器網絡或其它原因導致的UDP協議53端口持續性不通。
解決方案
CoreDNS Pod負載高
問題現象
部分節點或全部節點接入CoreDNS的業務,Pod解析域名的延遲增加、概率性或持續性失敗。
檢查CoreDNS Pod運行狀態發現各副本CPU、Memory使用量接近其資源限制。
問題原因
由于CoreDNS副本數不足、業務請求量高等情況導致的CoreDNS負載高。
解決方案
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負載。具體操作,請參見使用NodeLocal DNSCache。
適當擴充CoreDNS副本數,使每個Pod的峰值CPU始終低于節點空閑CPU數。
CoreDNS Pod負載不均
問題現象
部分接入CoreDNS的業務Pod解析域名的延遲增加、概率性或持續性失敗。
檢查CoreDNS Pod運行狀態發現各副本CPU使用量負載不均衡。
CoreDNS副本數少于兩個,或多個CoreDNS副本位于同節點上。
問題原因
由于CoreDNS副本調度不均、Service親和性設置導致CoreDNS Pod負載不均衡。
解決方案
擴容并打散CoreDNS副本到不同的節點上。
負載不均衡時,可禁用kube-dns服務的親和性屬性。具體操作,請參見配置Kube-DNS服務。
CoreDNS Pod運行狀態異常
問題現象
部分接入CoreDNS的業務Pod解析域名的延遲增加、概率性或持續性失敗。
CoreDNS副本狀態Status不處于Running狀態,或重啟次數RESTARTS持續增加。
CoreDNS運行日志中出現異常。
問題原因
由于CoreDNS YAML模板、配置文件等導致CoreDNS運行異常。
解決方案
檢查CoreDNS Pod運行狀態和運行日志。
常見異常日志及處理方案
日志中字樣 | 原因 | 處理方案 |
| 配置文件和CoreDNS不兼容, | 從kube-system命名空間中CoreDNS配置項中刪除ready插件,其它報錯同理。 |
| 日志出現時間段內,API Server中斷。 | 如果是日志出現時間和異常不吻合,可以排除該原因,否則請檢查CoreDNS Pod網絡連通性。具體操作,請參見檢查CoreDNS Pod的網絡連通性。 |
| 日志出現時間段內,CoreDNS無法連接到上游DNS服務器。 |
客戶端負載原因導致解析失敗
問題現象
業務高峰期間或突然偶發的解析失敗,ECS監控顯示機器網卡重傳率、CPU負載異常。
問題原因
接入CoreDNS的業務Pod所在ECS負載達到100%等情況導致UDP報文丟失。
解決方案
建議提交工單排查原因。
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負載。具體操作,請參見使用NodeLocal DNSCache。
Conntrack表滿
問題現象
部分節點或全部節點上接入CoreDNS的業務,Pod解析域名在業務高峰時間段內出現大批量域名解析失敗,高峰結束后失敗消失。
運行
dmesg -H
,滾動到問題對應時段的日志,發現出現conntrack full
字樣的報錯信息。
問題原因
Linux內Conntrack表條目有限,無法進行新的UDP或TCP請求。
解決方案
增加Conntrack表限制。具體操作,請參見如何提升Linux連接跟蹤Conntrack數量限制?。
AutoPath插件異常
問題現象
解析集群外部域名時,概率性解析失敗或解析到錯誤的IP地址,解析集群內部域名無異常。
高頻創建容器時,集群內部服務域名解析到錯誤的IP地址。
問題原因
CoreDNS處理缺陷導致AutoPath無法正常工作。
解決方案
按照以下步驟,關閉AutoPath插件。
執行
kubectl -n kube-system edit configmap coredns
命令,打開CoreDNS配置文件。刪除
autopath @kubernetes
一行后保存退出。檢查CoreDNS Pod運行狀態和運行日志,運行日志中出現
reload
字樣后說明修改成功。
A記錄和AAAA記錄并發解析異常
問題現象
接入CoreDNS的業務Pod解析域名概率性失敗。
從抓包或檢查CoreDNS DNS查詢請求日志可以發現,A和AAAA通常在同一時間的出現,并且請求的源端口一致。
問題原因
并發A和AAAA的DNS請求觸發Linux內核Conntrack模塊缺陷,導致UDP報文丟失。
低版本的libc(<2.33)在ARM機型上在同時發起A和AAAA請求時的并發問題,導致請求超時重傳,請參見GLIBC#26600。
解決方案
考慮采用NodeLocal DNSCache緩存方案,提升DNS解析性能,降低CoreDNS負載。具體操作,請參見使用NodeLocal DNSCache。
CentOS、Ubuntu等使用libc的基礎鏡像,升級libc版本到2.33或以上版本避免A和AAAA并發解析問題。
CentOS、Ubuntu等基礎鏡像,可以通過
options timeout:2 attempts:3 rotate single-request-reopen
等參數優化。如果容器鏡像是以Alpine制作的,建議更換基礎鏡像。更多信息,請參見Alpine。
PHP類應用短連接解析問題較多,如果使用的是PHP Curl的調用,可以使用
CURL_IPRESOLVE_V4
參數僅發送IPv4解析。更多信息,請參見函數說明。
IPVS缺陷導致解析異常
問題現象
當集群節點擴縮容、節點關機、CoreDNS縮容時,出現概率性解析失敗,通常時長在五分鐘左右。
問題原因
若您集群的kube-proxy負載均衡模式為IPVS,在CentOS、Alibaba Cloud Linux 2內核版本小于4.19.91-25.1.al7.x86_64的節點上,摘除IPVS UDP類型后端后,一段時間內若新發起的UDP報文源端口沖突,該報文會被丟棄。
解決方案
考慮采用NodeLocal DNSCache緩存方案,可以容忍IPVS丟包。具體操作,請參見使用NodeLocal DNSCache。
優化IPVS UDP超時時間。具體操作,請參見配置IPVS類型集群的UDP超時時間。
NodeLocal DNSCache未生效
問題現象
NodeLocal DNSCache沒有流量進入,所有請求仍在CoreDNS上。
問題原因
未配置DNSConfig注入,業務Pod實際仍配置了CoreDNS kube-dns服務IP作為DNS服務器地址。
業務Pod采用Alpine作為基礎鏡像,Alpine基礎鏡像會并發請求所有nameserver,包括本地緩存和CoreDNS。
解決方案
配置DNSConfig自動注入。具體操作,請參見使用NodeLocal DNSCache。
如果容器鏡像是以Alpine制作的,建議更換基礎鏡像。更多信息,請參見Alpine。
PrivateZone域名解析異常
問題現象
對于接入NodeLocal DNSCache的業務,Pod無法解析PrivateZone上注冊的域名,或無法解析包含vpc-proxy字樣的阿里云云產品API域名,或解析結果不正確。
問題原因
PrivateZone不支持TCP協議,需要使用UDP協議訪問。
解決方案
在CoreDNS中配置prefer_udp
。具體操作,請參見CoreDNS配置說明。