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: | ["22.214.171.124"]
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 126.96.36.199 nameserver 188.8.131.52 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)