2. 服务发现

## 概述

1. 服务发现机制的基本实现，一般是事先部署好一个网络位置较为稳定的服务注册中心（也称为服务总线），服务提供者（服务端）向注册中心注册自己的位置信息，并在变动后及时予以更新，相应地，服务消费者则周期性地从注册中心获取服务提供者的最新位置信息从而“发现”要访问的目标服务资源。复杂的服务发现机制还能够让服务提供者提供其描述信息、状态信息及资源使用信息等，以供消费者实现更为复杂的服务选择逻辑。
2. 根据服务发现过程的实现方式，服务发现还可分为两种类型：客户端发现和服务端发现。
- 客户端发现：由客户端到服务注册中心发现其依赖到的服务的相关信息，因此，它需要内置特定的服务发现程序和发现逻辑。
- 服务端发现：这种方式需要额外用到一个称为中央路由器或服务均衡器的组件；服务消费者将请求发往中央路由器或者负载均衡器，由它们负责查询服务注册中心获取服务提供者的位置信息，并将服务消费者的请求转发给服务提供者。
3. Kubernetes自1.3版本开始，其用于服务发现的DNS更新为了kubeDNS，自Kubernetes 1.11版本起，CoreDNS取代kubeDNS成为默认的DNS附件。不过，Kubernetes依然支持使用环境变量进行服务发现。

## 服务发现方式：环境变量
> 创建Pod资源时，kubelet会将其所属名称空间内的每个活动的Service对象以一系列环境变量的形式注入其中。

1. Kubernetes Service环境变量<br />Kubernetes为每个Service资源生成包括以下形式的环境变量在内的一系列环境变量，在同一名称空间中创建的Pod对象都会自动拥有这些变量。
- {SVCNAME}_SERVICE_HOST
- {SVCNAME}_SERVICE_PORT
2. Docker Link形式的环境变量<br />Docker使用--link选项实现容器连接时所设置的环境变量形式。在创建Pod对象时，Kubernetes也会将与此形式兼容的一系列环境变量注入Pod对象中。
- 在Service资源myapp-svc创建后创建的Pod对象中查看可用的环境变量，其中以KUBERNETES_SERVICE开头的表示Kubernetes Service环境变量，名称中不包含“SERVICE”字符串的环境变量为Docker Link形式的环境变量：

![未命名图片.png](/media/202406/6.2.15275334_image1.png)

3. 基于环境变量的服务发现其功能简单、易用，但存在一定的局限，例如，仅有那些与创建的Pod对象在同一名称空间中且事先存在的Service对象的信息才会以环境变量的形式注入，那些处于非同一名称空间，或者是在Pod资源创建之后才创建的Service对象的相关环境变量则不会被添加。

## ClusterDNS和服务发现

1. 集群中创建的每个Service对象，都会由其自动生成相关的资源记录。默认情况下，集群内各Pod资源会自动配置其作为名称解析服务器，并在其DNS搜索列表中包含它所属名称空间的域名后缀。
2. 无论是使用kubeDNS还是CoreDNS，它们提供的基于DNS的服务发现解决方案都会负责解析以下资源记录（Resource Record）类型以实现服务发现。
3. 拥有ClusterIP的Service资源，需要具有以下类型的资源记录。
- A记录：<service>.<ns>.svc.<zone>. <ttl> IN A <cluster-ip>
- SRV记录：_<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority><port-number> <service>.<ns>.svc.<zone>
- PTR记录：<d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <service>.<ns>.svc.<zone>
4. Headless类型的Service资源，需要具有以下类型的资源记录。
- A记录：<service>.<ns>.svc.<zone>. <ttl> IN A <endpoint-ip>
- SRV记录：_<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority><port-number> <hostname>.<service>.<ns>.svc.<zone>
- PTR记录：<d>.<c>.<b>.<a>.in-addr.arpa. <ttl> IN PTR <hostname>.<service>.<ns>.svc.<zone>
5. ExternalName类型的Service资源，需要具有CNAME类型的资源记录。
- CNAME记录：<service>.<ns>.svc.<zone>. <ttl> IN CNAME <extname>

## 服务发现方式：DNS

1. 创建Service资源对象时，ClusterDNS会为它自动创建资源记录用于名称解析和服务注册，于是，Pod资源可直接使用标准的DNS名称来访问这些Service资源。每个Service对象相关的DNS记录包含如下两个。
- {SVCNAME}.{NAMESPACE}.{CLUSTER_DOMAIN}
- {SVCNAME}.{NAMESPACE}.svc.{CLUSTER_DOMAIN}
2. 系统初始化时默认会将“cluster.local.”和主机所在的域“ilinux.io.”作为DNS的本地域使用，这些信息会在Pod创建时以DNS配置的相关信息注入它的/etc/resolv.conf配置文件中。例如，在此前创建的用于交互式Pod资源的客户端中查看其配置，命令如下：

![未命名图片.png](/media/202406/6.2.15275334_image2.png)

3. 上述search参数中指定的DNS各搜索域，是以次序指定的几个域名后缀，具体如下所示。
- {NAMESPACE}.svc.{CLUSTER_DOMAIN}：如default.svc.cluster.local。
- svc.{CLUSTER_DOMAIN}：如svc.cluster.local。
- {CLUSTER_DOMAIN}：如cluster.local。
- {WORK_NODE_DOMAIN}：如ilinux.io。