Container Service for Kubernetes：DNS最佳實務

監控指標

CoreDNS通過標準的Prometheus介面暴露出解析結果等健康指標，發現CoreDNS服務端甚至上遊DNS伺服器的異常。

阿里雲Prometheus監控預設內建了CoreDNS相關的指標監控和警示規則，您可以在Container Service管理主控台開啟Prometheus及儀錶盤功能。具體操作，請參見CoreDNS組件監控。

若您是自建Prometheus監控Kubernetes叢集，可以在Prometheus觀測相關指標，並對重點指標設定警示。具體操作，請參見CoreDNS Prometheus官方文檔。

作業記錄

在DNS異常發生的情況下，CoreDNS日誌有助於您快速診斷異常根因。建議您開啟CoreDNS網域名稱解析日誌和其SLS日誌採集，具體操作，請參見分析和監控CoreDNS日誌。

Kubernetes事件投遞

在v1.9.3.6-32932850-aliyun及以上版本的CoreDNS中，您可以開啟k8s_event外掛程式以將CoreDNS關鍵日誌以Kubernetes事件的形式投遞到事件中心。關於k8s_event外掛程式，請參見k8s_event。

全新部署的CoreDNS會預設開啟該功能。如果您是從低版本CoreDNS升級到v1.9.3.6-32932850-aliyun及以上版本的，您需要手動修改設定檔以開啟該功能。

1. 執行如下命令，開啟CoreDNS設定檔。

   kubectl -n kube-system edit configmap/coredns

2. 新增kubeAPI和k8s_event外掛程式。

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
   
           // 新增開始（請忽略其他差異）。
           kubeapi
           k8s_event {
             level info error warning // 將info、error、warning狀態關鍵日誌投遞。
           }
           // 新增結束。
   
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // 下方略。
       }

3. 檢查CoreDNS Pod運行狀態和作業記錄，作業記錄中出現reload字樣後說明修改成功。

評估CoreDNS組件壓力

您可在叢集中執行DNS壓力測試評估組件壓力。包括DNSPerf在內的許多開源工具可以協助您完成此目標。如果您無法準確評估叢集DNS壓力，您可參照下方的推薦標準。

• 建議您在任何情況下設定CoreDNS Pod數應至少為2，單個Pod的資源limit不小於1核1G。

• CoreDNS所能提供的網域名稱解析QPS與CPU消耗成正相關，使用NodeLocal DNSCache的情況下，每CPU核可以支撐10000+ QPS的網域名稱解析請求。不同類型的業務對網域名稱請求的QPS需求存在較大差異，您可以觀察每個CoreDNS Pod的峰值CPU使用量，如果其在業務峰值期間佔用CPU大於一核，建議您對CoreDNS進行副本擴容。無法確定峰值CPU使用量時，可以保守地採用Pod數和叢集節點數1：8的比值來部署，即每擴容8個叢集節點，增加一個CoreDNS Pod。

調整CoreDNS Pod數量

CoreDNS擁有的Pod數量直接決定了CoreDNS能夠使用的計算資源，您可根據評估的結果調整CoreDNS所屬Pod數量。

• 根據建議策略自動調整

  您可部署下方的dns-autoscaler，它會參照前方提到的推薦策略（Pod數和叢集節點數1：8）即時自動調整CoreDNS的Pod數量。其中Pod數量的計算公式為replicas = max (ceil (cores × 1/coresPerReplica), ceil (nodes × 1/nodesPerReplica) )，且受到max、min限制。

  dns-autoscaler

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: dns-autoscaler
    namespace: kube-system
    labels:
      k8s-app: dns-autoscaler
  spec:
    selector:
      matchLabels:
        k8s-app: dns-autoscaler
    template:
      metadata:
        labels:
          k8s-app: dns-autoscaler
      spec:
        serviceAccountName: admin
        containers:
        - name: autoscaler
          image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
          resources:
            requests:
              cpu: "200m"
              memory: "150Mi"
          command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --nodelabels=type!=virtual-kubelet
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=9

• 手動調整

  您可通過下方的命令手動調整CoreDNS所屬的Pod數量。

  kubectl scale --replicas={target} deployment/coredns -n kube-system # target替換為目標Pod數量

• 請勿使用工作負載自動調整

  雖然工作負載自動調整，例如容器水平伸縮（HPA）、容器定時水平伸縮（CronHPA）等也可以自動調整Pod數量，但是它們會頻繁執行擴縮容。由於前文所說的Pod縮容時導致的解析異常，請勿使用工作負載自動調整控制CoreDNS Pod數量。

調整CoreDNS Pod規格

另一種調整CoreDNS資源的方式是調整Pod規格。在ACK託管叢集Pro版中，CoreDNS Pod預設的記憶體限制為2Gi，CPU則未限制。推薦您將CPU Limit設定為4096m, 最小應不低於1024m。您可通過控制台對CoreDNS Pod配置進行調整。

調度CoreDNS Pod

建議您在部署CoreDNS Pod時，將其部署在不同可用性區域、不同叢集節點上，避免單節點、單可用性區域故障。版本低於v1.8.4.3的CoreDNS組件預設配置了按節點的弱反親和性，可能會因為節點資源不足導致部分或全部Pod部署在同一節點上，如果遇到這種情況，請刪除Pod觸發調度進行調整，或者升級組件版本到最新。CoreDNS 組件版本v1.8 以下版本不再維護，請儘快升級。

CoreDNS所啟動並執行叢集節點應避免CPU、記憶體用滿的情況，否則會影響網域名稱解析的QPS和響應延遲。當叢集節點條件允許時，可以考慮使用自訂參數將CoreDNS調度至獨立的叢集節點上，以提供穩定的網域名稱解析服務。

關閉kube-dns服務的親和性配置

關閉Autopath外掛程式

部分早期版本的CoreDNS開啟了Autopath外掛程式，該外掛程式在一些極端情境下會導致解析結果出錯，請確認其是否處於開啟狀態，並編輯設定檔將其關閉。更多資訊，請參見Autopath。

1. 執行kubectl -n kube-system edit configmap coredns命令，開啟CoreDNS設定檔。

2. 刪除autopath @kubernetes一行後儲存退出。

3. 檢查CoreDNS Pod運行狀態和作業記錄，作業記錄中出現reload字樣後說明修改成功。

配置CoreDNS優雅退出

lameduck是 CoreDNS 中的一種機制，用於實現優雅退出（Graceful Shutdown）。它可在CoreDNS需要停止或重啟時，確保正在處理的請求能夠正常完成，而不會突然中斷。lameduck的工作原理如下：

• 當CoreDNS進程將要終止時，它會進入 Lameduck 模式。

• 在lameduck模式下，CoreDNS會停止接收新的請求，但會繼續處理已經接收到的請求，直到請求全部完成或超過lameduck逾時時間。

配置Forward外掛程式與上遊VPC DNS伺服器的預設協議

NodeLocal DNSCache採用TCP協議與CoreDNS進行通訊，CoreDNS會根據請求來源使用的協議與上遊DNS伺服器進行通訊。因此預設情況下，來自業務容器的叢集外部網域名稱解析請求會依次經過NodeLocal DNSCache、CoreDNS，最終以TCP協議請求VPC內DNS伺服器，即ECS上預設配置的100.100.2.136和100.100.2.138兩個 IP。

# 修改前
forward . /etc/resolv.conf
# 修改後
forward . /etc/resolv.conf {
  prefer_udp
}

配置Ready就緒探針外掛程式

大於1.5.0版本的CoreDNS必須配置ready外掛程式以啟用就緒探針。

1. 執行如下命令，開啟CoreDNS設定檔。

   kubectl -n kube-system edit configmap/coredns

2. 檢查是否包含ready一行，若無，則增加ready一行，按Esc鍵、輸入:wq!並按Enter鍵，儲存修改後的設定檔並退出編輯模式。

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # 如果沒有這一行，請增加本行，注意縮排與Kubernetes保持一致。
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. 檢查CoreDNS Pod運行狀態和作業記錄，作業記錄中出現reload字樣後說明修改成功。