爲什麼集羣需要 Overlay 網絡

爲什麼這麼設計(Why’s THE Design)是一系列關於計算機領域中程序設計決策的文章,我們在這個系列的每一篇文章中都會提出一個具體的問題並從不同的角度討論這種設計的優缺點、對具體實現造成的影響。如果你有想要了解的問題,可以在文章下面留言。

對計算機網絡或者 Kubernetes 網絡稍有了解的工程師都應該聽說過延展網絡(Overlay Network),Overlay 網絡其實並不是一門新技術,它是指構建在另一個網絡上的計算機網絡 [^1],這是一種網絡虛擬化技術的形式,近年來雲計算虛擬化技術的演進促進了網絡虛擬化技術的應用 [^2]。

overlay-network

圖 1 - 延展網絡

因爲 Overlay 網絡是建立在另一個計算機網絡之上的虛擬網絡,所以它不能獨立出現,Overlay 底層依賴的網絡就是 Underlay 網絡,這兩個概念也經常成對出現。

Underlay 網絡是專門用來承載用戶 IP 流量的基礎架構層,它與 Overlay 網絡之間的關係有點類似物理機和虛擬機。Underlay 網絡和物理機都是真正存在的實體,它們分別對應着真實存在的網絡設備和計算設備,而 Overlay 網絡和虛擬機都是依託在下層實體使用軟件虛擬出來的層級。

network-and-compute

圖 2 - 網絡與計算

在分析 Overlay 網絡的作用之前,我們需要對它的常見實現有大概的瞭解,在實踐中我們一般會使用虛擬局域網擴展技術(Virtual Extensible LAN,VxLAN)組建 Overlay 網絡。在下圖中,兩個物理機可以通過三層的 IP 網絡互相訪問:

VxLAN-overlay-network

圖 3 - VxLAN 組成的 Overlay 網絡

VxLAN 使用虛擬隧道端點(Virtual Tunnel End Point、VTEP)設備對服務器發出和收到的數據包進行二次封裝和解封。

上圖中兩個 VTEP 會相互連接並獲得網絡中的 MAC 地址、IP 地址等信息,例如,服務器 1 中的 VTEP 需要知道想要訪問綠色網絡中的 10.0.0.2 虛擬機需要先訪問 IP 地址爲 204.79.197.200 的服務器 2。這些配置可以被網絡管理員手動配置、自動學習、也可以通過上層的管理器設置。當綠色的 10.0.0.1 虛擬機想要向綠色的 10.0.0.2 發送數據時,會經過以下幾個步驟:

overlay-network-packet

圖 4 - Overlay 網絡中的數據包

  1. 綠色的 10.0.0.1 會將 IP 數據包發送給 VTEP;

  2. 服務器 1 的 VTEP 收到 10.0.0.1 發送的數據包後;

  3. 從收到的 IP 數據包中獲取目的虛擬機的 MAC 地址;

  4. 在本地的轉發表中查找該 MAC 地址所在服務器的 IP 地址,即 204.79.197.200;

  5. 將綠色虛擬機所在的虛擬網絡標識符(VxLAN Network Identifier、VNI)以及原始的 IP 數據包作爲負載,構建新的 UDP 數據包;

  6. 將新的 UDP 數據包發送到網絡中;

  7. 服務器 2 的 VTEP 收到 UDP 數據包後;

  8. 去掉 UDP 數據包中的協議頭;

  9. 查看數據包中 VNI;

  10. 將 IP 數據包轉發給目標的綠色服務器 10.0.0.2;

  11. 綠色的 10.0.0.2 會收到綠色服務器 10.0.0.1 發送的數據包;

在數據包的傳輸過程中,通信的雙方都不知道底層網絡做的這些轉換,它們認爲兩者可以通過二層的網絡互相訪問,但是實際上經過了三層 IP 網絡的中轉,通過 VTEP 之間建立的隧道實現了連通。除了 VxLAN 之外,Overlay 網絡還有很多實現方案,不過也都大同小異。Overlay 網絡雖然能夠利用底層網絡在多數據中心之間組成二層網絡,但是它的封包和拆包過程也會帶來額外開銷,所以爲什麼我們的集羣需要 Overlay 網絡呢,本文將介紹 Overlay 網絡解決的三個問題:

虛擬機遷移

Kuberentes 目前已經是容器編排領域的事實標準了,雖然很多傳統行業仍然在使用物理機部署服務,但是越來越多的計算任務在未來都會跑在虛擬機上。虛擬機遷移是將虛擬機從一個物理硬件設備移到另一個設備的過程,因爲日常的更新維護,集羣中的大規模虛擬機遷移是比較常見的事情,上千臺物理機組成的大集羣使得集羣內的資源調度變得更加容易,我們可以通過虛擬機遷移來提高資源的利用率、容忍虛擬機的錯誤並提高節點的可移植性 [^3]。

當虛擬機所在的宿主機因爲維護或者其他原因宕機時,當前實例就需要遷移到其他的宿主機上,爲了保證業務不中斷,我們需要保證遷移過程中的 IP 地址不變,因爲 Overlay 是在網絡層實現二層網絡,所以多個物理機之間只要網絡層可達就能組建虛擬的局域網,虛擬機或者容器遷移後仍然處於同一個二層網絡,也就不需要改變 IP 地址。

virtual-machine-migration

圖 5 - 跨數據中心的虛擬機遷移

如上圖所示,遷移後的虛擬機與其他的虛擬機雖然位於不同的數據中心,但是由於上述兩個數據中心之間可以通過 IP 協議連通,所以遷移後的虛擬機仍然可以通過 Overlay 網絡與原集羣的虛擬機組成二層網絡,集羣內部的主機也完全不清楚、不關心底層的網絡架構,它們只知道不同虛擬機之間是可以連通的。

虛擬機規模

我們在 爲什麼 Mac 地址不需要全球唯一 曾經介紹過二層網絡的通信需要依賴 MAC 地址,一個傳統的二層網絡需要網絡設備中存儲從 IP 地址到 MAC 地址的轉發表。

目前 Kuberentes 官方支持的最大集羣爲 5000 節點,如果這 5000 個節點中的每個節點都僅僅包含一個容器,這對於內部的網絡設備其實沒有太大的壓力,但是在實際情況下 5000 節點的集羣中都包含幾萬甚至幾十萬個容器,當某個容器向集羣中發送 ARP 請求,集羣中的全部容器都會收到 ARP 請求,這時會帶來極高的網絡負載。

在使用 VxLAN 搭建的 Overlay 網絡中,網絡會將虛擬機發送的數據重新封裝成 IP 數據包,這樣網絡只需要知道不同 VTEP 的 MAC 地址,由此可以將 MAC 地址表項中的幾十萬條數據降低到幾千條,ARP 請求也只會在集羣中的 VTEP 之間擴散,遠端的 VTEP 將數據拆包後也僅會在本地廣播,不會影響其他的 VTEP,雖然這對於集羣中的網絡設備仍然有較高的要求,但是已經極大地降低了核心網絡設備的壓力。

overlay-network-and-arp

圖 6 - Overlay 網絡中的 ARP 請求

Overlay 網絡其實與軟件定義網絡(Software-defined networking、SDN)[^4] 密切相關,而 SDN 引入了數據平面和控制平面,其中數據平面負責轉發數據,而控制平面負責計算並分發轉發表。VxLAN 的 RFC7348 中只定義了數據平面的內容,由該技術組成的網絡可以通過傳統的自學習模式學習網絡中的 MAC 與 ARP 表項 [^5],但是在大規模的集羣中,我們仍然需要引入控制平面分發路由轉發表。

網絡隔離

大規模的數據中心往往都會對外提供雲計算服務,同一個物理集羣可能會被拆分成多個小塊分配給不同的租戶(Tenant),因爲二層網絡的數據幀可能會進行廣播,所以出於安全的考慮這些不同的租戶之間需要進行網絡隔離,避免租戶之間的流量互相影響甚至惡意攻擊。傳統的網絡隔離會使用虛擬局域網技術(Virtual LAN、VLAN),VLAN 會使用 12 比特表示虛擬網絡 ID,虛擬網絡的上限是 4096 個。

vlan-header

圖 7 - VLAN 協議頭

4096 個虛擬網絡對於大規模的數據中心來說遠遠不夠,VxLAN 會使用 24 比特的 VNI 表示虛擬網絡個數,總共可以表示 16,777,216 個虛擬網絡,這也就能滿足數據中心多租戶網絡隔離的需求了。

VxLAN-packet

圖 8 - VxLAN 協議頭

更多的虛擬網絡其實是 VxLAN 順手帶來的好處,它不應該成爲使用 VxLAN 的決定性因素。VLAN 協議的擴展協議 IEEE 802.1ad 允許我們在以太網幀中加入兩個 802.1Q 的協議頭,兩個 VLAN ID 組成的 24 比特也可以表示 16,777,216 個虛擬網絡 [^6],所以想要解決網絡隔離不是使用 VxLAN 或者 Overlay 網絡的充分條件。

總結

今天的數據中心包含多個集羣以及海量的物理機,Overlay 網絡是虛擬機和底層網絡設備之間的中間層,通過 Overlay 網絡這一個中間層,我們可以解決虛擬機的遷移問題、降低二層核心網絡設備的壓力並提供更大規模的虛擬網絡數量:

需要注意的是,Overlay 網絡只是一種在物理網絡上的虛擬網絡,使用該技術並不能直接解決集羣中的規模性等問題,而 VxLAN 也不是組建 Overlay 網絡的唯一方法,在不同場景中我們可以考慮使用不同的技術,例如:NVGRE、GRE 等。到最後,我們還是來看一些比較開放的相關問題,有興趣的讀者可以仔細思考一下下面的問題:

如果對文章中的內容有疑問或者想要了解更多軟件工程上一些設計決策背後的原因,可以在博客下面留言,作者會及時回覆本文相關的疑問並選擇其中合適的主題作爲後續的內容。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/a1omUj17yNVUuymh6DYpRQ