索引

診斷流程

基本概念

• 集群內(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ù)。

異常診斷流程

1. 判斷當(dāng)前的異常原因。具體信息，請(qǐng)參見(jiàn)常見(jiàn)客戶端報(bào)錯(cuò)。

   • 如果異常原因是域名不存在，請(qǐng)參見(jiàn)排查思路的《按解析異常的域名類(lèi)型》。

   • 如果異常原因是無(wú)法連接至域名服務(wù)器，請(qǐng)參見(jiàn)排查思路的《按解析異常出現(xiàn)頻次》。

2. 如果以上排查無(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，則按以下步驟排查。

       1. 通過(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)異常。

       2. 通過(guò)檢查CoreDNS運(yùn)行日志進(jìn)行診斷。具體操作，請(qǐng)參見(jiàn)檢查CoreDNS運(yùn)行日志和集群外部域名解析異常。

       3. 確認(rèn)異常是否能夠穩(wěn)定復(fù)現(xiàn)。

          1. 如果異常穩(wěn)定復(fù)現(xiàn)，請(qǐng)參見(jiàn)檢查CoreDNS DNS查詢請(qǐng)求日志和檢查業(yè)務(wù)Pod到CoreDNS的網(wǎng)絡(luò)連通性。

          2. 如果異常不能穩(wěn)定復(fù)現(xiàn)，請(qǐng)參見(jiàn)抓包。

   • 如果使用了NodeLocal DNSCache，請(qǐng)參見(jiàn)NodeLocal DNSCache未生效和PrivateZone域名解析異常。

3. 如果以上排查無(wú)果，請(qǐng)提交工單排查。

常見(jiàn)客戶端報(bào)錯(cuò)

排查思路

常見(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)

檢查CoreDNS運(yùn)行日志

命令

kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx

檢查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ò)連通性

操作步驟

1. 登錄CoreDNS Pod所在集群節(jié)點(diǎn)。

2. 執(zhí)行ps aux | grep coredns，查詢CoreDNS的進(jìn)程ID。

3. 執(zhí)行nsenter -t <pid> -n bash，進(jìn)入CoreDNS所在容器網(wǎng)絡(luò)命名空間，其中pid為上一步得到的進(jìn)程ID。

4. 測(cè)試網(wǎng)絡(luò)連通性。

   1. 運(yùn)行telnet <apiserver_clusterip> 6443，測(cè)試Kubernetes API Server的連通性。

      其中apiserver_clusterip為default命名空間下Kubernetes服務(wù)的IP地址。

   2. 運(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)題

檢查業(yè)務(wù)Pod到CoreDNS的網(wǎng)絡(luò)連通性

操作步驟

1. 選擇以下任意一種方式，進(jìn)入客戶端Pod容器網(wǎng)絡(luò)。

   • 方法一：使用kubectl exec命令。

   • 方法二：

     1. 登錄業(yè)務(wù)Pod所在集群節(jié)點(diǎn)。

     2. 執(zhí)行ps aux | grep <業(yè)務(wù)進(jìn)程名>命令，查詢業(yè)務(wù)容器的進(jìn)程ID。

     3. 執(zhí)行nsenter -t <pid> -n bash命令，進(jìn)入業(yè)務(wù)Pod所在容器網(wǎng)絡(luò)命名空間。

        其中pid為上一步得到的進(jìn)程ID。

   • 方法三：如果頻繁重啟，請(qǐng)按以下步驟操作。

     1. 登錄業(yè)務(wù)Pod所在集群節(jié)點(diǎn)。

     2. 執(zhí)行docker ps -a | grep <業(yè)務(wù)容器名>命令，查詢k8s_POD_ 開(kāi)頭的沙箱容器，記錄容器ID。

     3. 執(zhí)行docker inspect <沙箱容器 ID> | grep netns命令，查詢/var/run/docker/netns/xxxx的容器網(wǎng)絡(luò)命名空間路徑。

     4. 執(zhí)行nsenter -n<netns 路徑> bash命令，進(jìn)入容器網(wǎng)絡(luò)命名空間。

        其中netns 路徑為上一步得到的路徑。

        說(shuō)明

        -n和<netns 路徑>之間不加空格。

2. 測(cè)試網(wǎng)絡(luò)連通性。

   1. 執(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。

   2. 執(zhí)行ping <coredns_pod_ip>命令，測(cè)試業(yè)務(wù)Pod到CoreDNS容器副本的連通性。

      其中<coredns_pod_ip>為kube-system命名空間中CoreDNS Pod的IP。

   3. 執(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)題

抓包

當(dāng)無(wú)法定位問(wèn)題時(shí)，需要抓包進(jìn)行輔助診斷。

1. 登錄出現(xiàn)異常的業(yè)務(wù)Pod、CoreDNS Pod所在節(jié)點(diǎn)。

2. 在ECS（非容器內(nèi)）執(zhí)行以下命令，可以將最近所有的53端口信息抓取到文件中。

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

3. 結(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)求日志

# 其中包含狀態(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

當(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)注明以下信息。

新增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)異常日志及處理方案

客戶端負(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ú)法正常工作。

解決方案

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ō)明。