如前面的文章我们说了，kubernetes的服务发现是服务端发现模式。它有一个服务注册中心，使用DNS作为服务的注册表。每个集群都会运行一个DNS服务，默认是CoreDNS服务。每个服务都会在这个DNS中注册。注册的大致过程：
1、向kube-apiserver提交一个新服务对象的定义
2、创建服务对象，并分配它一个ClusterIP，保存服务对象数据到etcd中
3、DNS服务监听kube-apiserver，一旦有新服务对象创建就创建一个从服务对象名称映射到ClusterIP的域名记录。服务就是不需要主动去DNS中注册，靠DNS的控制器就能完成服务的自动注册。
一旦注册完成后，服务对象后面的Pod列表就会被更新。服务对象中的label selector字段与选择器中定义的标签相匹配的Pod就会纳入当前服务对象的Pod列表中。服务对象的选择控制器会持续扫描和服务对象的标签相匹配的Pod，然后更新到EndPoint对象中。
在kubernetes中，Pod列表对应一个EndPoint对象，这个对象负责保存一个和服务标签选择器相配匹的Pod列表。
每个Pod都要知道集群DNS服务地址，Pod容器的/etc/resolv.conf文件都被配置为使用集群的DNS进行解析。
在kubernetes中的DNS服务查询过程如下：
1、调用者向DNS服务发起域名（服务名称）查询，如果本地没有缓存就会被提交到DNS服务，DNS服务返回对应的ClusterIP。ClusterIP是服务对象的IP地址，并不是具体提供服务的Pod的IP地址。
2、通过返回的ClusterIP访问对应的Pod。kubernetes的每个节点（Node）上都有一个kube-proxy代理服务，这个代理会通过服务对象和Pod的对应关系创建iptables或IPVS路由规则，节点Node会基于这些规则将请求转发到具体的Pod上。
顺便提一下服务网格中边车代理（sidecar proxy），流量会首先被这个代理劫持，这是通过修改iptables路由规则来做到这一点的。其次服务网格也会监听集群内服务对象的变化情况，从而获得最的服务地址。最后一点是关于负载均衡，服务网络是基于服务对象而不是基于Pod的。它给服务对象前加上一层负载均衡，这样才能实现基于服务层面的流量管理。