coredns (System Resource Add-On, Mandatory)

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, click the cluster name, and access the cluster console. 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. If you select Custom qps, the domain name resolution QPS provided by CoreDNS is positively correlated with the CPU consumption. Adjust the number of pods and container CPU/memory quotas as required.
   Pods	Number of pods that will be created to match the selected add-on specifications.
   Multi AZ	Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ. Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.
   Containers	CPU and memory quotas of the container allowed for the selected add-on specifications.
   Parameters	parameterSyncStrategy: indicates whether to configure consistency check when an add-on is upgraded. ensureConsistent: indicates that the configuration consistency check is enabled. If the configuration recorded in the cluster is inconsistent with the actual configuration, the add-on cannot be upgraded. force: indicates that the configuration consistency check is ignored during an upgrade. Ensure that the current effective configuration is the same as the original configuration. After the add-on is upgraded, restore the value of parameterSyncStrategy to ensureConsistent and enable the configuration consistency check again. 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	The changed Corefile can be automatically reloaded. After editing the ConfigMap, 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.