Minor nit: in the diagram labeled "the flow of a DNS query in Kubernetes," it says a DNS query is a syscall. That is incorrect: DNS lookups happen in userspace, not the kernel.<p>This is usually by calling a library function in libc, but sometimes not. For example, most programs written in Go (such as Kubernetes itself) use their own resolver instead of <a href="https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html" rel="nofollow">https://www.man7.org/linux/man-pages/man3/getaddrinfo.3.html</a> (or its predecessor, <a href="https://www.man7.org/linux/man-pages/man3/gethostbyname.3.html" rel="nofollow">https://www.man7.org/linux/man-pages/man3/gethostbyname.3.ht...</a>). This can lead to "fun" issues where the behavior between resolvers diverges, such as <a href="https://github.com/golang/go/issues/15419">https://github.com/golang/go/issues/15419</a>.
The author states:<p>>"When a pod performs a DNS lookup, the query is first sent to the local DNS resolver in the pod. This resolver uses the resolv.conf configuration file. In this file, the nodelocaldns server is set up as the default recursive DNS resolver, which acts as a cache."<p>and then:<p>>"Here's the TLDR. When a pod performs a DNS lookup, the query is first sent to the DNS cache on the node where the pod is running. If the cache does not contain the IP address for the requested hostname, the query is forwarded to the cluster DNS server."<p>It's somewhat bizarre to include an optional add-on component such a node-local DNS as part of a discussion about the default name resolution flow in Kubernetes. It is only towards the end of the post that the author mentions that node-local DNS is not actually a default component in Kubernetes.