在遵循微服务架构设计理念的场景中，应用被拆分成众多小服务，各服务实例按需创建且变动频繁，配置信息基本无法事先写入配置文件中并及时跟踪反映动态变化，服务发现的重要性便随之凸显。

服务发现机制的基本实现，一般是事先部署好一个网络位置较为稳定的服务注册中心（也称为服务总线），由服务提供者（服务端）向注册中心注册自己的位置信息，并在变动后及时予以更新，相应地，服务消费方周期性地从注册中心获取服务提供者的最新位置信息，从而“发现”要访问的目标服务资源。复杂的服务发现机制还会让服务提供者提供其描述信息、状态信息及资源使用信息等，以供消费者实现更为复杂的服务选择逻辑。

服务消费者将请求发往中央路由器或者负载均衡器，由它们负责查询服务注册中心获取服务提供者的位置信息，并将服务消费者的请求转发给服务提供者。

KubeDNS由kubedns、dnsmasq和sidecar这3个部分组合而成。第一个部分包含kubedns和skydns两个组件，前者负责将Service和Endpoint转换为SkyDNS可以理解的格式；第二部分用于增强解析功能；第三部分为前两者添加健康状态检查机制。

每个Service对象都会具有以下3个类型的DNS资源记录。

1）根据ClusterIP的地址类型，为IPv4生成A记录，为IPv6生成AAAA记录。

2）为每个定义了名称的端口生成一个SRV记录，未命名的端口号则不具有该记录。

3）对于每个给定的A记录或AAAA记录都要生成PTR记录。

Kubernetes还支持在单个Pod资源规范上自定义DNS解析策略和配置，它们分别使用spec.dnsPolicy和spec.dnsConfig进行定义，并组合生效。Kubernetes支持如下DNS解析策略，它们定义在spec.dnsPolicy字段上。

CoreDNS是高度模块化的DNS服务器，几乎全部功能均由可插拔的插件实现。CoreDNS调用的插件及相关的配置定义在称为Corefile的配置文件中。CoreDNS主要用于定义各服务器监听地址和端口、授权解析的区域以及加载的插件等。

Kubernetes把这类不具有ClusterIP的Service资源形象地称为Headless Service，该Service的请求流量无须kube-proxy处理，也不会有负载均衡和路由相关的iptables或ipvs规则。至于ClusterDNS如何自动配置Headless Service，则取决于Service标签选择器的定义。

有标签选择器：由端点控制器自动创建与Service同名的Endpoint资源，而ClusterDNS则将Service名称的A记录直接解析为后端各端点的IP而非ClusterIP。

无标签选择器：ClusterDNS的配置分为两种情形，为ExternalName类型的服务（配置了spec.externalName字段）创建CNAME记录，而为与该Service同名的Endpoint对象上的每个端点创建一个A记录。

ExternalName Service是一种特殊类型的Service资源，它不需要使用标签选择器关联任何Pod对象，也无须定义任何端口或Endpoints，但必须要使用spec.externalName属性定义一个CNAME记录，用于返回真正提供服务的服务名称的别名。ClusterDNS会为这种类型的Service资源自动生成..svc.. IN CNAME .格式的DNS资源记录。