一、為什么CCE集群的容器無法通過DNS解析？

問題描述

某客戶在DNS服務中做內網解析，將自有的域名綁定到DNS服務中的內網域名中，并綁定到特定的VPC中，發現本VPC內的節點（ECS）可以正常解析內網域名的記錄，而VPC內的容器則無法解析。

適用場景

VPC內的容器無法進行正常DNS解析的情況。

解決方案

由于本案例涉及的是內網域名解析，按照內網域名解析的規則，需要確保VPC內的子網DNS設置成的云上DNS，具體以內網DNS服務的控制臺界面提示為準。

本案例的子網中已經完成該設置，其中用戶可以在該VPC子網內的節點（ECS）進行域名解析，也說明已完成該設置，如下圖：

但是在容器內進行解析卻提示bad address無法解析域名返回地址，如下圖：

登錄CCE控制臺查看該集群的插件安裝情況。

如果已安裝插件列表中沒有coredns插件，可能是用戶卸載了該插件等原因導致。

安裝coredns插件，并添加相應的域名及對應的DNS服務地址，即可進行域名解析。

二、如何設置容器內的DNS策略？

CCE支持通過dnsPolicy標記每個Pod配置不同的DNS策略：

• None： 表示空的DNS設置，這種方式一般用于想要自定義DNS配置的場景，而且，往往需要和dnsConfig配合一起使用達到自定義DNS的目的。
• Default： 有人說Default的方式，是使用宿主機的方式，這種說法并不準確。

這種方式其實是讓kubelet來決定使用何種DNS策略。而kubelet默認的方式，就是使用宿主機的 /etc/resolv.conf，但是kubelet是可以靈活來配置使用什么文件來進行DNS策略的，我們完全可以使用kubelet的參數：–resolv-conf=/etc/resolv.conf來決定您的DNS解析文件地址。

• ClusterFirst： 這種方式表示Pod內的DNS使用集群中配置的DNS服務，簡單來說，就是使用Kubernetes中kubedns或coredns服務進行域名解析。如果解析不成功，才會使用宿主機的DNS配置進行解析。

如果未明確指定dnsPolicy，則默認使用“ClusterFirst”：

• 如果將dnsPolicy設置為“Default”，則名稱解析配置將從運行pod的工作節點繼承。
• 如果將dnsPolicy設置為“ClusterFirst”，則DNS查詢將發送到kube-dns服務。

對于以配置的集群域后綴為根的域的查詢將由kube-dns服務應答。所有其他查詢（例如，www.kubernetes.io）將被轉發到從節點繼承的上游名稱服務器。在此功能之前，通常通過使用自定義解析程序替換上游DNS來引入存根域。但是，這導致自定義解析程序本身成為DNS解析的關鍵路徑，其中可伸縮性和可用性問題可能導致集群丟失DNS功能。此特性允許用戶在不接管整個解析路徑的情況下引入自定義解析。

如果某個工作負載不需要使用集群內的coredns，可以使用kubectl命令或API將此策略設置為dnsPolicy: Default。