In a Kubernetes cluster, pods use domain names to access Services or external services. These domain names must be resolved to IP addresses to allow access. DNS handles this by maintaining a mapping between domain names and IP addresses. This topic describes the basics of DNS, the DNS components in ACK, and DNS configuration.
How domain name resolution works
Although devices on the internet communicate by using IP addresses, domain names are easier to remember because they are more semantic. As a result, clients almost always use domain names to initiate requests. The following figure shows the process when a client sends a request to example.com.
The server registers its IP address and domain name with a DNS server, which stores the corresponding record.
The client asks the DNS server for the IP address that corresponds to example.com.
The DNS server looks up the record and returns the IP address to the client.
The client uses the IP address to access the target server.
Domain name types in a cluster
Internal domain name: The domain name of a Service, which is valid only within the cluster. We recommend that you use the fully qualified domain name (FQDN) format,
<service-name>.<namespace>.svc.<cluster-domain>, to access the Service. Using a short domain name (<service-name>) causes excessive invalid DNS queries and increases resolution time.The cluster-domain is a custom setting configured during cluster creation, which defaults to
cluster.local.External domain name: Includes VPC-internal domain names and public domain names. To resolve these domain names, CoreDNS must get the result from an upstream DNS server. By default, the upstream DNS server is the PrivateZone service, with the IP addresses 100.100.2.136 and 100.100.2.138.
ImportantPrivateZone does not provide a Service Level Agreement (SLA) for the recursive resolution of public domain names. For the limitations of recursive resolution, see Manage recursive queries.
DNS components in a cluster
In an ACK managed cluster, two components handle DNS: CoreDNS and NodeLocal DNSCache.
CoreDNS
CoreDNS is available in two modes: managed and unmanaged.
Comparison item | ||
Applicable clusters |
|
|
Deployment mode | Deployed on the control plane and fully managed by ACK. On the Component Management page in the console, hosted component cards display Hosted. | Deployed as a workload (Deployment) in the cluster. By default, it is installed in the kube-system namespace and consumes resources on worker nodes. |
O&M responsibility | Alibaba Cloud is responsible for component O&M. | Follows a shared responsibility model:
|
Features |
|
|
Logging | Logging is enabled by default. | Supported, but you must manually enable CoreDNS logging. |
Monitoring and alerting | Supports Prometheus monitoring. You must set up and configure monitoring for the cluster. | |
Performance | For more information, see Managed CoreDNS performance. | Depends on the component configuration. |
Unmanaged CoreDNS
CoreDNS is a component in a Kubernetes cluster that handles DNS resolution. It can resolve both internal service domain names and external domain names. The CoreDNS project is hosted by the Cloud Native Computing Foundation (CNCF). For more information, see CoreDNS: DNS and Service Discovery.
Following the open-source Kubernetes standard, ACK clusters install CoreDNS as the default DNS server. CoreDNS is deployed as a Deployment in the kube-system namespace. kube-dns is the ClusterIP-type Service for CoreDNS. For information about how to configure CoreDNS, see Configure Unmanaged CoreDNS.
In the following example, a Pod in the default namespace attempts to access database-svc and goes through the following process:
The pod checks the
/etc/resolv.confconfiguration file and determines that the IP address of the DNS server is172.0.XX.XX. This is the ClusterIP of kube-dns. An example of the configuration file is as follows.nameserver 172.0.XX.XX # Defines the IP address of the DNS server. search default.svc.cluster.local svc.cluster.local cluster.local # Sets the search suffix rules for domain names. The more search paths are configured, the more lookup attempts are made. options ndots:5 # Defines options for the domain name resolution configuration file. Multiple key-value pairs are supported.A pod sends a DNS query to kube-dns, using the values in the
searchfield as suffixes to sequentially resolve the following names:database-svc.default.svc.cluster.local(A Service in the same namespace as the pod)database-svc.svc.cluster.local(A Service in another namespace)database-svc.cluster.local(cluster-scoped domain name)database-svc(external domain name)
The CoreDNS pod returns the result, which is the IP address 172.4.XX.XX.
The pod uses this IP to access the target service
database-svc.If the request is for an external domain name, such as a VPC-internal domain name or a public domain name, the CoreDNS pod forwards the query to the upstream DNS server.
ImportantDo not modify the DNS server configuration on the node because CoreDNS inherits the upstream DNS server address from the node on which it runs.
CoreDNS configuration is stored in the
corednsConfigMap in the kube-system namespace. In the default configuration, theforwardplugin points to/etc/resolv.conf. This means that for upstream DNS queries, CoreDNS uses the DNS server addresses from its container's/etc/resolv.conffile. The/etc/resolv.conffile in the CoreDNS container is, by default, the same as the/etc/resolv.conffile on its host node, which uses the default DNS server addresses 100.100.2.136 and 100.100.2.138. If you modify the DNS server configuration on the node, CoreDNS will use incorrect upstream DNS addresses, leading to resolution failures or unexpected results..:53 { ... forward . /etc/resolv.conf { prefer_udp } ... }
Managed CoreDNS
Managed CoreDNS works on the same principle as Unmanaged CoreDNS but is fully managed by ACK. It does not consume cluster resources and requires no O&M from you. It also autoscales based on the load. For more information, see Managed CoreDNS performance.
Managed CoreDNS is supported in ACK managed clusters with auto mode enabled. To use an ACK managed cluster with auto mode enabled, see Create an ACK managed cluster with auto mode enabled.
NodeLocal DNSCache
NodeLocal DNSCache configures a DNS cache on each worker node to reduce the load on CoreDNS and improve cluster DNS stability and availability. We recommend that you install this component in scenarios with high DNS load or strict requirements for DNS response speed and stability. To install and use the component, see Use the NodeLocal DNSCache component.
In the following example, after NodeLocal DNSCache is installed and the node-local-dns-injection: "enabled" label is added to the default namespace, a pod in the default namespace attempts to access database-svc and goes through the following process:
The pod first checks the DNS cache on its node.
The process proceeds in one of two ways, depending on whether a cache hit occurs:
A cache hit occurs if the node's DNS cache contains a record for
database-svc. The cache returns the result, and the pod uses this result to access the service.If a cache miss occurs, meaning the node's DNS cache does not have a record for
database-svc, the result is retrieved from CoreDNS. The result from CoreDNS is then cached in the node's DNS cache for future use.
Cluster DNS configuration
DNS in a cluster can be configured at three different levels, each with a different scope.
Cluster configuration
ClusterDomain is a kubelet configuration on each node. This configuration must be consistent across all kubelets in the cluster. Otherwise, network errors will occur.
ClusterDomainClusterDomain is the local top-level domain of a cluster and the default suffix for the full domain names of all Services within the cluster. The default value is
cluster.local. The ClusterDomain configuration is typically used to distinguish between in-cluster and out-of-cluster networks. When you create a cluster, you can customize the ClusterDomain. Ensure that the custom domain name does not conflict with commonly used external domain names.
Node configuration
resolveConfresolveConfspecifies the path to the DNS configuration file on the node. When a pod'sdnsPolicyisDefault, the kubelet copies the file specified byresolveConf(which defaults to/etc/resolv.conf) to the pod's/etc/resolv.conf.
Pod configuration
Each pod has two configurations to customize its DNS policy:
dnsPolicydefines the DNS resolution policy, anddnsConfigis used to specify custom DNS servers and search domains. For more information about how to usednsPolicyanddnsConfigtogether in different scenarios, see DNS Policy Configuration and Domain Name Resolution.