27 K8S 之服务发现

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

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

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

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 资源自动生成<service>.<ns>.svc.<zone>. <ttl> IN CNAME <extname>.格式的 DNS 资源记录。