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.