转自：http://blog.itpub.net/28624388/viewspace-2155433/
1.Service在很多情况下只是一个概念，而真正将Service的作用实现的是kube-proxy服务进程。
2.每个Node节点上都会运行一个kube-proxy服务进程。
3.对每一个TCP类型的Kubernetes Service,kube-proxy都会在本地Node节点上建立一个SocketServer来负责接收请求，然后均匀发送到后端某个Pod的端口上。这个过程默认采用Round Robin负载均衡算法。
4.kube-proxy在运行过程中动态创建与Service相关的Iptables规则，这些规则实现了ClusterIp及NodePort的请求流量重定向到kube-proxy进程上对应服务的代理端口功能。
5.kube-proxy通过查询和监听API Server 中Service与Endpoints的变化，为每个Service都建立一个“服务代理对象”，并自动同步。服务代理对象是kube-proxy程序内部的一种数据结构，它包括一个用于监听此服务请求的SockerServer,SocketServer的端口是随机选择一个本地空闲端口。此外，kube-proxy内部创建了一个负载均衡器-LoadBalancer.
6.针对发生变化的Service列表，kube-proxy会逐个处理：
a. 如果没有设置集群IP，则不做任何处理，否则，取该Service的所有端口定义列表。
b.为Service端口分配服务代理对象并为该Service创建相关的Iptables规则。
c.更新负载均衡器组件中对应Service的转发地址列表
7.kube-proxy在启动时和监听到Service或Endpoint的变化后，会在本机Iptables的NAT表中添加4条规则链。
a.KUBE-PORTALS-CONTAINER: 从容器中通过Cluster IP 和端口号访问service.
b.KUBE-PORTALS-HOST: 从主机中通过Cluster IP 和端口号访问service.
c.KUBE-NODEPORT-CONTAINER:从容器中通过NODE IP 和端口号访问service.
d. KUBE-NODEPORT-HOST:从主机中通过Node IP 和端口号访问service.