Docs

Volcengine Kubernetes Engine

DNS

Using NodeLocal DNSCache as a DNS caching proxy

NodeLocal DNSCache cache solution provides a DNS cache proxy for nodes, improving DNS service discovery performance and stability across the entire cluster. This topic describes how to configure NodeLocal DNSCache in a cluster.

Background information

In large-scale applications, overwhelming DNS requests place significant pressure on CoreDNS, resulting in increased DNS latency and adversely affecting business performance. To improve performance, users often need to upgrade CoreDNS specifications or perform scale-out, which increases operation and maintenance complexity, yet delivers a disappointing result.

To address the above issues, Kubernetes officially provides the NodeLocal DNSCache solution, which can effectively improve DNS performance and stability in large-scale clusters. In a VKE cluster, the node-local-dns add-on can be used as the NodeLocal DNSCache for the cluster. This add-on runs in a DaemonSet on each node in the cluster, working as a DNS cache proxy on nodes to improve the performance and stability of DNS service discovery in the cluster.

DNS cache configuration is injected into pods as soon as node-local-dns add-on is installed in the cluster. After that, the DNS resolution will take the following steps:

NodeLocal DNSCache resolution: Pods first send queries to NodeLocal DNSCache (169.254.20.10) on their nodes. If NodeLocal DNSCache is unreachable or a cache miss occurs, the queries are sent to CoreDNS in the cluster.

CoreDNS resolution: If NodeLocal DNSCache does not have a cached response for the query, the query is sent to CoreDNS (10.0.0.10) through the kube-dns service for resolution.

tip

For more details on NodeLocal DNSCache, see Kubernetes documentation.

Limits

When a VCI-type Pod uses the NodeLocal DNSCache feature, the node-local-dns add-on must first be upgraded to v0.3.1 or later. For details, see Add-on release record.

NodeLocal DNSCache requires the vpc-cni add-on v1.3.0 or later. For details, see Add-on release records.

After the node-local-dns add-on is installed in the cluster and NodeLocal DNSCache is enabled, NodeLocal DNSCache takes effect only for newly created Pods.

Prerequisites

The node-local-dns add-on has been installed. For details, see node-local-dns.

Application scenarios

Scenario 1: Use automatic injection

After node-local-dns add-on is installed, the newly created pods in a cluster will be injected with the dnsConfig settings by the system to enable access to NodeLocal DNSCache.

Except for the following types of pods:

Pods belong to the kube-system and kube-public namespaces.

Pods with namespaces or labels that contain dns-config-injection=disable.

Pods that are running on hostNetwork and have DNSPolicy set to ClusterFirstWithHostNet, or those not running on hostNetwork and have DNSPolicy set to ClusterFirst.

Taking the pods with the default namespace as an example, the following dnsConfig settings are injected by the system.

To ensure maximum availability of DNS service, the ClusterIP address (10.0.10.1) of kube-dns will also be added to the nameservers as a backup DNS server.

Scenario 2: Disable automatic injection

If necessary, you can disable NodeLocal DNSCache with the following methods.

Namespace dimension

Pod dimension

Execute the following command to disable the dnsConfig setting for all newly created pods in the specified namespace.

Scenario 3: Configure manually

You can configure NodeLocal DNSCache if the automatic injection does not meet your requirements. Procedure:

For how to disable automatic injection to pods, see Disabli automatic injection.

Manually configure NodeLocal DNSCache for pods. The following are example settings for the pods in the default namespace.

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx:latest
name: container-0
dnsPolicy: None
dnsConfig:
nameservers: ["169.254.20.10","172.21.0.10"] # DNS server IP addresses
searches: # Complete domain names to be used when only partial domain names are found in requests
- default.svc.cluster.local
- svc.cluster.local
- cluster.local
options:
- name: ndots # Metric to determine if a domain name is complete. If the number of dots in a domain name exceeds the value, DNS resolution starts immediately. If the number of dots in a domain name is less than the value, the domains under the searches are used accordingly to fulfill DNS resolution.
value: "3"
- name: attempts # Number of retry attempts when the DNS resolution fails
value: "2"
- name: timeout # Timeout for a single DNS resolution request, measured in seconds
value: "1"
imagePullSecrets:
- name: default-secret
...

tip

You can also use kubelet with the --cluster-dns and --cluster-domain parameters to globally control pod dnsConfig. However, this is not a recommended method. If you find it necessary to use that method, you can submit a ticket for consultation.