IPVS (IP Virtual Server)實現了傳輸層負載均衡，也就是我們常說的4層我們知道ipvs 會使用 iptables 進行包過濾、SNAT、masquared(偽裝)。
Linux負載均衡LVS（IPVS）
LVS是Linux Virtual Server的簡稱，也就是Linux虛擬服務器, 是一個由章文嵩博士發起的自由軟件項目，現在已經是 Linux標准內核的一部分。LVS是一種叫基於TCP/IP的負載均衡技術，轉發效率極高，具有處理百萬計並發連接請求的能力。
LVS的IP負載均衡技術是通過IPVS模塊實現的。IPVS模塊是LVS集群的核心軟件模塊，它安裝在LVS集群作為負載均衡的主節點上，虛擬出一個IP地址和端口對外提供服務。用戶通過訪問這個虛擬服務（VS），然后訪問請求由負載均衡器（LB）調度到后端真實服務器（RS）中，由RS實際處理用戶的請求給返回響應。
IPVS有三種轉發模式
1.DR模式（Direct Routing）
2.NAT模式（Network Address Translation）
3.FULLNAT模式
三種轉發模式性能從高到低：DR > NAT >FULLNAT。
1.DR模式（Direct Routing）
DR模式下，客戶端的請求包到達負載均衡器的虛擬服務IP端口后，負載均衡器不會改寫請求包的IP和端口，但是會改寫請求包的MAC地址為后端RS的MAC地址，然后將數據包轉發；真實服務器處理請求后，響應包直接回給客戶端，不再經過負載均衡器。所以DR模式的轉發效率是最高的，特別適合下行流量較大的業務場景，比如請求視頻等大文件。
DR模式的特點：
數據包在LB轉發過程中，源/目的IP端口都不會變化
LB只是將數據包的MAC地址改寫為RS的MAC地址，然后轉發給相應的RS。
每台RS上都必須在環回網卡上綁定LB的虛擬服務IP
因為LB轉發時並不會改寫數據包的目的IP，所以RS收到的數據包的目的IP仍是LB的虛擬服務IP。為了保證RS能夠正確處理該數據包，而不是丟棄，必須在RS的環回網卡上綁定LB的虛擬服務IP。這樣RS會認為這個虛擬服務IP是自己的IP，自己是能夠處理這個數據包的。否則RS會直接丟棄該數據包！
RS上的業務進程必須監聽在環回網卡的虛擬服務IP上，且端口必須和LB上的虛擬服務端口一致
因為LB不會改寫數據包的目的端口，所以RS服務的監聽端口必須和虛擬服務端口一致，否則RS會直接拒絕該數據包。
RS處理完請求后，響應直接回給客戶端，不再經過LB
因為RS收到的請求數據包的源IP是客戶端的IP，所以理所當然RS的響應會直接回給客戶端，而不會再經過LB。這時候要求RS和客戶端之間的網絡是可達的。
LB和RS須位於同一個子網
因為LB在轉發過程中需要改寫數據包的MAC為RS的MAC地址，所以要能夠查詢到RS的MAC。而要獲取到RS的MAC，則需要保證二者位於一個子網，否則LB只能獲取到RS網關的MAC地址。
2. NAT模式（Network Address Translation）
NAT模式下，請求包和響應包都需要經過LB處理。當客戶端的請求到達虛擬服務后，LB會對請求包做目的地址轉換（DNAT），將請求包的目的IP改寫為RS的IP。當收到RS的響應后，LB會對響應包做源地址轉換（SNAT），將響應包的源IP改寫為LB的IP。
NAT模式的特點：
LB會修改數據包的地址
對於請求包，會進行DNAT；對於響應包，會進行SNAT。
LB會透傳客戶端IP到RS（DR模式也會透傳）
雖然LB在轉發過程中做了NAT轉換，但是因為只是做了部分地址轉發，所以RS收到的請求包里是能看到客戶端IP的。
需要將RS的默認網關地址配置為LB的浮動IP地址
因為RS收到的請求包源IP是客戶端的IP，為了保證響應包在返回時能走到LB上面，所以需要將RS的默認網關地址配置為LB的虛擬服務IP地址。當然，如果客戶端的IP是固定的，也可以在RS上添加明細路由指向LB的虛擬服務IP，不用改默認網關。
LB和RS須位於同一個子網，並且客戶端不能和LB/RS位於同一子網
因為需要將RS的默認網關配置為LB的虛擬服務IP地址，所以需要保證LB和RS位於同一子網。
又因為需要保證RS的響應包能走回到LB上，則客戶端不能和RS位於同一子網。否則RS直接就能獲取到客戶端的MAC，響應包就直接回給客戶端了，不會走網關，也就走不到LB上面了。這時候由於沒有LB做SNAT，客戶端收到的響應包源IP是RS的IP，而客戶端的請求包目的IP是LB的虛擬服務IP，這時候客戶端無法識別響應包，會直接丟棄。
3. FULLNAT模式
FULLNAT模式下，LB會對請求包和響應包都做SNAT+DNAT。
FULLNAT模式的特點：
LB完全作為一個代理服務器
FULLNAT下，客戶端感知不到RS，RS也感知不到客戶端，它們都只能看到LB。此種模式和七層負載均衡有點相似，只不過不會去解析應用層協議，而是在TCP層將消息轉發
LB和RS對於組網結構沒有要求
不同於NAT和DR要求LB和RS位於一個子網，FULLNAT對於組網結構沒有要求。只需要保證客戶端和LB、LB和RS之間網絡互通即可。
雖然FULLNAT模式的性能比不上DR和NAT，但是FULLNAT模式沒有組網要求，允許LB和RS部署在不同的子網中，這給運維帶來了便利。並且 FULLNAT模式具有更好的可拓展性，可以通過增加更多的LB節點，提升系統整體的負載均衡能力。
IPVS支持的調度算法
對於后端的RS集群，LB是如何決策應該把消息調度到哪個RS節點呢？這是由負載均衡調度算法決定的。IPVS常用的調度算法有：
輪詢（Round Robin）
LB認為集群內每台RS都是相同的，會輪流進行調度分發。從數據統計上看，RR模式是調度最均衡的。
加權輪詢（Weighted Round Robin）
LB會根據RS上配置的權重，將消息按權重比分發到不同的RS上。可以給性能更好的RS節點配置更高的權重，提升集群整體的性能。
最小連接數（Least Connections）
LB會根據和集群內每台RS的連接數統計情況，將消息調度到連接數最少的RS節點上。在長連接業務場景下，LC算法對於系統整體負載均衡的情況較好；但是在短連接業務場景下，由於連接會迅速釋放，可能會導致消息每次都調度到同一個RS節點，造成嚴重的負載不均衡。
加權最小連接數（Weighted Least Connections）
最小連接數算法的加權版~
地址哈希（Address Hash）
LB上會保存一張哈希表，通過哈希映射將客戶端和RS節點關聯起來。
為什么使用IPVS，IPVS的應用場景
盡管 Kubernetes 在版本v1.6中已經支持5000個節點，但使用 iptables 的 kube-proxy 實
際上是將集群擴展到5000個節點的瓶頸。 在5000節點集群中使用 NodePort 服務，如
果有2000個服務並且每個服務有10個 pod，這將在每個工作節點上至少產生20000個
iptable 記錄，這可能使內核非常繁忙。
ipvs (IP Virtual Server) 實現了傳輸層負載均衡，也就是我們常說的4層LAN交換，作為
Linux 內核的一部分。ipvs運行在主機上，在真實服務器集群前充當負載均衡器。ipvs
可以將基於TCP和UDP的服務請求轉發到真實服務器上，並使真實服務器的服務在單個
IP 地址上顯示為虛擬服務。
ipvs vs iptables：
我們知道kube-proxy支持 iptables 和 ipvs 兩種模式， 在kubernetes v1.8 中引入了 ipvs
模式，在 v1.9 中處於 beta 階段，在 v1.11 中已經正式可用了。iptables 模式在 v1.1 中
就添加支持了，從 v1.2版本開始 iptables 就是 kube-proxy 默認的操作模式，ipvs 和
iptables 都是基於netfilter的。ipvs 會使用 iptables 進行包過濾、SNAT、masquared。
具體來說，ipvs 將使用ipset來存儲需要DROP或masquared的流量的源或目標地址，
以確保 iptables 規則的數量是恆定的，這樣我們就不需要關心我們有多少服務了。
啟動ipvs的要求：
- k8s版本 >= v1.11
- 使用ipvs需要安裝相應的工具來處理”yum install ipset ipvsadm -y“
- 確保 ipvs已經加載內核模塊， ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh、
- nf_conntrack_ipv4。如果這些內核模塊不加載，當kube-proxy啟動后，會退回到iptables模式。