本文详细介绍了Kubernetes中kube-proxy如何监控服务并实现负载均衡，重点讲解了iptables和IPVS模式的工作原理，以及它们在大规模服务中的性能优化。
监控集群中用户发布的服务，并完成负载均衡配置。
在建立好应用，服务要发布出去，那么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 模式下的转发规则：
扫一扫
1553
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
