kubernetes系列之五：IPVS概览

小鱼儿 2022-05-27 08:14 263阅读 0赞

## **一、前言** ##

IPVS是基于TCP四层(IP+端口)的负载均衡软件。

IPVS会从TCP SYNC包开始为一个TCP连接所有的数据包建立状态跟踪机制，保证一个TCP连接中所有的数据包能到同一个后端。所以IPVS是基于TCP状态机进行控制管理，只感知TCP头而不对TCP的payload进行查看；因此，对IPVS后端服务器集群还有一个假定，那就是所有后端都具有同样的应用层的服务功能，但是由于IPVS可以给后端设定权重，所以每个后端的服务的能力可以不同。

一个合理的负载均衡软件，应该能够尽量提高服务接入能力(ReqPS, Request Per Second)而将服务处理能力(ResPS, Response Per second)通过合理分配后端来达到最佳。

根据处理请求和响应数据包的模式的不同，IPVS具有如下四种工作模式：

*  NAT模式
 *  DR(Direct Routing)模式
 *  TUN(IP Tunneling)模式
 *  FULLNAT模式

而根据响应数据包返回路径的不同，可以分为如下两种模式：

*  双臂模式：请求、转发和返回在同一路径上，client和IPVS director、IPVS director和后端real server都是由请求和返回两个路径连接。
 *  三角模式：请求、转发和返回三个路径连接client、IPVS director和后端real server成为一个三角形。

转载自https://blog.csdn.net/cloudvtech

## **二、IPVS的基本构建** ##

IPVS系统由如下一些构建组成：

1.  Director：请求的入口，具有外网和内网多网络能力；由于director需要很高的ReqPS，所以可能需要微调它的CPU、NIC IRQ以及一些kernel IP/TCP能力参数(RPS、RFS、IRQ affinity、ARP配置)
2.  Virtual IP：具有外向暴露能力的外部IP，需要在director上绑定，根据模式不同，也有可能需要额外在real server进行绑定并且设定一些ARP参数和相应的iptables规则
3.  ![70][]
4.  Real Server：在应用层处理请求，产能返回结果。
5.  路由算法：分析数数据包头，维护和选择real server；路由算法需要维护一个TCP连接状态机。

转载自https://blog.csdn.net/cloudvtech

## **三、IPVS各种工作模式的分析和比较** ##

1.NAT模式

采用双臂模式，数据的进出都经过director；real server只需要内部IP、不需要在real server绑定外部IP；director需要处理返回数据包，容易成为瓶颈；需要后端分布在同一个局域网或者最低限度director需要设定为所有real server的网关；进出director的数据包需要进行请求数据包目的IP的替换和响应数据包的源IP的替换、请求的源IP可以被real server获取；可以进行端口转换；ReqPS和ResPS需要进行平衡。

2.TUN模式

采用三角模式，数据从director进入，响应从real server直接回到client；real server和director都要配置IP tunnel，real server需要配置外部IP并且绑定VIP；real server可以分布在互联网络的任何位置；请求的源IP可以被real server获取；不可以进行端口转换；director只需要处理请求数据包、ReqPS是最重要的指标。

3.DR模式

采用三角模式，数据从director进入，响应从real server直接回到client；real server需要配置外部IP并绑定VIP，并且real server需要分布在同一个局域网内；进出director的数据包需要进行请求数据包目的MAC地址的替换、请求的源IP可以被real server获取；不可以进行端口转换；director只需要处理请求数据包、ReqPS是最重要的指标。

4.FULLNAT模式

采用双臂模式，数据的进出都经过director；real server可以使用任何类型IP，只要和director可达即可；director需要处理返回数据包，容易成为瓶颈；real server可以分布在互联网络的任何位置；进出director的数据包需要进行请求数据源IP和包目的IP的替换和响应数据包的源IP和目的IP的替换、请求的源IP丢失(但是可以通过director修改数据包将源IP放在指定区域以被real server获取，但是需要修改director和real server的协议栈)；可以进行端口转换；ReqPS和ResPS需要进行平衡。

转载自https://blog.csdn.net/cloudvtech

## **四、IPVS使用场景分析** ##

互联网数据传输的一大特点是请求的数据传输量跟返回的数据传输量相比小到可以忽略，尤其是在现在多媒体和高清晰视图片和频的使用率越来越高的情况下，如何在director提高接入能力(处理请求包)的同时能完全发挥后端应用服务器集群的处理能力是一个亟待解决的问题。

在传统的服务器在内网提供对外网的服务能力的场景中，NAT和FULLNAT是比较合理的选择；在服务视频流的场景中，DR模式是更应该考虑的选择；在基于云提供商的场景中，NAT、FULLNAT或者TUN可能是合适的选择，或者直接使用云提供商的负载均衡服务；在基于容器的服务场景中，根据对于容器管理平台和容器主机的管理能力的不同，也需要选择合理的负载均衡服务。而在超大型分布式网络服务场景中，不仅后端需要具有集群服务的功能，承担流量接入的director本身也需要具有分布式的能力，并且需要保证后端能不借助director而将数据返回client，例如google的[Maglev][]。

转载自https://blog.csdn.net/cloudvtech

[70]: /images/20220527/8b482f8a2cd342288091606328db1116.png
[Maglev]: http://static.googleusercontent.com/media/research.google.com/zh-TW//pubs/archive/44824.pdf