索引

診斷流程

基本概念

• 集群內部域名：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服務。

異常診斷流程

1. 判斷當前的異常原因。具體信息，請參見常見客戶端報錯。

   • 如果異常原因是域名不存在，請參見排查思路的《按解析異常的域名類型》。

   • 如果異常原因是無法連接至域名服務器，請參見排查思路的《按解析異常出現頻次》。

2. 如果以上排查無果，請按以下步驟排查。

   • 檢查業務Pod的DNS配置，是否已經接入CoreDNS。具體操作，請參見檢查業務Pod的DNS配置。

     • 如果沒有接入CoreDNS，則考慮是客戶端負載原因或Conntrack表滿導致解析失敗。具體操作，請參見客戶端負載原因導致解析失敗和Conntrack表滿。

     • 如果接入了CoreDNS，則按以下步驟排查。

       1. 通過檢查CoreDNS Pod運行狀態進行診斷。具體操作，請參見檢查CoreDNS Pod運行狀態和CoreDNS Pod運行狀態異常。

       2. 通過檢查CoreDNS運行日志進行診斷。具體操作，請參見檢查CoreDNS運行日志和集群外部域名解析異常。

       3. 確認異常是否能夠穩定復現。

          1. 如果異常穩定復現，請參見檢查CoreDNS DNS查詢請求日志和檢查業務Pod到CoreDNS的網絡連通性。

          2. 如果異常不能穩定復現，請參見抓包。

   • 如果使用了NodeLocal DNSCache，請參見NodeLocal DNSCache未生效和PrivateZone域名解析異常。

3. 如果以上排查無果，請提交工單排查。

常見客戶端報錯

排查思路

常見檢查方法

檢查業務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運行狀態

檢查CoreDNS運行日志

命令

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

檢查CoreDNS DNS查詢請求日志

命令

DNS查詢請求日志僅會在開啟CoreDNS的Log插件后，才會打印到容器日志中。關于開啟Log插件的具體操作，請參見CoreDNS配置說明。

命令與檢查CoreDNS運行日志相同，請參見檢查CoreDNS運行日志。

檢查CoreDNS Pod的網絡連通性

您可以使用控制臺或命令行方式檢查CoreDNS Pod的網絡連通性。

常見問題

檢查業務Pod到CoreDNS的網絡連通性

您可以使用控制臺或命令行方式檢查業務Pod到CoreDNS的網絡連通性。

常見問題

抓包

當無法定位問題時，需要抓包進行輔助診斷。

1. 登錄出現異常的業務Pod、CoreDNS Pod所在節點。

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

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

3. 結合業務日志的報錯定位到精準的報錯時間的報文信息。

   說明

   • 在正常情況下，抓包對業務無影響，僅會增加小部分的CPU負載和磁盤寫入。

   • 以上命令會對抓取到的包進行rotate，最多可以寫200個20MB的.pcap文件。

集群外部域名解析異常

問題現象

業務Pod可以正常解析集群內部域名，但無法解析某些集群外部域名。

問題原因

上游服務器域名解析返回異常。

解決方案

檢查CoreDNS DNS查詢請求日志。

常見請求日志

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

當CoreDNS DNS查詢請求日志中顯示集群外部域名返回為NXDOMAIN、SERVFAIL、REFUSED時，說明CoreDNS的上游DNS服務器返回異常。

默認情況下，集群中CoreDNS的上游DNS服務器是VPC提供的DNS服務器（100.100.2.136 和 100.100.2.138）。您可以提交工單至云服務器ECS產品。提交工單時請注明以下信息。

新增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端口持續性不通。

解決方案

您可以使用網絡診斷對業務Pod和CoreDNS地址直接的網絡連通性進行診斷。若仍無法解決問題請提交工單排查。

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運行狀態和運行日志。

常見異常日志及處理方案

客戶端負載原因導致解析失敗

問題現象

業務高峰期間或突然偶發的解析失敗，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無法正常工作。

解決方案

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配置說明。