優化域名解析請求

使用合適的容器鏡像

當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相關的指標監控和告警規則，您可以在容器服務管理控制臺開啟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. 登錄容器服務管理控制臺，在左側導航欄單擊集群。

2. 在集群列表頁面，單擊目標集群名稱，然后在左側導航欄，選擇節點管理 > 節點。

3. 在節點頁面，單擊標簽與污點管理。

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

   說明

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

5. 在添加對話框中，設置以下參數，然后單擊確定。

   • 名稱：node-role.kubernetes.io/coredns

   • 值：true

6. 在集群管理頁左側導航欄中，選擇運維管理 > 組件管理，然后搜索CoreDNS。

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

   • Key：node-role.kubernetes.io/coredns

   • Value：true

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

合理配置CoreDNS

容器服務ACK僅提供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字樣后說明修改成功。