干货 | 云计算时代携程的网络架构变迁
作者簡(jiǎn)介
趙亞楠，攜程云平臺(tái)資深架構(gòu)師。2016 年加入攜程云計(jì)算部門，先后從事 OpenStack、SDN、容器網(wǎng)絡(luò)（Mesos、K8S）、容器鏡像存儲(chǔ)、分布式存儲(chǔ)等產(chǎn)品的開(kāi)發(fā)，目前帶領(lǐng) Ctrip Cloud Network & Storage Team，專注于網(wǎng)絡(luò)和分布式存儲(chǔ)研發(fā)。
?
本文介紹云計(jì)算時(shí)代以來(lái)攜程在私有云和公有云上的幾代網(wǎng)絡(luò)解決方案。希望這些內(nèi)容可以給業(yè)內(nèi)同行，尤其是那些設(shè)計(jì)和維護(hù)同等規(guī)模網(wǎng)絡(luò)的團(tuán)隊(duì)提供一些參考。
本文將首先簡(jiǎn)單介紹攜程的云平臺(tái)，然后依次介紹我們經(jīng)歷過(guò)的幾代網(wǎng)絡(luò)模型：從傳統(tǒng)的基于 VLAN 的二層網(wǎng)絡(luò)，到基于 SDN 的大二層網(wǎng)絡(luò)，再到容器和混合云場(chǎng)景下的網(wǎng)絡(luò)，最后是 cloud native 時(shí)代的一些探索。
一、攜程云平臺(tái)簡(jiǎn)介
攜程 Cloud 團(tuán)隊(duì)成立于 2013 年左右，最初是基于 OpenStack 做私有云，后來(lái)又開(kāi)發(fā)了自己的 baremetal（BM）系統(tǒng)，集成到 OpenStack，最近幾年又陸續(xù)落地了 Mesos 和 K8S 平 臺(tái)，并接入了公有云。
目前，我們已經(jīng)將所有 cloud 服務(wù)打造成一個(gè)?CDOS — 攜程數(shù)據(jù)中心操作系統(tǒng)的混合云平臺(tái)，統(tǒng)一管理我們?cè)谒接性坪凸性粕系挠?jì)算、網(wǎng)絡(luò) 、存儲(chǔ)資源。
Fig 1. Ctrip Datacenter Operation System (CDOS)在私有云上，我們有虛擬機(jī)、應(yīng)用物理機(jī)和容器。在公有云上，接入了亞馬遜、騰訊云、UCloud 等供應(yīng)商，給應(yīng)用部門提供虛擬機(jī)和容器。所有這些資源都通過(guò) CDOS API 統(tǒng)一管理。
網(wǎng)絡(luò)演進(jìn)時(shí)間線
Fig 2. Timeline of the Network Architecture Evolution圖 2 是我們網(wǎng)絡(luò)架構(gòu)演進(jìn)的大致時(shí)間線。
最開(kāi)始做 OpenStack 時(shí)采用的是簡(jiǎn)單的 VLAN 二層網(wǎng)絡(luò)，硬件網(wǎng)絡(luò)基于傳統(tǒng)的三層網(wǎng)絡(luò)模型。
隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大，這種架構(gòu)的不足逐漸顯現(xiàn)出來(lái)。因此，在 2016 年自研了基于 SDN 的大二層網(wǎng)絡(luò)來(lái)解決面臨的問(wèn)題，其中硬件架構(gòu)換成了 Spine-Leaf。
2017年，我們開(kāi)始在私有云和公有云上落地容器平臺(tái)。在私有云上，對(duì) SDN 方案進(jìn)行了擴(kuò)展和優(yōu)化，接入了 Mesos 和 K8S 平臺(tái)，單套網(wǎng)絡(luò)方案同時(shí)管理了虛擬機(jī)、應(yīng)用物理機(jī)和容器網(wǎng)絡(luò)。公有云上也設(shè)計(jì)了自己的網(wǎng)絡(luò)方案，打通了混合云。
最后是 2019 年，針對(duì) Cloud Native 時(shí)代面臨的一些新挑戰(zhàn)，我們?cè)谡{(diào)研一些新方案。
二、基于 VLAN 的二層網(wǎng)絡(luò)
2013 年我們開(kāi)始基于 OpenStack 做私有云，給公司的業(yè)務(wù)部門提供虛擬機(jī)和應(yīng)用物理機(jī)資源。
2.1 需求
網(wǎng)絡(luò)方面的需求有：
首先，性能不能太差，衡量指標(biāo)包括 instance-to-instance 延遲、吞吐量等等。
第二，二層要有必要的隔離，防止二層網(wǎng)絡(luò)的一些常見(jiàn)問(wèn)題，例如廣播泛洪。
第三，實(shí)例的 IP 要可路由，這點(diǎn)比較重要。這也決定了在宿主機(jī)內(nèi)部不能使用隧道技術(shù)。
第四，安全的優(yōu)先級(jí)可以稍微放低一點(diǎn)。如果可以通過(guò)犧牲一點(diǎn)安全性帶來(lái)比較大的性能提升，在當(dāng)時(shí)也是可以接受的。而且在私有云上，還是有其他方式可以彌補(bǔ)安全性的不足。
2.2 解決方案：OpenStack Provider Network 模型
經(jīng)過(guò)一些調(diào)研，我們最后選擇了 OpenStack?provider network?模型 [1]。
Fig 3. OpenStack Provider Network Model如圖 3 所示。宿主機(jī)內(nèi)部走二層軟交換，可以是 OVS、Linux Bridge、或者特定廠商的方案；宿主機(jī)外面，二層走交換，三層走路由，沒(méi)有 overlay 封裝。
這種方案有如下特點(diǎn)：
首先，租戶網(wǎng)絡(luò)的網(wǎng)關(guān)要配置在硬件設(shè)備上，因此需要硬件網(wǎng)絡(luò)的配合，而并不是一個(gè)純軟件的方案；
第二，實(shí)例的 IP 是可路由的，不需要走隧道；
第三，和純軟件的方案相比，性能更好，因?yàn)椴恍枰淼赖姆庋b和解封裝，而且跨網(wǎng)段的路由都是由硬件交換機(jī)完成的。
方案的一些其他方面：
1）二層使用 VLAN 做隔離
2）ML2 選用 OVS，相應(yīng)的 L2 agent 就是 neutron ovs agent
3）因?yàn)榫W(wǎng)關(guān)在硬件交換機(jī)上，所以我們不需要 L3 agent（OpenStack 軟件實(shí)現(xiàn)的虛擬路由器）來(lái)做路由轉(zhuǎn)發(fā)
4）不用 DHCP
5）沒(méi)有 floating ip 的需求
6）出于性能考慮，我們?nèi)サ袅?security group
2.3 硬件網(wǎng)絡(luò)拓?fù)?/strong>
圖 4 是我們的物理網(wǎng)絡(luò)拓?fù)?#xff0c;最下面是服務(wù)器機(jī)柜，上面的網(wǎng)絡(luò)是典型的接入-匯聚-核心三層架構(gòu)。
Fig 4. Physical Network Topology in the Datacenter特點(diǎn)：
1）每個(gè)服務(wù)器兩個(gè)物理網(wǎng)卡，直連到兩個(gè)置頂交換機(jī)做物理高可用
2）匯聚層和接入層走二層交換，和核心層走三層路由
3）所有 OpenStack 網(wǎng)關(guān)配置在核心層路由器
4）防火墻和核心路由器直連，做一些安全策略
2.4 宿主機(jī)內(nèi)部網(wǎng)絡(luò)拓?fù)?/strong>
再來(lái)看宿主機(jī)內(nèi)部的網(wǎng)絡(luò)拓?fù)洹D 5 是一個(gè)計(jì)算節(jié)點(diǎn)內(nèi)部的拓?fù)洹?/p>
Fig 5. Designed Virtual Network Topology within A Compute Node
特點(diǎn)：
1）首先，在宿主機(jī)內(nèi)有兩個(gè) OVS bridge：br-int?和?br-bond，兩個(gè) bridge 直連
2）有兩個(gè)物理網(wǎng)卡，通過(guò) OVS 做 bond。宿主機(jī)的 IP 配置在?br-bond?上作為管理 IP
3）所有實(shí)例連接到?br-int
圖中的兩個(gè)實(shí)例屬于不同網(wǎng)段，這些標(biāo)數(shù)字的（虛擬和物理）設(shè)備連接起來(lái)，就是兩個(gè)跨網(wǎng)段的實(shí)例之間通信的路徑：inst1?出來(lái)的包經(jīng)?br-int?到達(dá)?br-bond，再經(jīng)物理網(wǎng)卡出宿主機(jī)，然后到達(dá)交換機(jī)，最后到達(dá)路由器（網(wǎng)關(guān)）；路由轉(zhuǎn)發(fā)之后，包再經(jīng)類似路徑回到?inst2，總共是18跳。
作為對(duì)比，圖 6 是原生的 OpenStack?provider network?模型。
Fig 6. Virtual Network Topology within A Compute Node in Legacy OpenStack這里最大的區(qū)別就是每個(gè)實(shí)例和?br-int?之間都多出一個(gè) Linux bridge。這是因?yàn)樵?OpenStack 支持通過(guò) security group 對(duì)實(shí)例做安全策略，而 security group 底層是基于 iptables 的。OVS port 不支持?iptables?規(guī)則，而 Linux bridge port 支持，因此 OpenStack 在每個(gè)實(shí)例和 OVS 之間都插入了一個(gè) Linux Bridge。在這種情況下，inst1 -> inst2?總共是 24 跳，比剛才多出 6 跳。
2.5 小結(jié)
最后總結(jié)一下我們第一代網(wǎng)絡(luò)方案。
優(yōu)點(diǎn)：
首先，我們?nèi)サ袅艘恍┎挥玫?OpenStack 組件，例如 L3 agent、HDCP agent, Neutron meta agent 等等，簡(jiǎn)化了系統(tǒng)架構(gòu)。對(duì)于一個(gè)剛開(kāi)始做 OpenStack、經(jīng)驗(yàn)還不是很豐富的團(tuán)隊(duì)來(lái)說(shuō)，開(kāi)發(fā)和運(yùn)維成本比較低。
第二，上面已經(jīng)看到，我們?nèi)サ袅?Linux Bridge，簡(jiǎn)化了宿主機(jī)內(nèi)部的網(wǎng)絡(luò)拓?fù)?#xff0c;這使得轉(zhuǎn)發(fā)路徑更短，實(shí)例的網(wǎng)絡(luò)延遲更低。
第三，網(wǎng)關(guān)在硬件設(shè)備上，和 OpenStack 的純軟件方案相比，性能更好。
第四，實(shí)例的 IP 可路由，給跟蹤、監(jiān)控等外圍系統(tǒng)帶來(lái)很大便利。
缺點(diǎn)：
首先，去掉了 security group，沒(méi)有了主機(jī)防火墻的功能，因此安全性變?nèi)酢Ｎ覀兺ㄟ^(guò)硬件防火墻部分地補(bǔ)償了這一問(wèn)題。
第二，網(wǎng)絡(luò)資源交付過(guò)程還沒(méi)有完全自動(dòng)化，并且存在較大的運(yùn)維風(fēng)險(xiǎn)。?provider network?模型要求網(wǎng)關(guān)配置在硬件設(shè)備上，在我們的方案中就是核心路由器上。因此，每次在 OpenStack 里創(chuàng)建或刪除網(wǎng)絡(luò)時(shí)，都需要手動(dòng)去核心交換機(jī)上做配置 。雖然說(shuō)這種操作頻率還是很低的，但操作核心路由器風(fēng)險(xiǎn)很大，核心發(fā)生故障會(huì)影響整張網(wǎng)絡(luò)。
三、基于 SDN 的大二層網(wǎng)絡(luò)
以上就是我們?cè)谠朴?jì)算時(shí)代的第一代網(wǎng)絡(luò)方案，設(shè)計(jì)上比較簡(jiǎn)單直接，相應(yīng)地，功能也比較少。隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大和近幾年我們內(nèi)部微服務(wù)化的推進(jìn)，這套方案遇到了一些問(wèn)題。
3.1 面臨的新問(wèn)題
首先來(lái)自硬件。做數(shù)據(jù)中心網(wǎng)絡(luò)的同學(xué)比較清楚，三層網(wǎng)絡(luò)架構(gòu)的可擴(kuò)展性比較差， 而且我們所有的 OpenStack 網(wǎng)關(guān)都配置在核心上，使得核心成為潛在的性能瓶頸，而核心掛了會(huì)影響整張網(wǎng)絡(luò)。
第二，很大的 VLAN 網(wǎng)絡(luò)內(nèi)部的泛洪，以及 VLAN 最多只有 4096 個(gè)的限制。
第三，宿主機(jī)網(wǎng)卡比較舊，都是 1Gbps，也很容易達(dá)到瓶頸。
另外我們也有一些新的需求：
首先，攜程在這期間收購(gòu)了一些公司，會(huì)有將這些收購(gòu)來(lái)的公司的網(wǎng)絡(luò)與攜程的網(wǎng)絡(luò)打通的需求。在網(wǎng)絡(luò)層面，我們想把它們當(dāng)作租戶對(duì)待，因此有多租戶和 VPC 的需求。
另外，我們想讓網(wǎng)絡(luò)配置和網(wǎng)絡(luò)資源交付更加自動(dòng)化，減少運(yùn)維成本與運(yùn)維風(fēng)險(xiǎn)。
3.2 解決方案：OpenStack + SDN
針對(duì)以上問(wèn)題和需求，數(shù)據(jù)中心網(wǎng)絡(luò)團(tuán)隊(duì)和我們 cloud 網(wǎng)絡(luò)團(tuán)隊(duì)一起設(shè)計(jì)了第二代網(wǎng)絡(luò)方 案：一套基于軟件+硬件、OpenStack+SDN?的方案，從二層網(wǎng)絡(luò)演進(jìn)到大二層網(wǎng)絡(luò)。
硬件拓?fù)?/strong>
在硬件拓?fù)渖?#xff0c;從傳統(tǒng)三層網(wǎng)絡(luò)模型換成了近幾年比較流行的 Spine-Leaf 架構(gòu)，如圖 7 所示。
Fig 7. Spine-Leaf Topology in the New DatacenterSpine-Leaf 是 full-mesh 連接，它可以帶來(lái)如下幾個(gè)好處：
第一，轉(zhuǎn)發(fā)路徑更短。以圖 7 的 Spine-Leaf（兩級(jí) Clos 架構(gòu)）為例，任何兩臺(tái)服務(wù)器經(jīng)過(guò)三跳（Leaf1 -> Spine -> Leaf2）就可以到達(dá)，延遲更低，并且可保障（可以按跳數(shù)精確計(jì)算出來(lái)）。
第二，水平可擴(kuò)展性更好，任何一層有帶寬或性能瓶頸，只需新加一臺(tái)設(shè)備，然后跟另一層的所有設(shè)備直連。
第三，所有設(shè)備都是 active 的，一個(gè)設(shè)備掛掉之后，影響面比三層模型里掛掉一個(gè)設(shè)備小得多。
宿主機(jī)方面，我們升級(jí)到了 10G 和 25G 的網(wǎng)卡。
SDN：控制平面和數(shù)據(jù)平面
數(shù)據(jù)平面基于 VxLAN，控制平面基于 MP-BGP EVPN 協(xié)議，在設(shè)備之間同步控制平面信息。 網(wǎng)關(guān)是分布式的，每個(gè) leaf 節(jié)點(diǎn)都是網(wǎng)關(guān)。VxLAN 和 MP-BGP EVPN 都是 RFC 標(biāo)準(zhǔn)協(xié)議，更多信息參考 [2]。
VxLAN 的封裝和解封裝都在 leaf 完成，leaf 以下是 VLAN 網(wǎng)絡(luò)，以上是 VxLAN 網(wǎng)絡(luò)。
另外，這套方案在物理上支持真正的租戶隔離。
SDN：組件和實(shí)現(xiàn)
開(kāi)發(fā)集中在以下幾個(gè)方面。
首先是自研了一個(gè) SDN 控制器，稱作攜程網(wǎng)絡(luò)控制器（Ctrip Network Controller） ，縮寫 CNC。CNC 是一個(gè)集中式控制器，管理網(wǎng)絡(luò)內(nèi)所有 spine 和 leaf 節(jié)點(diǎn)，通過(guò) neutron plugin 與 OpenStack Neutron 集成，能夠動(dòng)態(tài)向交換機(jī)下發(fā)配置。
Neutron 的主要改造：
1）添加了 ML2 和 L3 兩個(gè) plugin 與 CNC 集成
2）設(shè)計(jì)了新的 port 狀態(tài)機(jī)，因?yàn)樵瓉?lái)的 port 只對(duì) underlay 進(jìn)行了建模，我們現(xiàn)在有 underlay 和 overlay 兩個(gè)平面
3）添加了一下新的API，用于和 CNC 交互
4）擴(kuò)展了一些表結(jié)構(gòu)等等
圖 8 就是我們對(duì) neutron port 狀態(tài)的一個(gè)監(jiān)控。如果一個(gè) IP（port）不通，我們很容易從它的狀態(tài)看出問(wèn)題是出在 underlay 還是 overlay。
Fig 8. Monitoring Panel for Neutron Port States3.3 軟件+硬件網(wǎng)絡(luò)拓?fù)?/strong>
Fig 9. HW + SW Topology of the Designed SDN Solution圖 9 是我們軟件+硬件的網(wǎng)絡(luò)拓?fù)?#xff1a;
1）以 leaf 為邊界，leaf 以下是 underlay，走 VLAN；上面 overlay，走 VxLAN
2）underlay 由 neutron、OVS 和 neutron OVS agent 控制；overlay 是 CNC 控制
3）Neutron 和 CNC 之間通過(guò) plugin 集成
3.4 創(chuàng)建實(shí)例涉及的網(wǎng)絡(luò)配置流程
這里簡(jiǎn)單來(lái)看一下創(chuàng)建一個(gè)實(shí)例后，它的網(wǎng)絡(luò)是怎么通的。圖 10 中黑色的線是 OpenStack 原有的邏輯，藍(lán)色的是我們新加的。
Fig 10. Flow of Spawn An Instance1）控制節(jié)點(diǎn)：從 nova 發(fā)起一個(gè)創(chuàng)建實(shí)例請(qǐng)求，指定從哪個(gè)網(wǎng)絡(luò)分配 IP 給這個(gè)實(shí)例。 nova 調(diào)度器將任務(wù)調(diào)度到某臺(tái)計(jì)算節(jié)點(diǎn)
2）計(jì)算節(jié)點(diǎn)：nova compute 開(kāi)始創(chuàng)建實(shí)例，其中一步是向 neutron 發(fā)起一個(gè) create port 請(qǐng)求，簡(jiǎn)單認(rèn)為就是申請(qǐng)一個(gè) IP 地址
3）Neutron Server: neutron 創(chuàng)建一個(gè) port，然后經(jīng) create port 的 postcommit 方法 到達(dá) CNC ML2 plugin；plugin 進(jìn)一步將 port 信息同步給 CNC，CNC 將其存儲(chǔ)到自己 的 DB
4）計(jì)算節(jié)點(diǎn)：port 信息從 neutron server 返回給 nova-compute
5）計(jì)算節(jié)點(diǎn)：nova-compute 拿到 port 信息，為實(shí)例創(chuàng)建虛擬網(wǎng)卡，配置 IP 地址等參數(shù) ，并將其 attach到 OVS
6）計(jì)算節(jié)點(diǎn)：ovs agent 檢測(cè)到新的 device 后，就會(huì)為這個(gè) device 配置 OVS，添加 flow 等，這時(shí)候 underlay 就通了，它會(huì)將 underlay 狀態(tài)上報(bào)給 neutron server
7）計(jì)算節(jié)點(diǎn)：nova-compute 做完網(wǎng)絡(luò)配置后，會(huì)發(fā)送一個(gè) update port 消息給 neutron server，其中帶著?host_id?信息，表示這個(gè) port 現(xiàn)在在哪臺(tái)計(jì)算節(jié)點(diǎn)上
8）Neutron Server：請(qǐng)求會(huì)通過(guò) postcommit 發(fā)給 CNC
9）CNC：CNC 根據(jù)?host_id?找到這臺(tái)計(jì)算節(jié)點(diǎn)所連接的 leaf 的端口，然后向這些端口動(dòng)態(tài)下發(fā)配置，這時(shí)候 overlay 就通了，最后將 overlay 狀態(tài)上報(bào)給 neutron server
在我們的系統(tǒng)里看，這時(shí) port 就是一個(gè)?ACTIVE_ACTIVE?的狀態(tài)，表示 underlay 和 overlay 配置都是正常的，網(wǎng)絡(luò)應(yīng)該是通的。
3.5 小結(jié)
總結(jié)一下我們這套方案。
硬件
首先，我們從三層網(wǎng)絡(luò)架構(gòu)演進(jìn)到 Spine-Leaf 兩級(jí)架構(gòu)。Spine-Leaf 的 full-mesh 使得服務(wù)器之間延遲更低、容錯(cuò)性更好、更易水平擴(kuò)展。另外，Spine-Leaf 還支持分布式網(wǎng) 關(guān)，緩解了集中式網(wǎng)關(guān)的性能瓶頸和單點(diǎn)問(wèn)題。
軟件
自研 SDN 控制器并與 OpenStack 集成，實(shí)現(xiàn)了網(wǎng)絡(luò)的動(dòng)態(tài)配置。
這套方案同時(shí)支持虛擬機(jī)和應(yīng)用物理機(jī)部署系統(tǒng)，限于篇幅這里只介紹了虛擬機(jī)。
多租戶
有硬多租戶（hard-multitenancy）支持能力。
四、容器和混合云網(wǎng)絡(luò)
以上方案最開(kāi)始還是針對(duì)虛擬機(jī)和應(yīng)用物理機(jī)設(shè)計(jì)的。到了 2017 年，我們開(kāi)始在私有云和公有云上落地容器平臺(tái)，將一部分應(yīng)用從虛擬機(jī)或應(yīng)用物理機(jī)遷移到容器。
容器平臺(tái)（K8S、Mesos 等）有不同于虛擬機(jī)平臺(tái)的一些特點(diǎn)，例如：
1）實(shí)例的規(guī)模很大，單個(gè)集群 10k～100k 個(gè)容器是很常見(jiàn)的；
2）很高的發(fā)布頻率，實(shí)例會(huì)頻繁地創(chuàng)建和銷毀；
3）實(shí)例創(chuàng)建和銷毀時(shí)間很短，比傳統(tǒng)的虛擬機(jī)低至少一個(gè)數(shù)量級(jí)；
4）容器的失敗是很常見(jiàn)，總會(huì)因?yàn)楦鞣N各樣的原因?qū)е氯萜鲯斓簟Ｈ萜骶幣乓嬖谠O(shè)計(jì)的 時(shí)候已經(jīng)把失敗當(dāng)做預(yù)期情況處理，例如將掛掉的容器在本機(jī)或其他宿主機(jī)再拉起來(lái)， 后者就是一次漂移；
4.1 私有云的 K8S 網(wǎng)絡(luò)方案
容器平臺(tái)的這些特點(diǎn)對(duì)網(wǎng)絡(luò)提出了新的需求。
4.1.1 網(wǎng)絡(luò)需求
首先，網(wǎng)絡(luò)服務(wù)的 API 必須要快，而且支持較大的并發(fā)。
第二，不管是 agent 還是可執(zhí)行文件，為容器創(chuàng)建和刪除網(wǎng)絡(luò)（虛擬網(wǎng)絡(luò)及相應(yīng)配置）也要快。
最后是一個(gè)工程問(wèn)題：新系統(tǒng)要想快速落地，就必須與很多線上系統(tǒng)保持前向兼容。這給我們網(wǎng)絡(luò)提出一個(gè)需求就是：容器漂移時(shí)，IP 要保持不變。因?yàn)?OpenStack 時(shí)代， 虛擬機(jī)遷移 IP 是不變的，所以很多外圍系統(tǒng)都認(rèn)為 IP 是實(shí)例生命周期中的一個(gè)不變量， 如果我們突然要改成 IP 可變，就會(huì)涉及大量的外圍系統(tǒng)（例如 SOA）改造，這其中很多不 是我們所能控制的。因此為了實(shí)現(xiàn)容器的快速落地，就必須考慮這個(gè)需求。而流行的 K8S 網(wǎng)絡(luò)方案都是無(wú)法支持這個(gè)功能的，因?yàn)樵谌萜髌脚_(tái)的設(shè)計(jì)哲學(xué)里，IP 地址已經(jīng)是一個(gè)被 弱化的概念，用戶更應(yīng)該關(guān)心的是實(shí)例暴露的服務(wù)，而不是 IP。
4.1.2 解決方案：擴(kuò)展現(xiàn)有 SDN 方案，接入 Mesos/K8S
在私有云中，我們最終決定對(duì)現(xiàn)有的為虛擬機(jī)和應(yīng)用物理機(jī)設(shè)計(jì)的 SDN 方案進(jìn)行擴(kuò)展，將 容器網(wǎng)絡(luò)也統(tǒng)一由 Neutron/CNC 管理。具體來(lái)說(shuō)，會(huì)復(fù)用已有的網(wǎng)絡(luò)基礎(chǔ)設(shè)施，包括 Neutron、CNC、OVS、Neutron-OVS-Agent 等待，然后開(kāi)發(fā)一個(gè)針對(duì) Neutron 的 CNI 插件 （對(duì)于 K8S）。
一些核心改動(dòng)或優(yōu)化如下。
Neutron 改動(dòng)
首先是增加了一些新的 API。比如，原來(lái)的 neutron 是按 network id 分配 IP，我們給 network 添加了 label 屬性，相同 label 的 network 我們認(rèn)為是無(wú)差別的。這樣，CNI申 請(qǐng) IP 的時(shí)候，只需要說(shuō)“我需要一個(gè) ‘prod-env’ 網(wǎng)段的 IP”，neutron 就會(huì)從打了“ prod-env” label 的 network 中任選一個(gè)還沒(méi)用完的，從中分一個(gè)IP。這樣既將外部系統(tǒng) 與 OpenStack 細(xì)節(jié)解耦，又提高了可擴(kuò)展性，因?yàn)橐粋€(gè) label 可以對(duì)應(yīng)任意多個(gè) network 。
另外做了一些性能優(yōu)化，例如增加批量分配 IP 接口、API 異步化、數(shù)據(jù)庫(kù)操作優(yōu)化等待。
還有就是 backport 一些新 feature 到 neutron，我們的 OpenStack 已經(jīng)不隨社區(qū)一起升級(jí)了，都是按需 backport。例如，其中一個(gè)對(duì)運(yùn)維和 trouble shooting 非常友好的功能 是 Graceful OVS agent restart。
K8S CNI for Neutron 插件
開(kāi)發(fā)了一個(gè) CNI plugin 對(duì)接 neutron。CNI 插件的功能比較常規(guī)：
1）為容器創(chuàng)建 veth pairt，并 attach 到 OVS
2）為容器配置 MAC、IP、路由等信息
但有兩個(gè)特殊之處：
1）向 neutron（global IPAM）申請(qǐng)分配和釋放 IP，而不是宿主機(jī)的本地服務(wù)分配（local IPAM）
2）將 port 信息更新到 neutron server
基礎(chǔ)網(wǎng)絡(luò)服務(wù)升級(jí)
另外進(jìn)行了一些基礎(chǔ)架構(gòu)的升級(jí)，比如 OVS 在過(guò)去幾年的使用過(guò)程中發(fā)現(xiàn)老版本的幾個(gè) bug，后來(lái)發(fā)現(xiàn)這幾個(gè)問(wèn)題在社區(qū)也是有記錄的：
1）vswitchd?CPU 100% [3]
2）流量鏡像丟包 [4]
注意到最新的 LTS 版本已經(jīng)解決了這些問(wèn)題，因此我們將 OVS 升級(jí)到了最新的 LTS。 大家如果有遇到類似問(wèn)題，可以參考 [3, 4]。
4.1.3 容器漂移
創(chuàng)建一個(gè)容器后，容器網(wǎng)絡(luò)配置的流程和圖 10 類似，Nova 和 K8S 只需做如下的組件對(duì)應(yīng)：
-
nova?->?kube master
-
nova-compute -> kubelet
-
nova network driver -> CNI
其流程不再詳細(xì)介紹。這里重點(diǎn)介紹一下容器漂移時(shí) IP 是如何保持不變的。
如圖 11 所示，保持 IP 不變的關(guān)鍵是：CNI 插件能夠根據(jù)容器的labels 推導(dǎo)出 port name，然后拿 name 去 neutron 里獲取 port 詳細(xì)信息。port name 是唯一的，這個(gè)是我們改過(guò)的，原生的 OpenStack 并不唯一。
第二個(gè)宿主機(jī)的 CNI plugin 會(huì)根據(jù) name 找到 port 信息，配置完成后，會(huì)將新的?host_id?更新到 netron server；neutron 通知到 CNC，CNC 去原來(lái)的交換機(jī)上刪除配置 ，并向新的交換機(jī)下發(fā)配置。
Fig 11. Pod drifting with the same IP within a K8S cluster4.1.4 小結(jié)
簡(jiǎn)單總結(jié)一下：
1）在保持基礎(chǔ)設(shè)施不變的情況下，我們快速地將容器平臺(tái)的網(wǎng)絡(luò)接入到已有系統(tǒng)
2）一個(gè) IPAM 同時(shí)管理了虛擬機(jī)、應(yīng)用物理機(jī)和容器的網(wǎng)絡(luò)
目前這套新方案的部署規(guī)模：
1）4 個(gè)可用區(qū)
2）最大的可用區(qū)有超過(guò) 500 個(gè)節(jié)點(diǎn)（VM/BM/Container 宿主機(jī)），其中主要是 K8S 節(jié)點(diǎn)
3）單個(gè) K8S 節(jié)點(diǎn)最多會(huì)有 500+ pod（測(cè)試環(huán)境的超分比較高）
4）最大的可用區(qū)有 2+ 萬(wàn)個(gè)實(shí)例，其中主要是容器實(shí)例
4.1.5 進(jìn)一步演進(jìn)方向
以上就是到目前為止我們私有云上的網(wǎng)絡(luò)方案演講，下面這張圖是我們希望將來(lái)能達(dá)到的一 個(gè)架構(gòu)。
Fig 12. Layered view of the future network architecture首先會(huì)有 underlay 和 overlay 兩個(gè)平面。underlay 部署各種基礎(chǔ)設(shè)施，包括 Openstack 控制器、計(jì)算節(jié)點(diǎn)、SDN 控制器等，以及各種需要運(yùn)行在underlay的物理設(shè)備； 在 overlay 創(chuàng)建 VPC，在 VPC 里部署虛擬機(jī)、應(yīng)用物理機(jī)實(shí)例等。
在 VPC 內(nèi)創(chuàng)建 K8S 集群，單個(gè) K8S 集群只會(huì)屬于一個(gè) VPC，所有跨 K8S 集群的訪問(wèn)都走服務(wù)接口，例如 Ingress，現(xiàn)在我們還沒(méi)有做到這一步，因?yàn)樯婕暗胶芏嗬檄h(huán)境的軟件和硬件改造。
4.2 公有云上的 K8S
接下來(lái)看一下我們?cè)诠性粕系木W(wǎng)絡(luò)。
4.2.1 需求
隨著攜程國(guó)際化戰(zhàn)略的開(kāi)展，我們需要具備在海外部署應(yīng)用的能力。自建數(shù)據(jù)中心肯定是來(lái)不及的，因此我們選擇在公有云上購(gòu)買虛擬機(jī)或 baremetal 機(jī)器，并搭建和維護(hù)自己的 K8S 集群（非廠商托管方案，例如 AWS EKS [10]）。 在外層，我們通過(guò) CDOS API 封裝不同廠商的差異，給應(yīng)用部門提供統(tǒng)一的接口。這樣，我們的私有云演進(jìn)到了混合云的階段。
網(wǎng)絡(luò)方面主要涉及兩方面工作：一是 K8S 的網(wǎng)絡(luò)方案，這個(gè)可能會(huì)因廠商而已，因?yàn)椴煌?廠商提供的網(wǎng)絡(luò)模型和功能可能不同；二是打通私有云和公有云。
4.2.2 AWS 上的 K8S 網(wǎng)絡(luò)方案
以 AWS 為例來(lái)看下我們?cè)诠性粕系?K8S 網(wǎng)絡(luò)方案。
Fig 13. K8S network solution on public cloud vendor (AWS)首先，起 EC2 實(shí)例作為 K8S node，我們自己開(kāi)發(fā)一個(gè) CNI 插件，動(dòng)態(tài)向 EC2 插拔 ENI， 并把 ENI 作為網(wǎng)卡給容器使用。這一部分借鑒了 Lyft和 Netflix 在 AWS 上經(jīng)驗(yàn) [5, 6]。
在 VPC 內(nèi)，有一個(gè)全局的 IPAM，管理整個(gè) K8S 集群的網(wǎng)絡(luò)資源，角色和私有云中的 neutron 類似。它會(huì)調(diào)用 AWS API 實(shí)現(xiàn)網(wǎng)絡(luò)資源的申請(qǐng)、釋放和管理。
另外，我們的 CNI 還支持 attach/detach floating IP 到容器。還有就是和私有云一樣， 容器漂移的時(shí)候 IP 保持不變。
4.2.3 全球 VPC 拓?fù)?/strong>
圖 14 是我們現(xiàn)在在全球的 VPC 分布示意圖。
在上海和南通有我們的私有云 VPC；在海外，例如首爾、莫斯科、法蘭克福、加州（美 西）、香港、墨爾本等地方有公有云上的 VPC，這里畫(huà)的不全，實(shí)際不止這幾個(gè) region。
Fig 14. VPCs distributed over the globe這些 VPC 使用的網(wǎng)段是經(jīng)過(guò)規(guī)劃的，目前不會(huì)跟內(nèi)網(wǎng)網(wǎng)段重合。因此通過(guò)專線打通后，IP 可以做到可路由。
五、Cloud Native 方案探索
以上就是我們?cè)谒接性坪突旌显茍?chǎng)景下的網(wǎng)絡(luò)方案演進(jìn)。目前的方案可以支持業(yè)務(wù)未來(lái)一段的發(fā)展，但也有一些新的挑戰(zhàn)。
首先，中心式的 IPAM 逐漸成為性能瓶頸。做過(guò) OpenStack 的同學(xué)應(yīng)該很清楚，neutron不是為性能設(shè)計(jì)的，而是為發(fā)布頻率很低、性能要求不高的虛擬機(jī)設(shè)計(jì)的。沒(méi)有優(yōu)化過(guò)的話， 一次 neutron API 調(diào)用百毫秒級(jí)是很正常的，高負(fù)載的時(shí)候更慢。
另外，中心式的 IPAM 也不符合容器網(wǎng)絡(luò)的設(shè)計(jì)哲學(xué)。Cloud native 方案都傾向于 local IPAM（去中心化），即 每個(gè) node 上有一個(gè) IPAM，自己管理本節(jié)點(diǎn)的網(wǎng)絡(luò)資源分配，calico、flannel 等流行的網(wǎng)絡(luò)方案都是這樣的。
第二，現(xiàn)在我們的 IP 在整張網(wǎng)絡(luò)都是可漂移的，因此故障范圍特別大。
第三，容器的高部署密度會(huì)給大二層網(wǎng)絡(luò)的交換機(jī)表項(xiàng)帶來(lái)壓力，這里面有一些大二層設(shè)計(jì)本身以及硬件的限制。
另外，近年來(lái)安全受到越來(lái)越高度重視，我們有越來(lái)越強(qiáng)的 3-7 層主機(jī)防火墻需求。目前基于OVS 的方案與主流的 K8S 方案差異很大，導(dǎo)致很多 K8S 原生功能用不了。
針對(duì)以上問(wèn)題和需求，我們進(jìn)行了一些新方案的調(diào)研，包括 Calico，Cilium 等等。Calico 大家應(yīng)該已經(jīng)比較熟悉了，這里介紹下 Cilium。
5.1 Cilium Overview
Cilium [7]是近兩年新出現(xiàn)的網(wǎng)絡(luò)方案，它使用了很多內(nèi)核新技術(shù)，因此對(duì)內(nèi)核版本要求比較高，需要 4.8 以上支持。
Cilium 的核心功能依賴 BPF/eBPF，這是內(nèi)核里的一個(gè)沙盒虛擬機(jī)。應(yīng)用程序可以通過(guò) BPF 動(dòng)態(tài)的向內(nèi)核注入程序來(lái)完成很多高級(jí)功能，例如系統(tǒng)調(diào)用跟蹤、性能分析、網(wǎng)絡(luò)攔截等等。Cilium 基于 BPF 做網(wǎng)絡(luò)的連通和安全，提供 3-7 層的安策略。
Cilium 組件：
1）CLI
2）存儲(chǔ)安全策略的 repository，一般是 etcd
3）與編排引擎集成的插件：提供了 plugin 與主流的編排系統(tǒng)（K8S、Mesos 等）集成
4）Agent，運(yùn)行在每臺(tái)宿主機(jī)，其中集成了 Local IPAM 功能
Fig 15. Cilium5.2 宿主機(jī)內(nèi)部網(wǎng)絡(luò)通信（Host Networking）
每個(gè)網(wǎng)絡(luò)方案都需要解決兩個(gè)主要問(wèn)題：
1）宿主機(jī)內(nèi)部的通信：實(shí)例之間，實(shí)例和宿主機(jī)通信
2）宿主機(jī)之間的通信：跨宿主機(jī)的實(shí)例之間的通信
先來(lái)看 Cilium 宿主機(jī)內(nèi)部的網(wǎng)絡(luò)通信。
Fig 16. Cilium host-networkingAgent 首先會(huì)創(chuàng)建一個(gè)?cilium_host <---> cilium_net?的 veth pair，然后將它管理的 CIDR 的第一個(gè) IP 作為網(wǎng)關(guān)，配置在cilium_host?上。對(duì)于每個(gè)容器，CNI 插件會(huì)承擔(dān)創(chuàng)建 veth pair、配置 IP、生成 BPF 規(guī)則等工作。
同宿主機(jī)內(nèi)部的容器之間的連通性靠?jī)?nèi)核協(xié)議棧二層轉(zhuǎn)發(fā)和BPF 程序。比如?inst1?到?isnt2，包首先從?eth0?經(jīng)協(xié)議棧到達(dá)lxc11，中間再經(jīng)過(guò)BPF 規(guī)則到達(dá)?lxc22， 然后再經(jīng)協(xié)議棧轉(zhuǎn)發(fā)到達(dá)?inst2?的?eth0。
以傳統(tǒng)的網(wǎng)絡(luò)觀念來(lái)看，lxc11?到?lxc22?這一跳非常怪，因?yàn)闆](méi)有既沒(méi)有 OVS 或 Linux bridge 這樣的二層轉(zhuǎn)發(fā)設(shè)備，也沒(méi)有 iptables 規(guī)則或者 ARP 表項(xiàng)，包就神奇的到達(dá)了另一個(gè)地方，并且 MAC 地址還被修改了。
類似地，容器和宿主機(jī)的通信走宿主機(jī)內(nèi)部的三層路由和 BPF 轉(zhuǎn)發(fā)，其中 BPF 程序連接容器的 veth pair 和它的網(wǎng)關(guān)設(shè)備，因?yàn)槿萜骱退拗鳈C(jī)是兩個(gè)網(wǎng)段。
5.3 跨宿主機(jī)網(wǎng)絡(luò)通信（Multi-Host Networking）
跨宿主機(jī)的通信和主流的方案一樣，支持兩種常見(jiàn)方式：
-
VxLAN 隧道
-
BGP 直接路由
如果使用 VxLAN 方式，Cilium 會(huì)創(chuàng)建一個(gè)名為?cilium_vxlan?的 device 作為 VTEP， 負(fù)責(zé)封裝和解封裝。這種方案需要評(píng)估軟件 VxLAN 的性能能否接受，以及是否需要 offload 到硬件加速。一般來(lái)說(shuō)，軟件 VxLAN 的方式性能較差，而且實(shí)例 IP 不可路由。
BGP 方案性能更好，而且 IP 可路由，但需要底層網(wǎng)絡(luò)支持。這種方案需要在每個(gè) node 上起一個(gè) BGP agent 來(lái)和外部網(wǎng)絡(luò)交換路由，涉及 BGP agent 的選型、AS（自治系 統(tǒng)）的設(shè)計(jì)等額外工作。如果是內(nèi)網(wǎng)，一般就是 BGP agent 與硬件網(wǎng)絡(luò)做 peering；如果 是在 AWS 之類的公有云上，還可以調(diào)用廠商提供的BGP API。
5.4 優(yōu)劣勢(shì)比較（Pros & Cons）
最后總結(jié)一下 Cilium 方案的優(yōu)劣勢(shì)。
Pros
首先，原生支持 K8S L4-L7 安全策略，例如在 yaml 指定期望的安全效果，Cilium 會(huì)自動(dòng)將其轉(zhuǎn)化為 BPF 規(guī)則。
第二，高性能策略下發(fā)（控制平面）。Calico/iptables 最大的問(wèn)題之一就是集群規(guī)模大了之后，新策略生效非常慢。iptables 是鏈?zhǔn)皆O(shè)計(jì)，復(fù)雜度是?O(n)；而 Cilium 的復(fù)雜度是?O(1)?[11]，因此性能非常好。
第三，高性能數(shù)據(jù)平面 (veth pair, IPVLAN)。
第四，原生支持雙棧 (IPv4/IPv6)。事實(shí)上 Cilium 最開(kāi)始只支持 IPv6，后面才添加了對(duì) IPv4 的支持，因?yàn)樗麄円婚_(kāi)始就是作為下一代技術(shù)為超大規(guī)模集群設(shè)計(jì)的。
第五，支持運(yùn)行在 flannel 之上：flannel 負(fù)責(zé)網(wǎng)絡(luò)連通性，Cilium 負(fù)責(zé)安全策略。如果你的集群現(xiàn)在是 flannel 模式，遷移到 Cilium 會(huì)比較方便。
最后，非常活躍的社區(qū)。Cilium 背后是一家公司在支持，一部分核心開(kāi)發(fā)者來(lái)自內(nèi)核社區(qū) ，而且同時(shí)也是 eBPF 的開(kāi)發(fā)者。
Cons
首先是內(nèi)核版本要求比較高，至少 4.8+，最好 4.14+，相信很多公司的內(nèi)核版本是沒(méi)有這么高的。
第二，方案比較新，還沒(méi)有哪家比較有名或有說(shuō)服力的大廠在較大規(guī)模的生產(chǎn)環(huán)境部署了這種方案，因此不知道里面有沒(méi)有大坑。
第三，如果要對(duì)代碼有把控（稍大規(guī)模的公司應(yīng)該都有這種要求），而不僅僅是做一個(gè)用戶 ，那對(duì)內(nèi)核有一定的要求，例如要熟悉協(xié)議棧、包的收發(fā)路徑、內(nèi)核協(xié)議棧數(shù)據(jù)結(jié)構(gòu)、 不錯(cuò)的 C 語(yǔ)言功底（BPF 程序是 C 寫的）等等，開(kāi)發(fā)和運(yùn)維成本比基于 iptables 的方案 （例如 Calico）要高。
總體來(lái)說(shuō)，Cilium/eBPF 是近幾年出現(xiàn)的最令人激動(dòng)的項(xiàng)目之一，而且還在快速發(fā)展之中。 我推薦大家有機(jī)會(huì)都上手玩一玩，發(fā)現(xiàn)其中的樂(lè)趣。
References
OpenStack Doc: Networking Concepts
Cisco Data Center Spine-and-Leaf Architecture: Design Overview
ovs-vswitchd: Fix high cpu utilization when acquire idle lock fails
openvswitch port mirroring only mirrors egress traffic
Lyft CNI plugin
Netflix: run container at scale
Cilium Project
Cilium Cheat Sheet
Cilium Code Walk Through: CNI Create Network
Amazon EKS - Managed Kubernetes Service
Cilium: API Aware Networking & Network Security for Microservices using BPF & XDP
總結(jié)
以上是生活随笔為你收集整理的干货 | 云计算时代携程的网络架构变迁的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 干货 | 当你在携程搜索时，背后的推荐系
- 下一篇： 用Telnet发送HTTP请求