蓝盟IT小贴士，来喽！
Iptables模式
kube-proxy可以通过服务信息器感知API服务器中的服务和端点的变化。 作为对该事件的响应，在主机上创建这样的iptables规则。 可以在iptables-save上看到。 这些规则捕获服务的群集IP和端口流量，并随机重定向到服务后端Pod。 为每个endpoint对象生成选择后端Pod的iptables规则。
如果最初选择的Pod没有响应，kube-proxy会检测到第一个Pod连接失败，并自动重试另一个后端Pod。 拓扑图：
iptables是Linux内核功能，是一个高效的防火墙，提供大量的数据包处理和过滤功能。 可以通过Hook将一系列规则连接到核心数据包处理管线。 在iptables模式下，kube-proxy通过NAT预路由电话提供了NAT和负载平衡功能。 该方法简单、有效，依赖成熟的内核功能，可以与其他与iptables合作的APP友好相处。
因为这纯粹是为防火墙设计的，基于内核规则的列表，所以kube-proxy使用的是o(n )算法，其中的n随着集群的规模同步增加，所以这里的集群规模越大，
例如，如果在5000节点群集中使用节点端口服务，则如果有2000个服务，每个服务有10个pod，则每个工作节点至少会生成20000个iptable记录，从而导致内核非常繁忙。
结论：
kube-proxy在iptables中处理服务的过程实际上需要在主机上设置相当多的iptables规则。 此外，kube-proxy还需要在控制循环中不断更新这些规则，以确保总是正确的。 当你的主机有大量的Pod时，成百上千的iptables规则会不断更新，大量消耗该主机的CPU资源，在这个过程中让主机拥有“卡”是很容易的事情。 因此，以往，基于iptables的服务的实现是制约Kubernetes项目搭载更多订单的Pod的主要障碍。ipvs模式
在IPVS模式下，kube-proxy监视Kubernetes服务和端点，调用netlink接口创建IPVS规则，并将IPVS规则与Kubernetes服务和端点定期同步访问服务时，IPVS会向其中一个后端Pod发送流量。 IPVS代理模式基于netfilter挂接函数(如iptables模式)，但使用哈希表作为基础数据结构在内核空间中工作。 这意味着，IPVS模式下的kube-proxy重定向通信比iptables模式下的kube-proxy延迟更短，在同步代理规则时性能更高。 IPVS模式支持比其他代理模式更高的网络通信量。
IPVS模式的工作原理实际上与iptables模式类似。 创建上一个服务后，kube-proxy首先在主机上创建虚拟网卡“kube-ipvs0”，然后将服务VIP分配为IP地址。 然后，kube-proxy通过Linux IPVS模块将此IP地址设置为三个ipvs虚拟主机，并将轮询模式(rr )用于三个虚拟主机之间的负载平衡策略。 拓扑图如下所示。
IPVS是用于负载均衡的Linux内核功能。 在IPVS模式下，kube-proxy使用IPVS负载平衡而不是iptable。 这个模型也有效。 IPVS的设计用于大量服务的负载均衡。 有一组优化的API，使用优化的查找算法，而不是从列表中查找规则。
因此，在IPVS模式下，kube-proxy的连接过程的复杂性为o(1)。 也就是说，在很多情况下，他的连接处理效率与集群的规模无关。
作为独立的负载平衡器，IPVS还包括各种负载平衡算法，如轮询、最小期望延迟、最小连接和各种散列方法。 iptables只有一个随机平等的选择算法。 IPVS的一个潜在缺点是，与普通包相比，IPVS处理的包通过iptables过滤器hook的路径不同。 如果使用iptables的其他程序与IPVS一起使用，则需要考虑它们是否一起工作。 但是，Ipvs代理模式已经上市很久了，很多组件都适合Calico等。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
