Container Service for Kubernetes：DNS最佳實務

最佳化網域名稱解析請求

使用合適的容器鏡像

當Kubernetes叢集中部署的容器採用了Alpine作為基礎鏡像時，可能會因為上述musl libc特性而無法正常解析網域名稱，建議嘗試更換基礎鏡像，如Debian、CentOS等。

避免IPVS缺陷導致的DNS機率性解析逾時問題

當叢集使用IPVS作為kube-proxy負載平衡模式時，您可能會在CoreDNS縮容或重啟時遇到DNS機率性解析逾時的問題。該問題由社區Linux核心缺陷導致，具體資訊，請參見IPVS。

使用節點DNS緩衝NodeLocal DNSCache

在ACK叢集中部署NodeLocal DNSCache可以提升服務發現的穩定性和效能，NodeLocal DNSCache通過在叢集節點上作為DaemonSet運行DNS緩衝代理來提高叢集DNS效能。

關於更多NodeLocal DNSCache的介紹及如何在ACK叢集中部署NodeLocal DNSCache的具體步驟，請參見使用NodeLocal DNSCache。

使用合適的CoreDNS版本

監控CoreDNS運行狀態

監控指標

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部署狀態

合理調整CoreDNS副本數

建議您在任何情況下設定CoreDNS副本數應至少為2，且副本數維持在一個合適的水位以承載整個叢集的解析。

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

• 當叢集節點數目長時間較為固定時，可以手動擴容副本數。具體操作，請參見手動擴容副本數。

• 如果叢集節點數持續增長，可以設定自動擴容副本數。具體操作，請參見自動擴容副本數（cluster-autoscaler）。

合理分配CoreDNS副本啟動並執行位置

建議您在部署CoreDNS副本時，應將CoreDNS副本打散在不同可用性區域、不同叢集節點上，避免單節點、單可用性區域故障。CoreDNS預設配置了按節點的弱反親和性，可能會因為節點資源不足導致部分或全部副本部署在同一節點上，如果遇到這種情況，請刪除Pod重新觸發其調度來調整。

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

手動擴容副本數

kubectl scale --replicas={target} deployment/coredns -n kube-system

自動擴容副本數（cluster-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

{
      "coresPerReplica": 64,
      "nodesPerReplica": 8,
      "min": 2,
      "max": 100,
      "preventSinglePointFailure": true
}

基於CPU負載指標自動擴容副本數（HPA）

---
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns-hpa
  namespace: kube-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

使用自訂參數完成CoreDNS獨佔節點部署

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

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

3. 在節點頁面，單擊標籤與汙點管理。

4. 在標籤與汙點管理頁面，選中目標節點，單擊添加標籤。

   說明

   節點數應大於CoreDNS副本數，避免單個節點上運行多個CoreDNS副本。

5. 在添加對話方塊中，設定以下參數，然後單擊確定。

   • 名稱：node-role-type

   • 值：coredns

6. 在叢集管理頁左側導覽列中，選擇營運管理 > 組件管理，然後搜尋CoreDNS。

7. 單擊CoreDNS卡片的配置，在配置對話方塊，單擊NodeSelector右側的＋，設定以下參數，然後單擊確定。

   • Key：node-role-type

   • Value：coredns

   CoreDNS會重新調度至指定標籤的節點上。

合理配置CoreDNS

Container ServiceACK僅提供CoreDNS的預設配置，您應關注配置中的各個參數，最佳化其配置，以使CoreDNS可以為您的業務容器正常提供DNS服務。CoreDNS的配置非常靈活，具體操作，請參見DNS策略配置和網域名稱解析說明和CoreDNS官方文檔。

您也可以通過容器智能營運中定時巡檢和故障診斷功能完成CoreDNS設定檔的檢查。當容器智能營運檢查結果中提示CoreDNS Configmap配置異常時，請逐個檢查以上專案。

合理調整CoreDNS的資源Request和Limit

部署CoreDNS時採用的預設資源Request和Limit如下表，建議您根據叢集實際運行情況及時做出調整，具體操作，請參見營運管理-組件管理-網路-CoreDNS-參數配置。

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

關閉Autopath外掛程式

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

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

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

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

配置CoreDNS優雅退出

配置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字樣後說明修改成功。