Kubernetes cluster DNS service discovery principle

Cluster DNS service

A DNS service is deployed in the Kubernetes cluster, and the DNS service is exposed through the service name of kube-dns. You can execute the following command to view the service details of kube-dns.

kubectl get svc kube-dns -n kube-system

output:

The service backend is two Pods named coredns (the principle of CoreDNS resolution will be introduced below). You can execute the following command to view the Pod details of coredns.

kubectl get deployment coredns -n kube-system

output:

Intra-cluster Domain Name Resolution Principles

The kubelet on the Kubernetes cluster node has two dns-related parameters --cluster-dns=${dns-service-ip} and --cluster-domain=${default-local-domain}, which are used to set the cluster DNS server respectively IP address and primary domain name suffix.

View the contents of the DNS domain name resolution configuration file /etc/resolv.conf in the Pod in dnsPolicy:ClusterFirst (dnsPolicy will be introduced below) mode in the cluster default namespace.

The parameters are described as follows:

nameserver: Defines the IP address of the DNS server.

search: Set the search suffix rules for the domain name. The more search configurations, the more times the domain name resolution search matches. There are 3 suffixes for cluster matching: default.svc.cluster.local, svc.cluster.local, and cluster.local, and a maximum of 8 queries (four queries each for IPV4 and IPV6) can be used to obtain correct parsing results.

option: Define domain name resolution configuration file options, support multiple KV values. For example, if this parameter is set to ndots:5, it means that if the number of dot characters in the accessed domain name string exceeds the ndots value, it will be considered as a complete domain name and will be parsed directly; if it is less than the ndots value, the search segment suffix will be added before querying.

According to the above file configuration, try to resolve in the Pod:

Services under the same namespace, such as kubernetes: add a search domain once, and send kubernetes.default.svc.cluster.local. an ipv4 domain name resolution request to 172.24.0.10 for resolution.

Services under a cross-namespace, such as kube-dns.kue-system: add two search domains, sending kube-dns.kue-system.default.svc.cluster.local. and kube-dns.kue-system.svc. cluster.local. Two ipv4 domain name resolution requests to 172.24.0.10 can resolve the correct result.

Services outside the cluster, such as aliyun.com: add the search domain three times, and send aliyun.com.default.svc.cluster.local., aliyun.com.svc.cluster.local., aliyun.com.cluster.local. and aliyun. com Four times of ipv4 domain name resolution requests to 172.24.0.10 can resolve the correct result.

Pod dnsPolicy

The Kubernetes cluster supports configuring different DNS policies for each Pod through the dnsPolicy field. Four strategies are currently supported:

ClusterFirst: Domain name resolution is done through the cluster DNS service. The DNS service address configured in /etc/resolv.conf in the Pod is the kube-dns address of the cluster DNS service. This policy is the default for cluster workloads.

None: Ignore the cluster DNS policy, you need to provide the dnsConfig field to specify the DNS configuration information.

Default: Pod directly inherits the domain name resolution configuration of the cluster nodes. That is, the /etc/resolv.conf file of the node is directly used in the cluster.

ClusterFirstWithHostNetwork: Forces the use of the ClusterFirst strategy in hostNetWork network mode (Default strategy is used by default).

CoreDNS
CoreDNS is currently a standard service discovery component of Kubernetes. Pods in dnsPolicy: ClusterFirst mode will use CoreDNS to resolve domain names inside and outside the cluster.

The cluster has a configmap called coredns under the namespace kube-system. The file configuration content of its Corefile field is as follows (CoreDNS functions are provided through plug-ins in Corefile).

Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus:9153
forward ./etc/resolv.conf
cache 30
loop
reload
load balance
}
Among them, each plug-in description:

errors: Error messages to standard output.

health: CoreDNS's own health status report, the default listening port is 8080, which is generally used for health checks. You can get the health status through http://localhost:8080/health.
ready: CoreDNS plug-in status report, default listening port 8181, generally used for readability check. The readable status can be obtained through http://localhost:8181/ready. When all plugins are running, the ready status is 200.

kubernetes: CoreDNS kubernetes plug-in, which provides service resolution capabilities within the cluster.
prometheus: CoreDNS's own metrics data interface. Monitoring data in prometheus format can be obtained through http://localhost:9153/metrics.
forward (or proxy): forward the domain name query request to a predefined DNS server. In the default configuration, when the domain name is not in the kubernetes domain, the request is forwarded to the predefined resolver (/etc/resolv.conf). By default, the host's /etc/resolv.conf configuration is used.
cache: DNS cache.

loop: loop detection, if a loop is detected, stop CoreDNS.

reload: Allows automatic reloading of changed Corefiles. After editing the ConfigMap configuration, please wait two minutes for the changes to take effect.

loadbalance: A round-robin DNS load balancer that can randomize the order of A, AAAA, MX records in the answer.