Kubernetes Hacks and Tricks – #5 Pod DNS Policy and DNS Config options

What is dnsPolicy in Pod spec, and when should we change it? By setting the dnsPolicy option in Pod spec, you define how DNS requests should be resolved. If you want to resolve DNS requests with just the internal DNS server, or you want to use the internal DNS server first and then use upstream DNS, or resolve all of them using an external DNS server or something else, you can do it by configuring Pod’s dnsPolicy and dnsConfig options. In Kubernetes, DNS policy can be configured per Pod, which means you can customize the DNS resolving method for every Pod in your cluster.

Follow our social media:

https://www.linkedin.com/in/ssbostan

https://www.linkedin.com/company/kubedemy

https://www.youtube.com/@kubedemy

https://telegram.me/kubedemy

Allowed values in dnsPolicy option:

• Default Pod inherits the worker node’s DNS configuration.
• None All DNS configurations are ignored, and dnsConfig option will be used to configure Pod DNS configuration. Used for custom configuration.
• ClusterFirst use cluster DNS first, CoreDNS. If the DNS query does not match any domains in cluster DNS, forward it to upstream DNS servers.
• ClusterFirstWithHostNet in the case of using hostNetwork It first uses the cluster DNS server and then forwards unmatched queries to upstream DNS servers. Will be explained more in the following article.

Although it seems Default should be the default, but ClusterFirst is the default option. If you have not set this option, ClusterFirst will be used by default.

ClusterFirst (real default value):

Test result:

As you can see, the cluster’s DNS server resolved the request through 10.43.0.10 (CoreDNS IP address) using my cluster domain.

Default (its name is just Default, but it’s not default):

Test result:

As you can see, it used my node’s DNS server to resolve the DNS query, and because of that, it couldn’t resolve the cluster’s service names configured through CoreDNS. Moreover, it used the worker node’s domain instead of the cluster domain.

ClusterFirstWithHostNet:

Test result:

Though we run the Pod on the host network namespace, and it inherited the host DNS configuration, we can resolve Kubernetes services as well because our configuration says to try Cluster First, and if it can’t resolve, use the host DNS nameservers.

None (to customize DNS configuration):

Test result:

It tried to resolve the specified address with our search list through the Google DNS server, which shows you can configure Pod’s DNS configuration completely.

Note: To understand how containers resolve domains, see /etc/resolve.conf inside the container for every configuration explained above.

If you like this series of articles, please share them and write your thoughts as comments here. Your feedback encourages me to complete this massively planned program.

Follow my LinkedIn https://www.linkedin.com/in/ssbostan

Follow Kubedemy LinkedIn https://www.linkedin.com/company/kubedemy

Follow Kubedemy Telegram https://telegram.me/kubedemy