K8s Service Registry+DNS
Service Registry 通过 Etcd 实现
客户端负载均衡
ClusterIP
一个服务一个 ClusterIP，这个IP后面跟的不是一个服务实例，而是一个服务实例集群，所以叫CLusterIP
Kube-DNS
消费者 Pod 不直接调用 ClusterIP，因为 ClusterIP 也会变，而是通过 服务名 ，<br>而服务名和ClusterIP的映射就是通过 Kube-DNS 解析的。
Kube_proxy
只负责服务发现和修改iptables规则
K8s服务发现流程
1. Pod 实例发布时，（通过 kind：Delooyment），kubelet 会负责启动 Pod 实例，<br> 启动完成后，kubelet 把 Pod IP 列表汇报给 Master 节点
2. Service 发布时，（通过kind：Service），K8s 会为 Service 分配 ClusterIP
3. 进行服务阶段时，Kube-Proxy 会监听Master 拿到ClusterIP 和 PodIP 列表的映射关系，<br>修改 iptables 转发规则，指示 iptables 在接收到 ClusterIP请求时，进行负载均衡并转发到对应的 Pod 上。
4. 进行服务调用时，一般通过 serviceName 先去 Kube-DNS 解析到 ClusterIP，<br>这个ClusetrIP 会被本地的 iptables 截获，通过负载均衡，转发到目标 Pod 上。
K8s 服务发现机制与 Eureka+Ribbon 机制的区别：
一，虽然都是 客户端负载均衡，但是 Ribbon 对客户端有侵入性。<br> 而 K8s 的Kube_proxy 是独立的，每个 Worker 节点都有一个。
二，Ribbon 代理转发是穿透的，而 K8s 的代理转发通过 iptables，
三，Ribbon 是 serviceName -> service 实例IP 的映射；<br> K8s 有两层映射：Kube_DNS 实现的 ServiceName -> ClusterIP<br> Kuber-Proxy 实现的 ClusterIP -> PodIP 的映射。
对比 K8s 服务发现机制和目前微服务主流的服务发现机制？
K8s 的服务发现机制明显抽象更好，<br>它通过 ClusterIP 统一屏蔽服务发现和负载均衡，一个服务一个ClusterIP。<br>并且对应用无侵入性。
