There are situations where one would prefer a Kubernetes workload to have an updated set of DNS nameservers, and there are two sets of solutions, ones that involve overriding host DNS resolution (so for example, the values in /etc/resolv.conf are overridden by a custom resolv.conf provided using various methods) or those scoped to the workload as part of the Pod spec. This piece will cover a few of those methods.
If you are using kube-dns, this can be updated cluster-wide using a ConfigMap like the following to specify your DNS nameservers:
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
upstreamNameservers: |
["8.8.8.8"]
In the alternative, a custom resolv.conf file can be provided to the Kubelet via its CLI flag, --resolv-conf string, so for example:
nameserver 8.8.8.8
nameserver 8.8.4.4
search ...
and the Kubelet will expose that alternative resolver configuration rather than the host's.
For multi-tenant configurations, a the Pod spec supports a dnsConfig block that allows you to build your desired resolution settings into your workload definitions, from the linked documentation:
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: dns-example
spec:
containers:
- name: test
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 192.0.2.1 # this is an example
searches:
- ns1.svc.cluster-domain.example
- my.dns.search.suffix
options:
- name: ndots
value: "2"
- name: edns0
The reason this would be advantageous for multi-tenant clusters is that it would allow specific workloads to use these DNS settings, rather than setting them for the cluster level, where a single-tenant might find this more desirable.
Here are some additional DNS-related resources for, both, updating resolvers and modifying other DNS services in Kubernetes:
Top comments (0)