ACK allows you to deploy NodeLocal DNSCache to improve the stability and performance of service discovery. NodeLocal DNSCache is implemented as a DaemonSet and runs a DNS caching agent on cluster nodes to improve the efficiency of DNS resolution for ACK clusters. This topic describes how to deploy and configure NodeLocal DNSCache for an application in an ACK cluster.
Prerequisites
- An ACK cluster is created. For more information, see Create an ACK managed cluster.
- A kubectl client is connected to the cluster. For more information, see Connect to ACK clusters by using kubectl.
Limits
- NodeLocal DNSCache does not support pods that run in serverless Kubernetes (ASK) clusters or on elastic container instances in managed or dedicated Kubernetes clusters.
- The Terway version must be 1.0.10.301 or later. If your cluster runs Terway in inclusive ENI mode based on IPVLAN, you must modify the configurations of Terway. For more information, see Modify the configurations of Terway.
- To install NodeLocal DNSCache, you can install ACK NodeLocal DNSCache on the Add-ons page or install ack-node-local-dns on the App Catalog page.
- NodeLocal DNSCache serves as a transparent caching proxy for CoreDNS and does not provide plug-ins such as hosts or rewrite. If you want to enable these plug-ins, modify the CoreDNS configurations.
- If you do not modify the configurations of CoreDNS before you use NodeLocal DNSCache, CoreDNS may fail to resolve external domain names. For more information, see Configure the default protocol for the Forward plug-in and upstream DNS servers of VPC.
Introduction
- The admission controller intercepts pod creation requests based on admission webhooks
and dynamically injects cached DNSConfig to pod configurations.
Note If you do not enable the admission controller to automatically inject DNSConfig, you must manually add DNS settings to pod configurations. For more information, see Method 2: Manually specify DNSConfig in Configure NodeLocal DNSCache for an application.
- The DaemonSet that runs a DNS cache on each node can create a virtual network interface.
By default, the virtual network interface listens for DNS queries that are sent to
the IP address 169.254.20.10. To change the IP address, Submit a ticket. DNS queries that are generated in pods are proxied by the DaemonSet based on pod
DNSConfig and node network settings.
Notice The DaemonSets that run DNS caches run on top of CoreDNS and provide only proxy and caching services. Do not enable other plug-ins such as hosts or rewrite.

No. | Description |
---|---|
1 | By default, a pod with the local DNSConfig injected uses NodeLocal DNSCache to listen for DNS queries that are sent to the IP address 169.254.20.10 on the node. |
2 | If NodeLocal DNSCache does not find a cache hit for the DNS query, the kube-dns Service is used to request CoreDNS to handle the query. |
3 | CoreDNS uses the DNS server deployed in the virtual private cloud (VPC) to resolve domain names that are not cluster-local. |
4 | If the pod with the local DNSConfig injected fails to connect to NodeLocal DNSCache, the pod uses the kube-dns Service to connect to CoreDNS for DNS resolution. |
5 | A pod without the local DNSConfig injected uses the kube-dns Service to connect to CoreDNS for DNS resolution. |
Install NodeLocal DNSCache
You can install NodeLocal DNSCache on the Add-ons page or the App Catalog page. We recommend that you install NodeLocal DNSCache on the Add-ons page.
Install NodeLocal DNSCache on the Add-ons page
- Log on to the ACK console.
- In the left-side navigation pane of the ACK console, click Clusters.
- On the Clusters page, find the cluster that you want to manage and choose in the Actions column.
- On the Add-ons page, click the Networking tab and find ACK NodeLocal DNSCache.
- Click Install. In the message that appears, click OK.
Install NodeLocal DNSCache on the App Catalog page
Configure NodeLocal DNSCache for an application
- Method 1: Use the admission controller to automatically inject DNSConfig when pods are created. We recommend that you use this method.
- Method 2: Manually specify DNSConfig when pods are created.
- Method 3: Modify kubelet parameters and restart kubelet. We recommend that you do not use this method because your business may be interrupted.
node-local-dns-injection=enabled
label. You can use the following command to add this label to a namespace. kubectl label namespace default node-local-dns-injection=enabled
- The preceding command enables automatic DNSConfig injection only for the default namespace.
To enable automatic DNSConfig injection for other namespaces, replace
default
based on your requirements. - If automatic DNSConfig injection is enabled for a namespace but you do not want to
automatically inject DNSConfig to some pods, you can add the
node-local-dns-injection=disabled
label to the templates of these pods.
dnsConfig:
nameservers:
- 169.254.20.10
- 172.21.0.10
options:
- name: ndots
value: "3"
- name: attempts
value: "2"
- name: timeout
value: "1"
searches:
- default.svc.cluster.local
- svc.cluster.local
- cluster.local
dnsPolicy: None
To enable automatic DNSConfig injection, the following conditions must be met. If DNSConfig is not automatically injected, check whether the conditions are met:
- Newly created pods do not belong to the kube-system or kube-public namespace.
- The namespace to which newly created pods belong has the
node-local-dns-injection=enabled
label. - The namespace to which newly created pods belong does not have labels related to Elastic
Container Instance-based pods, such as
virtual-node-affinity-injection
,eci
, andalibabacloud.com/eci
. - Newly created pods do not have labels related to elastic container instances, such
as
eci
andalibabacloud.com/eci
, or thenode-local-dns-injection=disabled
label. - Newly created pods use the
hostNetwork
network and theClusterFirstWithHostNet
DNS policy, or the pods do not use thehostNetwork
network but use theClusterFirst
DNS policy.
Method 2: Manually specify DNSConfig
apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: default
spec:
containers:
- image: alpine
command:
- sleep
- "10000"
imagePullPolicy: Always
name: alpine
dnsPolicy: None
dnsConfig:
nameservers: ["169.254.20.10","172.21.0.10"]
searches:
- default.svc.cluster.local
- svc.cluster.local
- cluster.local
options:
- name: ndots
value: "3"
- name: attempts
value: "2"
- name: timeout
value: "1"
- dnsPolicy: Set the value to
None
. - nameservers: Set the value to 169.254.20.10 and the cluster IP address of kube-dns.
- searches: Set the DNS search domains. Make sure that internal domain names can be resolved.
- ndots: You can improve resolution efficiency by setting this parameter to a smaller value. Default value: 5. For more information, see resolv.conf.
Method 3: Configure kubelet startup parameters
systemctl daemon-reload
and systemctl restart kubelet
commands for the changes to take effect. --cluster-dns=169.254.20.10 --cluster-dns=<kube-dns ip> --cluster-domain=<search domain>
- cluster-dns: specifies the DNS servers that are used in the pod configurations. By default, only
the IP address of
`kube-dns`
is specified. You must add the local IP address 169.254.20.10. - cluster-domain: specifies the DNS search domains that are used in the pod configurations. You can
use the existing search domain. In most cases, the existing search domain is
`cluster.local`
.
Example on how to configure NodeLocal DNSCache for an application
The following example shows how to configure NodeLocal DNSCache for a Deployment that is created in the default namespace.
Upgrade NodeLocal DNSCache
If you installed NodeLocal DNSCache on the Add-ons page, you must upgrade NodeLocal DNSCache on the Add-ons page. If you installed NodeLocal DNSCache on the App Catalog page, you must uninstall the current version of NodeLocal DNSCache on the Helm page and then install the latest version.
Upgrade NodeLocal DNSCache on the Add-ons page
Upgrade NodeLocal DNSCache on the App Catalog page
If you installed NodeLocal DNSCache on the App Catalog page, you must uninstall the current version of NodeLocal DNSCache and then install the latest version. For more information, see Uninstall NodeLocal DNSCache and Install NodeLocal DNSCache.
Uninstall NodeLocal DNSCache
If you installed NodeLocal DNSCache on the Add-ons page, you must uninstall NodeLocal DNSCache on the Add-ons page. If you installed NodeLocal DNSCache on the App Catalog page, you must uninstall NodeLocal DNSCache on the Helm page.
Uninstall NodeLocal DNSCache on the Add-ons page
Uninstall NodeLocal DNSCache on the App Catalog page
- Check the parameter settings.
- Uninstall NodeLocal DNSCache.
- In the left-side navigation pane of the ACK console, click Clusters.
- On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.
- In the left-side navigation pane of the details page, choose .
- On the Helm page, select ack-node-local-dns-default and click Delete in the Actions column. In the Clear Release Records message, click OK.
Modify CoreDNS
By default, NodeLocal DNSCache uses the TCP protocol to communicate with CoreDNS. CoreDNS communicates with the upstream servers based on the protocol used by the source of DNS queries. The DNS servers are deployed in the VPC where the cluster is deployed.
However, DNS servers in a VPC do not support TCP when they resolve domain names that are added to Alibaba Cloud DNS PrivateZone and the *.vpc-proxy.aliyuncs.com domain name provided by some cloud services. Therefore, NodeLocal DNSCache cannot resolve these domain names. To resolve these domain names, modify CoreDNS configurations based on the following modifications. This forces CoreDNS to use UDP as the default protocol when CoreDNS communicates with the upstream DNS servers in the VPC.
`perfer_udp`
. This way, CoreDNS preferentially uses the UDP protocol to communicate with upstream
servers. You can modify the setting based on the following modifications:# The original setting
forward . /etc/resolv.conf
# The modified setting
forward . /etc/resolv.conf {
prefer_udp
}