监控集群中用户发布的服务，并完成负载均衡配置。
在建立好应用，服务要发布出去，那么proxy就要监控service对象完成负载均衡。
•
每个节点的Kube-Proxy都会
配置相同的负载均衡策略，使得整个集群的服务发现建立在分布
式负载均衡器之上，
服务调用无需经过额外的网络跳转（Network Hop）。
•
负载均衡配置基于不同插件实现：
•
userspace。
•
操作系统网络协议栈不同的 Hooks 点和插件：
•
iptables
•
ipvs
kube-proxy
kube-proxy 也是在每个节点上都运行的。它是实现Kubernetes Service 机制的重要组件。毫无意外，kube-proxy 也是一个“控制器”。它也从API Server 监听Service 和Endpoint对象的变化，并根据Endpoint 对象的信息设置Service 到后端Pod 的路由，维护网络规则，执行TCP、UDP 和SCTP 流转发。
如图1-16 所示，标签app=example 的Pod 都是此Service的后端Pod，他们的Pod IP 将会被Endpoint 控制器实时更新到Endpoint 对象中。此Serivce被分配的ClusterIP 为192.168.232.109，nodePort 为30004。Pod 的8080 端口映射到Service的80 端口。
也就是说，在集群内部通过192.168.232.109:80 就能访问此Service 的后端Pod 8080 端口提供的服务；集群外的主机可以通过nodeIP:30004 来访问此Service。
图1-16 Service 和Pod 的关系
kube-proxy
有两种模式都可以实现流量转发，分别是
iptables
模式和
IPVS
（IP Virtual Server）模式（可以通过参数
--proxy-mode
来指定）。
默认是
iptables
模式，该模式是通过每个节点上的iptables
规则来实现的。我们可以通过
iptables
命令查看相关的
iptables rules
：
- 从上面iptables rules 的代码片段来看，在集群内，用ClusterIP: 192.168.232.109（规则 ②）或 nodePort 30004（规则①）访问 Service 时，会被跳转到 Chain KUBE-SVC- BBVI5 ZF6XS3KVW42。
- 对于Chain KUBE-SVC-BBVI5ZF6XS3KVW42，它有三条可以跳转的路径（规则③④⑤）。当我们查询到规则③时，它将有33.33%的概率命中，并跳转到KUBE-SEP-RXBFMC7CATPNMAHP。如果规则③未命中，则接下来我们考虑规则④，它将有50%的概率进入Chain KUBE-SEP-CCTNN4A277RJLBDD。如果此条仍没有命中，就会进入 Chain KUBE-SEP-HJGBTFNTDVVP5Q3I。因此分别进入这三个Chain 的概率是一样的，kube-proxy 也是利用iptables 的这一特性实现流量的负载均衡。
随着
Service
数量的增大，
iptables
模式由于线性查找匹配、全量更新等特点，其性能会显著下降。从Kubernetes
的
1.8
版本开始，
kube-proxy
引入了
IPVS
模式，
IPVS
与
iptables同样基于
netfilter
，但是采用的是哈希表而且运行在内核态，当
Service
数量达到一定规模时，哈希表的查询速度优势就会显现出来，从而提高Service
的服务性能。我们可以通过
ipvsadm 命令查看
IPVS
模式下的转发规则：
