如何進行容器SDN技術與微服務架構實踐

164次閱讀

共計 7298 個字符，預計需要花費 19 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關如何進行容器 SDN 技術與微服務架構實踐，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

關于 SDN 和容器

作為近年來比較熱的一個概念，眾所周知 SDN 是 Software Defined Network 的縮寫，即軟件定義網絡。但不同的人對 SDN 有不同的理解。在廣義上，只要是你通過軟件實現了一個東西，然后那個東西能夠靈活地去達到網絡上面的部署和伸縮，這就可以被認為是 SDN。在后文中會對 Flannel、Calico、Weave 這三個解決方案進行分析，并從控制層和轉發層來著重探討它們的技術實現，雖然它們并沒有宣稱自己是 SDN 的解決方案。

由于容器技術給傳統的虛擬化網絡提出了一些新的挑戰，所以圍繞 Docker 產生了很多不同的網絡解決方案，以彌補 Docker 在這些方面的不足。

圍繞容器的開源的 SDN 解決方案

Docker 自己的網絡方案比較簡單，就是每個宿主機上會跑一個非常純粹的 Linux Bridge，這個 Bridge 可以認為是一個二層的交換機，但它的能力有限，只能做一些簡單的學習和轉發。然后出來的流量，出網橋的流量會走 IPTABLES，做 NAT 的地址轉換，然后靠路由轉發去做一個宿主之間的通信。但是當真正用它的網絡模型部署一個比較復雜的業務時，會存在很多問題，比如容器重啟之后 IP 就變了；或者是由于每臺宿主機會分配固定的網段，因此同一個容器遷到不同宿主機時，它的 IP 可能會發生變化，因為它是在不同的網段；同時，NAT 的存在會造成兩端在通訊時看到對方的地址是不真實的，因為它被 NAT 過；并且 NAT 本身也是有性能損耗等。這些問題都對使用 Docker 自己的網絡方案造成了障礙。

Flannel

圖 1

Flannel 是 CoreOS 團隊針對 Kubernetes 設計的一個覆蓋網絡（Overlay Network）工具，如圖 1 所示。它們的控制平面其實很簡單，如圖 2 所示。

圖 2

每個機器上面的 Flannel 進程會監聽 ETCD，向 ETCD 申請每個節點可用的 IP 地址段，并且從 ETCD 拿到其他所有宿主機的網段信息，這樣它就可以做一些路由。對于它的轉發平面（圖 3）——轉發平面主要表現數據流的流向——它在 Docker 進來的網橋基礎之上，又創建了一個新的叫 VXLAN 的設備（圖 4），VXLAN 是一個隧道的方案，它可以把一個二層的包，前面加一個包頭，然后再把整個包作為物理網絡的一個包，去物理網絡里面去路由，流轉。

圖 3

圖 4

為什么會要有這個東西呢？因為通常虛擬網絡的 IP 和 MAC 在物理的網絡其實是不認識的。因為識別 IP 需要物理網絡支持，這個其實是個隧道的方案。

總結一下 Flannel 方案，可以看出它并沒有實現隔離，并且它也是按照網段做 IP 分配，即一個容器從一臺主機遷到另外一臺主機的時候，它的地址一定會變化。

Calico

圖 5

Calico 的思路比較新，如圖 5 所示。它把每個操作系統的協議棧認為是一個路由器，然后把所有的容器認為是連在這個路由器上的網絡終端，在路由器之間跑標準的路由協議——BGP 的協議，然后讓它們自己去學習這個網絡拓撲該如何轉發。所以 Calico 方案其實是一個純三層的方案，也就是說讓每臺機器的協議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。對于控制平面（圖 6），它每個節點上會運行兩個主要的程序，一個是它自己的叫 Felix，左邊那個，它會監聽 ECTD 中心的存儲，從它獲取事件，比如說用戶在這臺機器上加了一個 IP，或者是分配了一個容器等。接著會在這臺機器上創建出一個容器，并將其網卡、IP、MAC 都設置好，然后在內核的路由表里面寫一條，注明這個 IP 應該到這張網卡。綠色部分是一個標準的路由程序，它會從內核里面獲取哪一些 IP 的路由發生了變化，然后通過標準 BGP 的路由協議擴散到整個其他的宿主機上，讓外界都知道這個 IP 在這里，你們路由的時候得到這里來。

圖 6

關于 Calico 這里討論一個問題，因為它跑的是純三層的協議，所以其實它對物理架構有一定的侵入性。Calico 官方稱，你可以跑在一個大二層的網絡里面。所謂大二層就是沒有任何三層的網關，所有的機器、宿主機、物理機在二層是可達的。這個方案其實有一定的弊端，事實上在很多有經驗的網絡工程師眼里，一個大二層其實是一個單一的故障率，也就是說任何一個都會有一定的硬件風險會讓整個大二層癱瘓。

另外，Calico 跑在了一個三層網關的物理網絡上時，它需要把所有機器上的路由協議和整個物理網絡里面的路由器的三層路全部用 BGP 打通。這其實會帶來一個問題，這里的容器數量可能是成千上萬的，然后你讓所有物理的路由學習到這些知識，其實會給物理集群里的 BGP 路由帶來一定的壓力，這個壓力我雖然沒有測過，但據專業的網絡工程師告知，當網絡端點數達到足夠大的時候，它自我學習和發現拓撲以及收斂的過程是需要很多的資源和時間的。

轉發平面（圖 7）是 Calico 的優點。因為它是純三層的轉發，中間沒有任何的 NAT，沒有任何的 overlay，所以它的轉發效率可能是所有方案中最高的，因為它的包直接走原生 TCP/IP 的協議棧，它的隔離也因為這個棧而變得好做。因為 TCP/IP 的協議棧提供了一整套的防火墻的規則，所以它可以通過 IPTABLES 的規則達到比較復雜的隔離邏輯。

圖 7

Weave

圖 8

Weave 方案比較有趣，如圖 8 所示。首先它會在每臺機器上跑一個自己寫的 Router 程序起到路由器的作用，然后在路由器之間建立一個全打通的 PC 連接，接著在這張 TCP 的連接網里面互相跑路由協議，形成一個控制平面（圖 9）。可以看出，它的控制平面和 Calico 一致，而轉發平面（圖 10）則是走隧道的，這一點和 Flannel 一致，所以 Weave 被認為是結合了 Flannel 和 Calico 這兩個方案的特點。

圖 9

圖 10

圖 11 所示是它的服務發現與負載均衡的一個簡單的方案，它在每個容器會起兩個網卡，一個網卡連著自己起的可以跟其他宿主機聯通的網橋；另一個網卡綁在原生 Docker 的一個網橋上，并在這個網橋上監聽一個 DNS 的服務，這個 DNS 實際上嵌在 Router 里面，即它可以從 Router 里學習到一些服務的后端的一些配置。所以這時容器如果發起 DNS 查詢，實際上會被路由導到宿主機上，DNS Server 上，然后 DNS server 做一些響應。它們官方負載均衡也是靠這個，但是這其實是一個短板，因為我們更偏向于四層或者是七層更精細的負載均衡。

在隔離方面，Weave 的方案比較粗糙，只是子網級的隔離（圖 12）。比如說有兩個容器都處在 10.0.1-24 網段，那么它會在所有的容器里面加一條路由說該網段會走左邊的網橋出去，但是所有非此網段的流量會走 Docker0，這個時候 Docker0 和其他是不聯通的，所以它就達到一個隔離的效果。

圖 11

圖 12

三個方案總結

總結一下：

1. Flannel 僅僅作為單租戶的容器互聯方案還是很不錯的，但需要額外的組件去實現更高級的功能，例如服務發現與負載均衡。

2. Calico 有著良好的性能和隔離策略，但其基于三層轉發的原理對物理架構可能會有一定的要求和侵入性。

3. Weave 自帶 DNS，一定程度上能解決服務發現，但因隔離功能有限，若作為多租戶的聯通方案還稍加欠缺。

4. 另外，Calico 和 Weave 都使用了路由協議作為控制面，而自主路由學習在大規模網絡端點下的表現其實是未經驗證的，曾咨詢過相關的網絡工程師，大規模端點的拓撲計算和收斂往往需要一定的時間和計算資源。

七牛的具體實踐

業務需求

七牛實際上一直在擁抱容器帶來的變革，擁抱新型的微服務架構理念。所以構建了一套容器平臺，這么做的目的，一方面想推進通過將已有業務容器化簡化研發和上線流程，另一方面也想通過這個方式去滿足用戶的一些計算需求，畢竟計算和數據離得越近越好。

所以我們業務上對網絡的需求是：

1. 首先一點，是能夠運行在底層異構的基礎網絡上，這一點對于推進已有業務的容器化來說是很重要的，否則會涉及到基礎網絡的大規模變更，這是無法接受的。

2. 我們試圖構造一個對容器遷移友好的網絡結構，允許容器在必要情況下發生調度。

3. 我們認為服務發現和負載均衡對業務來說是個基礎而普適的需求，尤其是在倡導微服務架構的今天，一個設計良好的組件應該是可水平伸縮的，因此對于組件的調用方，服務發現和負載均衡是非常必要的功能。當然有人會說這個功能和網絡層無關，而應由應用層去實現，這個說法挺有道理，但后面我會講到由網絡層直接支持這兩個功能的好處。

4. 為了滿足七牛本身已有的一些對隔離有要求的服務，并滿足上層更豐富的權限模型和業務邏輯，我們試圖將隔離性做的更加靈活。

在這幾個需求的驅動下，我們最終嘗試跳出傳統網絡模型的束縛，嘗試去構造一個更加扁平而受控的網絡結構。

轉發平面

首先，在轉發層面，為了包容異構的基礎網絡，我們選擇了使用 Open vSwitch 構造 L2 overlay 模型，通過在 OVS 之間聯通 vxlan 隧道來實現虛擬網絡的二層互通。如圖 13 所示。但隧道通常是有計算成本的，隧道需要對虛擬二層幀進行頻繁解封包動作，而通用的 cpu 其實并不擅長這些。我們通過將 vxlan 的計算量 offload 到硬件網卡上，從而將一張萬兆網卡的帶寬利用率從 40% 提升到 95% 左右。

選擇 overlay 的另一個理由是，據我們目前所了解到，當下硬件的設備廠商在對 SDN 的支持上通常更偏向于 overlay 模型。

圖 13

控制平面

而在控制層面，我們思考了容器和傳統虛機的一些不同：

前面提到，微服務架構下，每個容器的職責相對虛機來說更加細化和固定，而這會造成容器與容器間的依賴關系也相對固定。那么每臺宿主機上的容器可能產生的 outbound 其實也是可推演的。如果進一步想的話，其實推演出來的理論范圍通常會遠大于容器實際產生的 outbound。所以我們嘗試使用被動的方式實現控制指令的注入。因此我們引入了 OpenFlow 作為控制面的協議。OpenFlow 作為目前 SDN 控制平面的協議標準，它有著很強的表達能力。從包匹配的角度看，它幾乎可匹配包頭中的任意字段，并支持多種流老化策略。此外，擴展性也很好，支持第三方的 Vendor 協議，可以實現標準協議中無法提供的功能 OpenFlow 可以按 Table 組織流表，并可在表間跳轉（這一點其實和 IPTABLES 很像，但 OpenFlow 的語義會更加豐富）。配合 OpenFlow 的這種 Table 組織方式，可以實現相對復雜的處理邏輯。如圖 14 所示。

圖 14

選擇了 OpenFlow，我們的控制平面會顯得很中規中矩，也就是邏輯上的集中式控制，沒有 weave/calico 的 P2P 那么炫酷。在這樣的結構下，當 ovs 遇到未知報文時，會主動提交包信息給 Controller，Controller 會根據包信息判斷后，給 ovs 下發合適的流表規則。為了實現負載均衡和高可用，我們給每組 ovs 配置多個 Controller。如圖 15 所示。

例如:

1. 對于非法流量 Controller 會讓 ovs 簡單丟棄，并在將來一段時間內不要再詢問。

2. 對于合法流量，Controller 會告訴 ovs 如何路由這個包并最終到達正確的目的地。

圖 15

服務發現和負載均衡

關于服務發現和負載均衡，我們提供了以下幾個對象模型：

1. Container，容器實例，多個 Container 構成一個 Pod（實體）。

2. Pod，每個 Pod 共享一個網絡棧，IP 地址和端口空間（實體）。

3. Service，多個相同 Pod 副本構成一個 Service，擁有一個 Service IP（邏輯）。

4. 安全組，多個 Service 構成一個安全組（邏輯）。

其中，可動態伸縮的關系是一個 Service 與其后端 Pod 的映射，這一步是靠平臺的自動服務發現來完成。只要發起對 Service IP 的訪問，那么 Service 本身就會完成服務發現和負載均衡的功能。后端 Pod 如果發生變動，調用方完全無需感知。

從實現上來說，我們將這個功能實現到了每個宿主機上，每個宿主機上的這個組件會直接代理本機產生的 Service 流量，這樣可以避免額外的內網流量開銷。

功能上，我們實現了 IP 級的負載均衡，什么意思，就是每個 Service IP 的可訪問端口與后端 Pod 實際監聽的端口是一致的，比如后端 Pod 監聽了 12345，那么直接訪問 Service IP 的 12345 端口，即可直接訪問，而無需額外的端口配置。

這里對比一下常見的幾種負載均衡：

1. 比 DNS 均衡更加精細。

2. 比端口級的負載均衡器更容易使用，對業務入侵更小。

另外，7 層的負載均衡實際上有很大的想象空間，我們實現了大部分 Nginx 的常用配置，使用者可以靈活配置。業務甚至還可以指定后端進行訪問。

安全組

在隔離層面，我們在邏輯上劃分了安全組，多個 service 組成一個安全組，安全組之間可以實現靈活的訪問控制。相同安全組內的容器可以互相不受限制的訪問。其中最常見的一個功能是，將安全組 A 中的某些特定的 Service Export 給另一組安全組 B。Export 后，安全組 B 內的容器則可以訪問這些導出的 Service，而不能訪問 A 中的其他 Service。如圖 16 所示。

圖 16

介紹完了我們網絡的基礎功能，這里通過分析兩個七牛的實際案例來說明這樣的結構是如何推動業務的架構演變的。

案例分析 1——七牛文件處理 FOP 架構演變

第一個是七牛的文件處理架構（File OPeration），如圖 17 所示。文件處理功能一直是七牛非常創新、也是很核心的一個功能，用戶在上傳了一個文件后，通過簡單地在資源 url 中添加一些參數，就能直接下載到按參數處理后的文件，例如你可以在一個視頻文件的 url 中添加一些參數，最終下載到一張在視頻某一幀上打了水印并旋轉 90 度并裁剪成 40×40 大小的圖片。

圖 17

而支撐這樣一個業務的架構，在早期是非常笨拙的。圖 17 左側是業務的入口，右側是實際進行計算的各種 worker 集群，里面包含了圖片處理，視頻處理，文檔處理等各種處理實例。

1. 集群信息寫死在入口配置中，后端配置變更不夠靈活。

2. 業務入口成為流量穿透的組件（業務的指令流與數據流混雜在一起）。

3. 突發請求情況下，應對可能不及時。

后面負責文件處理的同事將架構進化成了這樣（如圖 18）。

1. 增加 Discovery 組件，用于集群中 worker 信息的自動發現，每個 worker 被添加進集群都會主動注冊自己。

2. 業務入口從 Discovery 獲取集群信息，完成對請求的負載均衡。

3. 每個計算節點上新增 Agent 組件，用于向 Discovery 組件上報心跳和節點信息，并緩存處理后的結果數據（將數據流從入口分離），另外也負責節點內的請求負載均衡（實例可能會有多個）。

4. 此時業務入口只需負責分發指令流，但仍然需要對請求做節點級別的負載均衡。

圖 18

圖 19 描述的是文件處理架構遷移到容器平臺后的早期結構，較遷移之前有如下變更。

1. 每個 Agent 對應一個計算 worker，并按工種獨立成 Service，比如 Image Service，Video Service。

2. 取消業務的 Discovery 服務，轉由平臺自身的服務發現功能。

3. 每個 Agent 的功能退化：

無需和 Discovery 維護心跳，也不在需要上報節點信息。

由于后端只有一個 worker，因此也不需要有節點內的負載均衡邏輯。

4. 業務入口無需負載均衡，只需無腦地請求容器平臺提供的入口地址即可。

圖 19

圖 20 是遷移后發生的另一次演變，實際上上一個階段中，每個 Agent 仍然和計算實例綁定在一起，而這么做其實只是為了方便業務的無痛遷移，因為 Agent 本身的代碼會有一些邏輯上的假設。

這張圖中，我們進一步分離了 Agent 和 worker，Agent 獨立成一個 Service，所有的 worker 按工種獨立成 Service，這么分離的目的在于，Agent 是可能會有文件內容緩存、屬于有狀態的服務，而所有的 worker 是真正干活、無狀態的服務。分離之后的好處在于，worker 的數量可以隨時調整和伸縮，而不影響 Agent 中攜帶的狀態。

好處：

1. 可以看到，相比于最早的架構，業務方只需集中精力開發業務本身，而無需重復造輪子，實現各種復雜的服務發現和各種負載均衡的代碼。

2. 另外，自從部署到容器平臺之后，平臺的調度器會自動更具節點的資源消耗狀況做實例的遷移，這樣使得計算集群中每個節點的資源消耗更加均衡。

案例分析 2——用戶自定義文件處理 UFOP 架構演變

另一個案例是七牛的用戶自定義文件處理。

用戶自定義文件處理（User-defined File OPeration，UFOP）是七牛提供的用于運行用戶上傳的文件處理程序的框架。他的作用實際上和前面介紹的是一致的，只是允許用戶自定義他的計算實例。例如七牛現有的鑒黃服務，就是一個第三方的 worker，可以用于識別出一個圖片是否包含黃色內容。而正是由于引入了用戶的程序，所以 UFOP 在架構上和官方的 FOP 的不同在于，UFOP 對隔離有要求。

圖 20 是原本 UFOP 的架構，事實上，這里已經使用了容器技術進行資源上的隔離，所有的容器通過 Docker Expose 將端口映射到物理機，然后通過一個集中式的注冊服務，將地址和端口信息注冊到一個中心服務，然后入口分發服務通過這個中心服務獲取集群信息做請求的負載均衡。

而在網絡的隔離上，由于 Docker 自身的弱隔離性，這個架構中選擇了禁止所有的容器間通信，而只允許入口過來的流量。這個隔離尺度一定程度上限制了用戶自定義程序的靈活性。

圖 20