Container Service for Kubernetes:Deploying stable, high-performance unmanaged CoreDNS

Assess component pressure

Before adjusting replica count, assess your cluster's DNS pressure. Tools such as DNSPerf can measure overall DNS load.

If you cannot measure DNS pressure directly, use these guidelines:

• Run at least 2 CoreDNS pods, each with resource limits of at least 1 CPU core and 1 GB of memory.

• With NodeLocal DNSCache enabled, each CPU core handles over 10,000 queries per second (QPS). Monitor peak CPU usage per pod. If any pod consistently uses more than 1 CPU core during peak hours, scale out.

• Without load data, start with 1 CoreDNS pod per 8 cluster nodes as a conservative baseline.

Once you know your target replica count, use automatic adjustment (recommended) or scale manually.

Configure automatic adjustment (recommended)

The cluster-proportional-autoscaler component adjusts CoreDNS replica count in real time based on cluster size. Unlike HPA, it does not rely on CoreDNS CPU metrics and does not perform scale-in operations that could disrupt DNS. It targets 1 pod per 8 cluster nodes by default.

The replica count formula is: replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica)). The min and max parameters keep the pod count between 2 and 100.

Deploy the autoscaler with the following manifest:

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

Scale manually

To set a specific replica count directly:

kubectl scale --replicas=<target> deployment/coredns -n kube-system # Replace <target> with the target number of pods.

Create a dedicated node pool

When creating the node pool, follow these guidelines:

• CoreDNS is network-intensive but not compute-intensive. Use network-enhanced instances with at least 4 CPU cores and 8 GB of memory.

• The node pool must have at least 2 nodes, since CoreDNS runs 2 pods by default.

• Add a taint and label to prevent other pods from being scheduled to these nodes. For example, use system-addon: system-addon as both the taint key-value pair and label. Set the taint Effect to NoSchedule.

For detailed steps, see Create and manage node pools.

Schedule CoreDNS pods to the node pool

1. On the Add-ons page, find the CoreDNS card and click Configuration.

2. In the NodeSelector section, add the label of the dedicated node pool.

   Do not delete existing NodeSelector labels.

   

3. In the Tolerations section, add a toleration that matches the node pool's taint.

   

4. Click OK. Then run the following command to confirm that the CoreDNS pods are running on the dedicated node pool:

   kubectl -n kube-system get pod -o wide --show-labels | grep coredns

Pod anti-affinity

CoreDNS uses a requiredDuringSchedulingIgnoredDuringExecution pod anti-affinity rule to ensure no two CoreDNS pods share the same node. For this to work, your cluster needs at least 2 nodes with sufficient resource requests available, excluding:

• k8s.aliyun.com: true — nodes with node autoscaling enabled

• type: virtual-kubelet — virtual nodes

• alibabacloud.com/lingjun-worker: true — Lingjun nodes

The default affinity configuration is:

      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              # virtual nodes have this label
              - key: type
                operator: NotIn
                values:
                - virtual-kubelet
              # lingjun worker nodes have this label
              - key: alibabacloud.com/lingjun-worker
                operator: NotIn
                values:
                - "true"
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              # autoscaled nodes have this label
              - key: k8s.aliyun.com
                operator: NotIn
                values:
                - "true"
            weight: 100
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: k8s-app
                operator: In
                values:
                - kube-dns
            topologyKey: kubernetes.io/hostname

Topology-aware scheduling

By default, CoreDNS uses topology-aware scheduling to spread pods across zones. The whenUnsatisfiable: DoNotSchedule setting enforces this — pods won't be scheduled if the zone balance condition can't be met.

For this to work reliably:

• Your cluster must have nodes in at least 2 different zones, each with at least 1 node that has sufficient resources for CoreDNS.

• All nodes must have the topology.kubernetes.io/zone label (applied by default). Missing or inconsistent labels can cause scheduling failures or uneven distribution.

• Upgrade your cluster to v1.27 or later and CoreDNS to v1.12.1.3 or later to get the matchLabelKeys fix described below.

CoreDNS versions earlier than v1.12.1.3 use this topology spread constraint:

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

CoreDNS v1.12.1.3 and later resolves this with the matchLabelKeys feature introduced in Kubernetes v1.27:

topologySpreadConstraints:
- labelSelector:
    matchLabels:
      k8s-app: kube-dns
  matchLabelKeys:
  - pod-template-hash
  nodeTaintsPolicy: Honor
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule

Adding matchLabelKeys: [pod-template-hash] scopes the spread constraint to pods from the current ReplicaSet only, so rolling updates produce an even distribution across all zones.