Updated on 2024-07-04 GMT+08:00

Adjusting the CoreDNS Deployment Status

In CCE clusters, the CoreDNS add-on is installed by default, and it can run on the same cluster nodes as your service containers. You need to pay attention to the following points when deploying CoreDNS:

Properly Changing the Number of CoreDNS Replicas

You are advised to set the number of CoreDNS replicas to at least 2 in any case and keep the number of replicas within a proper range to support the resolution of the entire cluster. The default number of pods for installing the add-on in a CCE cluster is 2.

  • Modifying the number of CoreDNS replicas, CPUs, and memory size will change CoreDNS' parsing capability. Therefore, evaluate the impact before the operation.
  • By default, podAntiAffinity (pod anti-affinity) is configured for the add-on. If a node already has a CoreDNS pod, no new pod can be added. That is, only one CoreDNS pod can run on a node. If there are more configured CoreDNS replicas than cluster nodes, the excess pods cannot be scheduled. Therefore, keep the number of replicas less than or equal to the number of nodes.

Properly Deploying the CoreDNS Pods

  • By default, podAntiAffinity (pod anti-affinity) is configured for CoreDNS, so CoreDNS pods are forcibly deployed on different nodes in a cluster. It is recommended to deploy CoreDNS pods on nodes in different AZs to prevent the add-on from being interrupted by faults in a single AZ.
  • The CPU and memory of the cluster node where the coredns add-on runs must not be used up. Otherwise, the QPS and response of domain name resolution will be affected. It is recommended to use the custom parameters to deploy CoreDNS separately.

Deploying CoreDNS Separately Using Custom Parameters

It is recommended that CoreDNS be deployed separately from resource-intensive workloads to prevent CoreDNS performance deterioration or unavailability due to service fluctuation. You can customize parameters to deploy CoreDNS on a dedicated node.

There should be more nodes than CoreDNS pods. You need to avoid deploying multiple CoreDNS pods on a single node.

  1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Nodes.
  2. Click the Nodes tab, select the node dedicated for CoreDNS, and click Labels and Taints above the node list.

    Add the following labels:

    • Key: node-role.kubernetes.io/coredns
    • Value: true

    Add the following taints:

    • Key: node-role.kubernetes.io/coredns
    • Value: true
    • Effect: NoSchedule
    Figure 1 Adding a label and a taint

  3. In the navigation pane, choose Add-ons, locate CoreDNS, and click Edit.
  4. Select Custom Policies for Node Affinity and add the preceding node label.

    Add tolerations for the preceding taint.

    Figure 2 Adding a toleration

  5. Click OK.

Automatically Expanding the CoreDNS Capacity Based on the HPA

HPA frequently scales down the number of the coredns add-on replicas. Therefore, you are advised not to use HPA. If HPA is required, you can configure HPA auto scaling policies using the CCE Advanced HPA add-on. The process is as follows:

  1. Log in to the CCE console and click the name of the target cluster to access the cluster console. In the navigation pane, choose Add-ons, locate the CCE Advanced HPA add-on on the right, and click Install.
  2. Configure the add-on parameters and click Install. For details about the add-on, see CCE Advanced HPA.
  3. In the navigation pane, choose Workloads, select the kube-system namespace, locate the row containing the CoreDNS pod, and click Auto Scaling in the Operation column.

    In the HPA Policies area, you can customize HPA policies based on metrics such as CPU usage and memory usage to automatically scale out the CoreDNS pods.

    Figure 3 Creating an auto scaling policy

  4. Click Create. If the latest status is Started, the policy has taken effect.