Container Service for Kubernetes：DNS FAQ

為什麼通過exec無法進入CoreDNS Pod？

問題現象

使用kubectl -n kube-system exec -it {coredns pod} bash及類似命令無法進入到CoreDNS Pod。

問題原因

CoreDNS所使用的容器鏡像是基於Scratch構建，不具備Shell執行環境。

解決方案

可以使用nsenter的方式訪問CoreDNS Pod所處的容器網路環境。具體操作，請參見檢查CoreDNS Pod的網路連通性。如果您需要查看CoreDNS日誌，可以啟用CoreDNS日誌分析與監控能力。具體操作，請參見分析和監控CoreDNS日誌。

為什麼CoreDNS正在使用廢棄的API？

問題現象

執行叢集升級前置檢查時，發現使用者代理程式（UserAgent）為coredns的用戶端正在訪問已棄用的discovery.k8s.io/v1beta1Kubernetes API，其API路徑為/apis/discovery.k8s.io/v1beta1。

問題原因

CoreDNS使用discovery.k8s.io/v1beta1API串連到APIServer，但該API在您叢集版本中即將棄用或已棄用。產生這種現象的原因有兩種：

• CoreDNS版本較低：當前叢集安裝的CoreDNS版本較低，不支援調用discovery.k8s.io/v1API，只能使用discovery.k8s.io/v1beta1API。

• CoreDNS是在較早版本的Kubernetes中啟動的：儘管Kubernetes和CoreDNS的版本都是最新的，但CoreDNS是在較早的Kubernetes版本（例如1.20版本）中啟動，並在容器啟動階段選擇了discovery.k8s.io/v1beta1API版本。然而，隨著Kubernetes叢集逐漸升級，discovery.k8s.io/v1beta1API被棄用，但CoreDNS仍然在使用它。

解決方案

1. 登入Container Service管理主控台，在左側導覽列選擇叢集列表。

2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇營運管理 > 組件管理。

3. 在組件管理頁面對CoreDNS組件進行升級操作。

   如果頁面提示不可升級，請執行下一步，否則執行步驟3。關於如何升級組件，請參見管理組件。

4. 使用kubectl執行如下命令，重啟CoreDNS。

   kubectl -n kube-system rollout restart deployment coredns

   重要

   請注意重啟過程中可能存在小機率解析異常的問題。更多資訊，請參見避免IPVS缺陷導致的DNS機率性解析逾時問題。

5. CoreDNS升級或重啟成功後，使用kubectl執行如下命令，確認CoreDNS Pod的狀態。

   kubectl -n kube-system get pod -l k8s-app=kube-dns

   如果CoreDNS Pod剛剛重建並處於Running狀態，您可忽略叢集升級前置檢查頁面中由CoreDNS產生的廢棄API調用記錄，繼續對叢集進行升級。

CoreDNS日誌中報錯，顯示dns: buffer size too small

問題現象

使用kubectl -n kube-system logs {coredns pod} 命令查看CoreDNS Pod日誌時，提示dns: buffer size too small。

問題原因

由於CoreDNS的預設緩衝區大小（bufsize）為1232位元組，所以Kubernetes Pod的DNS查詢的UDP資料包最大隻能為1232位元組。如果某個DNS請求的響應超過了這個限制，DNS解析將會失敗，無法擷取該請求的結果。在Pod中進行某些DNS查詢，尤其是當請求的響應資料較大時，可能會受到影響，詳情請參見issue。

解決方案

升級CoreDNS版本至v1.7.1及以上。對於CoreDNS版本低於v1.7.1，可使用kubectl edit cm -n kube-system coredns 配置CoreDNS的bufsize大小，該值取值範圍為[512, 4096]之間。更多資訊，請參見CoreDNS社區文檔。

. {
    bufsize 1220
    log
}

建立Service後連續請求兩次，分別返回NXDOMAIN和NOERR

CoreDNS組件採用多Pod執行個體部署，若其中某個Pod在建立Service後未及時從API Server擷取最新資訊，有可能出現多次請求返回結果不一致的情況。等待CoreDNS Pod擷取最新Service資訊後，DNS請求的結果會變為一致。

Windows節點上的DNS解析特性

• 在Windows節點上啟動並執行Pod不支援ClusterFirstWithHostNet。Windows 將所有帶有.的名稱視為全限定網域名稱（FQDN）並跳過全限定網域名稱（FQDN）解析。

• Windows支援多種不同的DNS解析器，但這些解析器彼此之間會有輕微的行為差別，建議使用Resolve-DNSName PowerShell cmdlet進行名稱查詢解析。

• 在Linux中，網域名稱解析失敗後，系統會使用預設的DNS尾碼列表依次嘗試重新解析。而Windows僅支援單個DNS尾碼， 即與該 Pod 的命名空間相關聯的DNS尾碼（例如，在 default 命名空間中產生一個 Pod，該 Pod 會獲得的 DNS 尾碼為 default.svc.cluster.local）。因此，在Windows節點的Pod中，您可以解析kubernetes.default.svc.cluster.local和kubernetes，但是不能解析部分限定名稱（如kubernetes.default 和 kubernetes.default.svc）。

更多資訊，請參見社區文檔。