1、LVS簡介
LVS的IP負載均衡技術是通過IPVS模塊實現的。IPVS模塊是LVS集羣的核心軟件模塊，它安裝在LVS集羣作爲負載均衡的主節點上，虛擬出一個IP地址和端口對外提供服務。用戶通過訪問這個虛擬服務（VS），然後訪問請求由負載均衡器（LB）調度到後端真實服務器（RS）中，由RS實際處理用戶的請求給返回響應。
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 模式之間有哪些差異呢？
- ipvs 爲大型集羣提供了更好的可擴展性和性能
- ipvs 支持比 iptables 更復雜的複製均衡算法（最小負載、最少連接、加權等等）
- ipvs 支持服務器健康檢查和連接重試等功能
ipvs 依賴 iptables
ipvs 會使用 iptables 進行包過濾、SNAT、masquared(僞裝)。具體來說，ipvs 將使用ipset來存儲需要DROP或masquared的流量的源或目標地址，以確保 iptables 規則的數量是恆定的，這樣我們就不需要關心我們有多少服務了。
如圖所示，前端調度器虛擬出 VS（Virtual Server）監聽和接收請求，真正提供服務的是後端的 Member（亦稱爲 RealServer 或者 RS），數個 Member 組成一個 Pool，VS 的請求分發到 Pool 上，並在 Pool 當中的 Member 之間按一定策略分發輪詢。
2、 調度模式
據負載均衡器轉發客戶端請求以及RS返回響應機制的不同，將IPVS的轉發模式分爲三種：NAT，DR，FULLNAT。（還有一種IP TUNNEL模式，IP通道技術，接觸比較少）
2.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.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，這時候客戶端無法識別響應包，會直接丟棄。
2.3 FULLNAT模式
FULLNAT模式下，LB會對請求包和響應包都做SNAT+DNAT。
FULLNAT模式的特點：
- LB完全作爲一個代理服務器
FULLNAT下，客戶端感知不到RS，RS也感知不到客戶端，它們都只能看到LB。此種模式和七層負載均衡有點相似，只不過不會去解析應用層協議，而是在TCP層將消息轉發
- LB和RS對於組網結構沒有要求
不同於NAT和DR要求LB和RS位於一個子網，FULLNAT對於組網結構沒有要求。只需要保證客戶端和LB、LB和RS之間網絡互通即可。
三種轉發模式性能從高到低：DR > NAT >FULLNAT。
雖然FULLNAT模式的性能比不上DR和NAT，但是FULLNAT模式沒有組網要求，允許LB和RS部署在不同的子網中，這給運維帶來了便利。並且 FULLNAT模式具有更好的可拓展性，可以通過增加更多的LB節點，提升系統整體的負載均衡能力。
3、LVS調度算法
1. 輪叫調度 rr
這種算法是最簡單的，就是按依次循環的方式將請求調度到不同的服務器上，該算法最大的特點就是簡單。輪詢算法假設所有的服務器處理請求的能力都是一樣的，調度器會將所有的請求平均分配給每個真實服務器，不管後端 RS 配置和處理能力，非常均衡地分發下去。
2. 加權輪叫 wrr
這種算法比 rr 的算法多了一個權重的概念，可以給 RS 設置權重，權重越高，那麼分發的請求數越多，權重的取值範圍 0 – 100。主要是對rr算法的一種優化和補充， LVS 會考慮每臺服務器的性能，並給每臺服務器添加要給權值，如果服務器A的權值爲1，服務器B的權值爲2，則調度到服務器B的請求會是服務器A的2倍。權值越高的服務器，處理的請求越多。
3. 最少鏈接 lc
這個算法會根據後端 RS 的連接數來決定把請求分發給誰，比如 RS1 連接數比 RS2 連接數少，那麼請求就優先發給 RS1
4. 加權最少鏈接 wlc
這個算法比 lc 多了一個權重的概念。
5. 基於局部性的最少連接調度算法 lblc
這個算法是請求數據包的目標 IP 地址的一種調度算法，該算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址所有使用的服務器，如果這臺服務器依然可用，並且有能力處理該請求，調度器會盡量選擇相同的服務器，否則會繼續選擇其它可行的服務器
6. 複雜的基於局部性最少的連接算法 lblcr
記錄的不是要給目標 IP 與一臺服務器之間的連接記錄，它會維護一個目標 IP 到一組服務器之間的映射關係，防止單點服務器負載過高。
7. 目標地址散列調度算法 dh
該算法是根據目標 IP 地址通過散列函數將目標 IP 與服務器建立映射關係，出現服務器不可用或負載過高的情況下，發往該目標 IP 的請求會固定發給該服務器。
8. 源地址散列調度算法 sh
與目標地址散列調度算法類似，但它是根據源地址散列算法進行靜態分配固定的服務器資源。
3、使用場景
我們都知道，我們一般用nginx或者haproxy來作爲我們的負載均衡，但是當併發超過nginx/haproxy上限時，就可以使用LVS了。日1000-2000W pv或併發請求1萬以上可以考慮LVS+nginx/haproxy的方案，如下圖所示。
4、LVS 高可用性
4.1 主播模式
在冗餘方面，LVS 分別支持主備模式和集羣模式。在主備模式下，LVS 可採用成熟的開源軟件 Keepalived 實現冗餘功能。在 LVS 主備方案實施當中，一臺爲主機正常提供服務，另外一臺提供熱備份。當主機離線時，備機會自動接管所有 VS，接替主機承擔負載均衡的職責。
Keepalived 參照了 VRRP 協議實現故障切換。LVS 的 Self IP 與 F5 的 Self IP 在概念上並不相同。LVS 不需要像 F5 那樣爲每臺設備的每個網段配置 Self IP，再配置一個不同於 Self IP 的 Float IP 對外提供服務。在 LVS 中，Self IP 直接對外提供服務，Fullnat 模式下還擁有不會隨主備切換的 Local Addres。在正常情況下，主機對外宣告 Self IP，備機沒有配置 IP，保持靜默。如果主機發生故障，備機會在一秒鐘內檢測到，產生故障切換事件，通過發送免費 ARP 宣告自己擁有 Self IP，引發流量切換。
Keepalived 可以指定某個網絡接口運行 VRRP 實例，爲了避免 VRRP 影響現有網絡，可以採用單獨的心跳線傳輸 Failover 流量。備機通過監聽 VRRP 通告確認主機是否存活，如果主備機因爲意外同時 ACTIVE，會導致嚴重的網絡故障，並且需要人爲干預才能恢復。爲了避免單根鏈路故障而導致的意外故障切換，建議心跳線採用兩根鏈路捆綁，可以大大降低故障機率。LVS 支持人爲的進行主備機倒換，但是並不具備 F5 的會話鏡像功能，因此在主備機倒換和故障切換之後，所有會話的連接性都會丟失。
4.2 集羣模式
集羣模式採用了 LVS ospf 方案，利用開源的軟路由軟件 quagga，對 IDC 接入交換機宣告 VIP 的主機路由信息，通過 OSPF 等價路由的特性可以提供最多八臺 LVS All-active 的集羣服務。在集羣模式下，LVS 可以橫向擴展，自由伸縮，但是會增加網絡的複雜性。
單 OSPF 區域，LVS 只能使用 DR 模式，與內網核心使用 TRUNK 連接，在每一個服務 VLAN 宣告 IP，並且所有後端服務器必須配置 LVS 爲網關，對網絡的要求和後端服務器的變動需求非常大。如果要使用 NAT 模式，需要 LVS 與內網核心也建立 OSPF 鄰居關係，將 SNAT IP 同時宣告給內網核心。
受限於 ospf 調度算法，集羣模式有可能無法提供無感知的伸縮特性。如果三層設備不支持 ospf 調度一致性 hash，那麼當某臺 LVS 離線的時候，所有長連接都會丟失。目前只有 Cisco 設備支持一致性 Hash 算法。
參考文檔：
https://blog.csdn.net/codebay118/article/details/72630066
https://www.cnblogs.com/bananaaa/p/7929796.html