容器服务 Kubernetes 版 ACK：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相关的指标监控和告警规则，您可以在容器服务管理控制台开启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字样后说明修改成功。