容器服务 Kubernetes 版 ACK：DNS最佳实践

监控指标

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组件压力

您可在集群中执行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字样后说明修改成功。