Introduction

The coredns add-on is a DNS server that provides domain name resolution services for Kubernetes clusters. coredns chains plug-ins to provide additional features.

coredns is an open-source software and has been a part of CNCF. It provides a means for cloud services to discover each other in cloud-native deployments. Each of the plug-ins chained by coredns provides a particular DNS function. You can integrate coredns with only the plug-ins you need to make it fast, efficient, and flexible. When used in a Kubernetes cluster, coredns can automatically discover services in the cluster and provide domain name resolution for these services. By working with DNS server, coredns can resolve external domain names for workloads in a cluster.

coredns is a system resource add-on. It is installed by default when a cluster of Kubernetes v1.11 or later is created.

Kubernetes v1.11 and later back CoreDNS as the official default DNS for all clusters going forward.

CoreDNS official website: https://coredns.io/

Open source community: https://github.com/coredns/coredns

For details, see DNS.

Notes and Constraints

When coredns is running properly or being upgraded, ensure that the number of available nodes is greater than or equal to the number of coredns instances and all coredns instances are running. Otherwise, the upgrade will fail.

Installing the Add-on

This add-on has been installed by default. If it is uninstalled due to some reasons, you can reinstall it by performing the following steps:

1. Log in to the CCE console and access the cluster details page. Choose Add-ons in the navigation pane, locate coredns on the right, and click Install.
2. On the Install Add-on page, select the add-on specifications and set related parameters.

   Table 1 coredns add-on parameters

   Parameter	Description
   Add-on Specifications	Concurrent domain name resolution ability. Select add-on specifications that best fit your needs.
   Pods	Number of pods that will be created to match the selected add-on specifications.
   Containers	CPU and memory quotas of the container allowed for the selected add-on specifications. The quotas cannot be modified.
   Parameters	stub_domains: A domain name server for a user-defined domain name. The format is a key-value pair. The key is a suffix of DNS domain name, and the value is one or more DNS IP addresses. upstream_nameservers: IP address of the upstream DNS server. servers: The servers configuration is available since coredns 1.23.1. You can customize the servers configuration. For details, see dns-custom-nameservers. plugins indicates the configuration of each component in coredns (https://coredns.io/manual/plugins/). You are advised to retain the default configurations in common scenarios to prevent CoreDNS from being unavailable due to configuration errors. Each plugin component contains name, parameters (optional), and configBlock (optional). The format of the generated Corefile is as follows: $name $parameters { $configBlock } Table 2 describes common plugins. Example: { "servers": [ { "plugins": [ { "name": "bind", "parameters": "{$POD_IP}" }, { "name": "cache", "parameters": 30 }, { "name": "errors" }, { "name": "health", "parameters": "{$POD_IP}:8080" }, { "configBlock": "pods insecure\nfallthrough in-addr.arpa ip6.arpa", "name": "kubernetes", "parameters": "cluster.local in-addr.arpa ip6.arpa" }, { "name": "loadbalance", "parameters": "round_robin" }, { "name": "prometheus", "parameters": "{$POD_IP}:9153" }, { "configBlock": "policy random", "name": "forward", "parameters": ". /etc/resolv.conf" }, { "name": "reload" }, { "name": "log" } ], "port": 5353, "zones": [ { "zone": "." } ] } ], "stub_domains": { "acme.local": [ "1.2.3.4", "6.7.8.9" ] }, "upstream_nameservers": ["8.8.8.8", "8.8.4.4"] }

   Table 2 Default plugin configuration of the active zone of coredns

   plugin Name	Description
   bind	Host IP address listened by coredns. You are advised to retain the default value {$POD_IP}.
   cache	DNS cache is enabled.
   errors	Errors are logged to stdout.
   health	Health check configuration. The current listening IP address is {$POD_IP}:8080. Retain the default value. Otherwise, the coredns health check fails and coredns restarts repeatedly.
   kubernetes	CoreDNS Kubernetes plug-in, which provides the service parsing capability in a cluster.
   loadbalance	Round-robin DNS load balancer that randomizes the order of A, AAAA, and MX records in the answer.
   prometheus	Port for obtaining coredns metrics. The default zone listening IP address is {$POD_IP}:9153. Retain the default value. Otherwise, CloudScope cannot collect coredns metrics.
   forward	Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
   reload	Allows automatic reload of a changed Corefile. After you edit the ConfigMap configuration, wait for two minutes for the modification to take effect.

3. After the preceding configurations are complete, click Install.

How Does Domain Name Resolution Work in Kubernetes?

DNS policies can be set on a per-pod basis. Currently, Kubernetes supports four types of DNS policies: Default, ClusterFirst, ClusterFirstWithHostNet, and None. For details, see https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/. These policies are specified in the dnsPolicy field in the pod-specific.

Customizing CoreDNS Specifications

On the console, the coredns add-on can only be configured with the preset specifications, which can satisfy most of the service requirements. In some scenarios where there are requirements on the CoreDNS resource usage, you may need to customize the add-on specifications.

The following describes how to customize CoreDNS parameters, including replicas, CPUs, and memory.

• Improper modification on CoreDNS configuration may cause domain name resolution failures in the cluster. Perform tests before and after the modification.
• Modifying the number of CoreDNS replicas, CPUs, and memory size will change CoreDNS's parsing capability. Therefore, evaluate the impact before the operation.
• By default, podAntiAffinity (pod anti-affinity) is configured for the coredns 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 the number of configured CoreDNS replicas is greater than the number of cluster nodes, the excess pods cannot be scheduled. Therefore, keep the number of replicas less than or equal to the number of nodes.

1. Call the add-on query API to query the ID of the installed coredns add-on.

   GET https://{cluster_id}.{endpoint}/api/v3/addons?cluster_id={cluster_id}

   For details about how to call an API, see Calling APIs. {cluster_id} indicates the cluster ID, which can be viewed on the cluster details page on the CCE console. {endpoint} indicates the CCE access address, which can be obtained from Regions and Endpoints. For example, cce.east-3.myhuaweicloud.com indicates the Shanghai1 region.

   View the uid and spec of coredns add-on in the response.

   {
       "kind": "Addon",
       "apiVersion": "v3",
       "items": [
           {
               "kind": "Addon",
               "apiVersion": "v3",
               "metadata": {
                   "uid": "2083381d-46ae-11ec-91a8-0255ac1000c5",
                   "name": "coredns",
                   "creationTimestamp": "2021-11-16T07:23:42Z",
                   "updateTimestamp": "2021-11-16T07:27:35Z"
               },
               "spec": {
                   "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9",
                   "version": "1.17.9",
                   "addonTemplateName": "coredns",
                   "addonTemplateType": "helm",
   ...

2. Call the configuration API to modify the add-on specifications.

   PUT https://{cluster_id}.{endpoint}/api/v3/addons/{uid}

   {cluster_id} indicates the cluster ID. {endpoint} indicates the address for accessing CCE, which can be obtained from Regions and Endpoints. {uid} indicates the add-on ID obtained in the previous step.

   The following is an example of the request body. spec defines the content queried in the previous step. Modify replicas (number of replicas) and resources (CPU/memory usage of a single pod) as required. Retain the values of clusterID and version. The value of addon.upgrade/type must be patch.

   {
       "metadata": {
           "annotations": {
               "addon.upgrade/type": "patch"
           }
       },
       "spec": {
           "clusterID": "15d748b4-3de1-11ec-9199-0255ac1000c9",
           "version": "1.17.9",
           "addonTemplateName": "coredns",
           "values": {
               "flavor": {
                   "replicas": 2,
                   "resources": [
                       {
                           "limitsCpu": "500m",
                           "limitsMem": "512Mi",
                           "requestsCpu": "500m",
                           "requestsMem": "512Mi"
                       }
                   ]
               }
           }
       }
   }