作者簡介

趙亞楠，攜程云平臺資深架構師。2016 年加入攜程云計算部門，先后從事 OpenStack、SDN、容器網絡（Mesos、K8S）、容器鏡像存儲、分布式存儲等產品的開發，目前帶領 Ctrip Cloud Network & Storage Team，專注于網絡和分布式存儲研發。

?

本文介紹云計算時代以來攜程在私有云和公有云上的幾代網絡解決方案。希望這些內容可以給業內同行，尤其是那些設計和維護同等規模網絡的團隊提供一些參考。

本文將首先簡單介紹攜程的云平臺，然后依次介紹我們經歷過的幾代網絡模型：從傳統的基于 VLAN 的二層網絡，到基于 SDN 的大二層網絡，再到容器和混合云場景下的網絡，最后是 cloud native 時代的一些探索。

一、攜程云平臺簡介

攜程 Cloud 團隊成立于 2013 年左右，最初是基于 OpenStack 做私有云，后來又開發了自己的 baremetal（BM）系統，集成到 OpenStack，最近幾年又陸續落地了 Mesos 和 K8S 平 臺，并接入了公有云。

目前，我們已經將所有 cloud 服務打造成一個?CDOS — 攜程數據中心操作系統的混合云平臺，統一管理我們在私有云和公有云上的計算、網絡 、存儲資源。

Fig 1. Ctrip Datacenter Operation System (CDOS)

在私有云上，我們有虛擬機、應用物理機和容器。在公有云上，接入了亞馬遜、騰訊云、UCloud 等供應商，給應用部門提供虛擬機和容器。所有這些資源都通過 CDOS API 統一管理。

網絡演進時間線

Fig 2. Timeline of the Network Architecture Evolution

圖 2 是我們網絡架構演進的大致時間線。

最開始做 OpenStack 時采用的是簡單的 VLAN 二層網絡，硬件網絡基于傳統的三層網絡模型。

隨著網絡規模的擴大，這種架構的不足逐漸顯現出來。因此，在 2016 年自研了基于 SDN 的大二層網絡來解決面臨的問題，其中硬件架構換成了 Spine-Leaf。

2017年，我們開始在私有云和公有云上落地容器平臺。在私有云上，對 SDN 方案進行了擴展和優化，接入了 Mesos 和 K8S 平臺，單套網絡方案同時管理了虛擬機、應用物理機和容器網絡。公有云上也設計了自己的網絡方案，打通了混合云。

最后是 2019 年，針對 Cloud Native 時代面臨的一些新挑戰，我們在調研一些新方案。

二、基于 VLAN 的二層網絡

2013 年我們開始基于 OpenStack 做私有云，給公司的業務部門提供虛擬機和應用物理機資源。

2.1 需求

網絡方面的需求有：

首先，性能不能太差，衡量指標包括 instance-to-instance 延遲、吞吐量等等。

第二，二層要有必要的隔離，防止二層網絡的一些常見問題，例如廣播泛洪。

第三，實例的 IP 要可路由，這點比較重要。這也決定了在宿主機內部不能使用隧道技術。

第四，安全的優先級可以稍微放低一點。如果可以通過犧牲一點安全性帶來比較大的性能提升，在當時也是可以接受的。而且在私有云上，還是有其他方式可以彌補安全性的不足。

2.2 解決方案：OpenStack Provider Network 模型

經過一些調研，我們最后選擇了 OpenStack?provider network?模型 [1]。

Fig 3. OpenStack Provider Network Model

如圖 3 所示。宿主機內部走二層軟交換，可以是 OVS、Linux Bridge、或者特定廠商的方案；宿主機外面，二層走交換，三層走路由，沒有 overlay 封裝。

這種方案有如下特點：

首先，租戶網絡的網關要配置在硬件設備上，因此需要硬件網絡的配合，而并不是一個純軟件的方案；

第二，實例的 IP 是可路由的，不需要走隧道；

第三，和純軟件的方案相比，性能更好，因為不需要隧道的封裝和解封裝，而且跨網段的路由都是由硬件交換機完成的。

方案的一些其他方面：

1）二層使用 VLAN 做隔離

2）ML2 選用 OVS，相應的 L2 agent 就是 neutron ovs agent

3）因為網關在硬件交換機上，所以我們不需要 L3 agent（OpenStack 軟件實現的虛擬路由器）來做路由轉發

4）不用 DHCP

5）沒有 floating ip 的需求

6）出于性能考慮，我們去掉了 security group

2.3 硬件網絡拓撲

圖 4 是我們的物理網絡拓撲，最下面是服務器機柜，上面的網絡是典型的接入-匯聚-核心三層架構。

Fig 4. Physical Network Topology in the Datacenter

特點：

1）每個服務器兩個物理網卡，直連到兩個置頂交換機做物理高可用

2）匯聚層和接入層走二層交換，和核心層走三層路由

3）所有 OpenStack 網關配置在核心層路由器

4）防火墻和核心路由器直連，做一些安全策略

2.4 宿主機內部網絡拓撲

再來看宿主機內部的網絡拓撲。圖 5 是一個計算節點內部的拓撲。

Fig 5. Designed Virtual Network Topology within A Compute Node

特點：

1）首先，在宿主機內有兩個 OVS bridge：br-int?和?br-bond，兩個 bridge 直連

2）有兩個物理網卡，通過 OVS 做 bond。宿主機的 IP 配置在?br-bond?上作為管理 IP

3）所有實例連接到?br-int

圖中的兩個實例屬于不同網段，這些標數字的（虛擬和物理）設備連接起來，就是兩個跨網段的實例之間通信的路徑：inst1?出來的包經?br-int?到達?br-bond，再經物理網卡出宿主機，然后到達交換機，最后到達路由器（網關）；路由轉發之后，包再經類似路徑回到?inst2，總共是18跳。

作為對比，圖 6 是原生的 OpenStack?provider network?模型。

Fig 6. Virtual Network Topology within A Compute Node in Legacy OpenStack

這里最大的區別就是每個實例和?br-int?之間都多出一個 Linux bridge。這是因為原生的 OpenStack 支持通過 security group 對實例做安全策略，而 security group 底層是基于 iptables 的。OVS port 不支持?iptables?規則，而 Linux bridge port 支持，因此 OpenStack 在每個實例和 OVS 之間都插入了一個 Linux Bridge。在這種情況下，inst1 -> inst2?總共是 24 跳，比剛才多出 6 跳。

2.5 小結

最后總結一下我們第一代網絡方案。

優點：

首先，我們去掉了一些不用的 OpenStack 組件，例如 L3 agent、HDCP agent, Neutron meta agent 等等，簡化了系統架構。對于一個剛開始做 OpenStack、經驗還不是很豐富的團隊來說，開發和運維成本比較低。

第二，上面已經看到，我們去掉了 Linux Bridge，簡化了宿主機內部的網絡拓撲，這使得轉發路徑更短，實例的網絡延遲更低。

第三，網關在硬件設備上，和 OpenStack 的純軟件方案相比，性能更好。

第四，實例的 IP 可路由，給跟蹤、監控等外圍系統帶來很大便利。

缺點：

首先，去掉了 security group，沒有了主機防火墻的功能，因此安全性變弱。我們通過硬件防火墻部分地補償了這一問題。

第二，網絡資源交付過程還沒有完全自動化，并且存在較大的運維風險。?provider network?模型要求網關配置在硬件設備上，在我們的方案中就是核心路由器上。因此，每次在 OpenStack 里創建或刪除網絡時，都需要手動去核心交換機上做配置 。雖然說這種操作頻率還是很低的，但操作核心路由器風險很大，核心發生故障會影響整張網絡。

三、基于 SDN 的大二層網絡

以上就是我們在云計算時代的第一代網絡方案，設計上比較簡單直接，相應地，功能也比較少。隨著網絡規模的擴大和近幾年我們內部微服務化的推進，這套方案遇到了一些問題。

3.1 面臨的新問題

首先來自硬件。做數據中心網絡的同學比較清楚，三層網絡架構的可擴展性比較差， 而且我們所有的 OpenStack 網關都配置在核心上，使得核心成為潛在的性能瓶頸，而核心掛了會影響整張網絡。

第二，很大的 VLAN 網絡內部的泛洪，以及 VLAN 最多只有 4096 個的限制。

第三，宿主機網卡比較舊，都是 1Gbps，也很容易達到瓶頸。

另外我們也有一些新的需求：

首先，攜程在這期間收購了一些公司，會有將這些收購來的公司的網絡與攜程的網絡打通的需求。在網絡層面，我們想把它們當作租戶對待，因此有多租戶和 VPC 的需求。

另外，我們想讓網絡配置和網絡資源交付更加自動化，減少運維成本與運維風險。

3.2 解決方案：OpenStack + SDN

針對以上問題和需求，數據中心網絡團隊和我們 cloud 網絡團隊一起設計了第二代網絡方 案：一套基于軟件+硬件、OpenStack+SDN?的方案，從二層網絡演進到大二層網絡。

硬件拓撲

在硬件拓撲上，從傳統三層網絡模型換成了近幾年比較流行的 Spine-Leaf 架構，如圖 7 所示。

Fig 7. Spine-Leaf Topology in the New Datacenter

Spine-Leaf 是 full-mesh 連接，它可以帶來如下幾個好處：

第一，轉發路徑更短。以圖 7 的 Spine-Leaf（兩級 Clos 架構）為例，任何兩臺服務器經過三跳（Leaf1 -> Spine -> Leaf2）就可以到達，延遲更低，并且可保障（可以按跳數精確計算出來）。

第二，水平可擴展性更好，任何一層有帶寬或性能瓶頸，只需新加一臺設備，然后跟另一層的所有設備直連。

第三，所有設備都是 active 的，一個設備掛掉之后，影響面比三層模型里掛掉一個設備小得多。

宿主機方面，我們升級到了 10G 和 25G 的網卡。

SDN：控制平面和數據平面

數據平面基于 VxLAN，控制平面基于 MP-BGP EVPN 協議，在設備之間同步控制平面信息。 網關是分布式的，每個 leaf 節點都是網關。VxLAN 和 MP-BGP EVPN 都是 RFC 標準協議，更多信息參考 [2]。

VxLAN 的封裝和解封裝都在 leaf 完成，leaf 以下是 VLAN 網絡，以上是 VxLAN 網絡。

另外，這套方案在物理上支持真正的租戶隔離。

SDN：組件和實現

開發集中在以下幾個方面。

首先是自研了一個 SDN 控制器，稱作攜程網絡控制器（Ctrip Network Controller） ，縮寫 CNC。CNC 是一個集中式控制器，管理網絡內所有 spine 和 leaf 節點，通過 neutron plugin 與 OpenStack Neutron 集成，能夠動態向交換機下發配置。

Neutron 的主要改造：

1）添加了 ML2 和 L3 兩個 plugin 與 CNC 集成

2）設計了新的 port 狀態機，因為原來的 port 只對 underlay 進行了建模，我們現在有 underlay 和 overlay 兩個平面

3）添加了一下新的API，用于和 CNC 交互

4）擴展了一些表結構等等

圖 8 就是我們對 neutron port 狀態的一個監控。如果一個 IP（port）不通，我們很容易從它的狀態看出問題是出在 underlay 還是 overlay。

Fig 8. Monitoring Panel for Neutron Port States

3.3 軟件+硬件網絡拓撲

Fig 9. HW + SW Topology of the Designed SDN Solution

圖 9 是我們軟件+硬件的網絡拓撲：

1）以 leaf 為邊界，leaf 以下是 underlay，走 VLAN；上面 overlay，走 VxLAN

2）underlay 由 neutron、OVS 和 neutron OVS agent 控制；overlay 是 CNC 控制

3）Neutron 和 CNC 之間通過 plugin 集成

3.4 創建實例涉及的網絡配置流程

這里簡單來看一下創建一個實例后，它的網絡是怎么通的。圖 10 中黑色的線是 OpenStack 原有的邏輯，藍色的是我們新加的。

Fig 10. Flow of Spawn An Instance

1）控制節點：從 nova 發起一個創建實例請求，指定從哪個網絡分配 IP 給這個實例。 nova 調度器將任務調度到某臺計算節點

2）計算節點：nova compute 開始創建實例，其中一步是向 neutron 發起一個 create port 請求，簡單認為就是申請一個 IP 地址

3）Neutron Server: neutron 創建一個 port，然后經 create port 的 postcommit 方法 到達 CNC ML2 plugin；plugin 進一步將 port 信息同步給 CNC，CNC 將其存儲到自己 的 DB

4）計算節點：port 信息從 neutron server 返回給 nova-compute

5）計算節點：nova-compute 拿到 port 信息，為實例創建虛擬網卡，配置 IP 地址等參數 ，并將其 attach到 OVS

6）計算節點：ovs agent 檢測到新的 device 后，就會為這個 device 配置 OVS，添加 flow 等，這時候 underlay 就通了，它會將 underlay 狀態上報給 neutron server

7）計算節點：nova-compute 做完網絡配置后，會發送一個 update port 消息給 neutron server，其中帶著?host_id?信息，表示這個 port 現在在哪臺計算節點上

8）Neutron Server：請求會通過 postcommit 發給 CNC

9）CNC：CNC 根據?host_id?找到這臺計算節點所連接的 leaf 的端口，然后向這些端口動態下發配置，這時候 overlay 就通了，最后將 overlay 狀態上報給 neutron server

在我們的系統里看，這時 port 就是一個?ACTIVE_ACTIVE?的狀態，表示 underlay 和 overlay 配置都是正常的，網絡應該是通的。

3.5 小結

總結一下我們這套方案。

硬件

首先，我們從三層網絡架構演進到 Spine-Leaf 兩級架構。Spine-Leaf 的 full-mesh 使得服務器之間延遲更低、容錯性更好、更易水平擴展。另外，Spine-Leaf 還支持分布式網 關，緩解了集中式網關的性能瓶頸和單點問題。

軟件

自研 SDN 控制器并與 OpenStack 集成，實現了網絡的動態配置。

這套方案同時支持虛擬機和應用物理機部署系統，限于篇幅這里只介紹了虛擬機。

多租戶

有硬多租戶（hard-multitenancy）支持能力。

四、容器和混合云網絡

以上方案最開始還是針對虛擬機和應用物理機設計的。到了 2017 年，我們開始在私有云和公有云上落地容器平臺，將一部分應用從虛擬機或應用物理機遷移到容器。

容器平臺（K8S、Mesos 等）有不同于虛擬機平臺的一些特點，例如：

1）實例的規模很大，單個集群 10k～100k 個容器是很常見的；

2）很高的發布頻率，實例會頻繁地創建和銷毀；

3）實例創建和銷毀時間很短，比傳統的虛擬機低至少一個數量級；

4）容器的失敗是很常見，總會因為各種各樣的原因導致容器掛掉。容器編排引擎在設計的 時候已經把失敗當做預期情況處理，例如將掛掉的容器在本機或其他宿主機再拉起來， 后者就是一次漂移；

4.1 私有云的 K8S 網絡方案

容器平臺的這些特點對網絡提出了新的需求。

4.1.1 網絡需求

首先，網絡服務的 API 必須要快，而且支持較大的并發。

第二，不管是 agent 還是可執行文件，為容器創建和刪除網絡（虛擬網絡及相應配置）也要快。

最后是一個工程問題：新系統要想快速落地，就必須與很多線上系統保持前向兼容。這給我們網絡提出一個需求就是：容器漂移時，IP 要保持不變。因為 OpenStack 時代， 虛擬機遷移 IP 是不變的，所以很多外圍系統都認為 IP 是實例生命周期中的一個不變量， 如果我們突然要改成 IP 可變，就會涉及大量的外圍系統（例如 SOA）改造，這其中很多不 是我們所能控制的。因此為了實現容器的快速落地，就必須考慮這個需求。而流行的 K8S 網絡方案都是無法支持這個功能的，因為在容器平臺的設計哲學里，IP 地址已經是一個被 弱化的概念，用戶更應該關心的是實例暴露的服務，而不是 IP。

4.1.2 解決方案：擴展現有 SDN 方案，接入 Mesos/K8S

在私有云中，我們最終決定對現有的為虛擬機和應用物理機設計的 SDN 方案進行擴展，將 容器網絡也統一由 Neutron/CNC 管理。具體來說，會復用已有的網絡基礎設施，包括 Neutron、CNC、OVS、Neutron-OVS-Agent 等待，然后開發一個針對 Neutron 的 CNI 插件 （對于 K8S）。

一些核心改動或優化如下。

Neutron 改動

首先是增加了一些新的 API。比如，原來的 neutron 是按 network id 分配 IP，我們給 network 添加了 label 屬性，相同 label 的 network 我們認為是無差別的。這樣，CNI申 請 IP 的時候，只需要說“我需要一個 ‘prod-env’ 網段的 IP”，neutron 就會從打了“ prod-env” label 的 network 中任選一個還沒用完的，從中分一個IP。這樣既將外部系統 與 OpenStack 細節解耦，又提高了可擴展性，因為一個 label 可以對應任意多個 network 。

另外做了一些性能優化，例如增加批量分配 IP 接口、API 異步化、數據庫操作優化等待。

還有就是 backport 一些新 feature 到 neutron，我們的 OpenStack 已經不隨社區一起升級了，都是按需 backport。例如，其中一個對運維和 trouble shooting 非常友好的功能 是 Graceful OVS agent restart。

K8S CNI for Neutron 插件

開發了一個 CNI plugin 對接 neutron。CNI 插件的功能比較常規：

1）為容器創建 veth pairt，并 attach 到 OVS

2）為容器配置 MAC、IP、路由等信息

但有兩個特殊之處：

1）向 neutron（global IPAM）申請分配和釋放 IP，而不是宿主機的本地服務分配（local IPAM）

2）將 port 信息更新到 neutron server

基礎網絡服務升級

另外進行了一些基礎架構的升級，比如 OVS 在過去幾年的使用過程中發現老版本的幾個 bug，后來發現這幾個問題在社區也是有記錄的：

1）vswitchd?CPU 100% [3]

2）流量鏡像丟包 [4]

注意到最新的 LTS 版本已經解決了這些問題，因此我們將 OVS 升級到了最新的 LTS。 大家如果有遇到類似問題，可以參考 [3, 4]。

4.1.3 容器漂移

創建一個容器后，容器網絡配置的流程和圖 10 類似，Nova 和 K8S 只需做如下的組件對應：

• nova?->?kube master

• nova-compute -> kubelet

• nova network driver -> CNI

其流程不再詳細介紹。這里重點介紹一下容器漂移時 IP 是如何保持不變的。

如圖 11 所示，保持 IP 不變的關鍵是：CNI 插件能夠根據容器的labels 推導出 port name，然后拿 name 去 neutron 里獲取 port 詳細信息。port name 是唯一的，這個是我們改過的，原生的 OpenStack 并不唯一。

第二個宿主機的 CNI plugin 會根據 name 找到 port 信息，配置完成后，會將新的?host_id?更新到 netron server；neutron 通知到 CNC，CNC 去原來的交換機上刪除配置 ，并向新的交換機下發配置。

Fig 11. Pod drifting with the same IP within a K8S cluster

4.1.4 小結

簡單總結一下：

1）在保持基礎設施不變的情況下，我們快速地將容器平臺的網絡接入到已有系統

2）一個 IPAM 同時管理了虛擬機、應用物理機和容器的網絡

目前這套新方案的部署規模：

1）4 個可用區

2）最大的可用區有超過 500 個節點（VM/BM/Container 宿主機），其中主要是 K8S 節點

3）單個 K8S 節點最多會有 500+ pod（測試環境的超分比較高）

4）最大的可用區有 2+ 萬個實例，其中主要是容器實例

4.1.5 進一步演進方向

以上就是到目前為止我們私有云上的網絡方案演講，下面這張圖是我們希望將來能達到的一 個架構。

Fig 12. Layered view of the future network architecture

首先會有 underlay 和 overlay 兩個平面。underlay 部署各種基礎設施，包括 Openstack 控制器、計算節點、SDN 控制器等，以及各種需要運行在underlay的物理設備； 在 overlay 創建 VPC，在 VPC 里部署虛擬機、應用物理機實例等。

在 VPC 內創建 K8S 集群，單個 K8S 集群只會屬于一個 VPC，所有跨 K8S 集群的訪問都走服務接口，例如 Ingress，現在我們還沒有做到這一步，因為涉及到很多老環境的軟件和硬件改造。

4.2 公有云上的 K8S

接下來看一下我們在公有云上的網絡。

4.2.1 需求

隨著攜程國際化戰略的開展，我們需要具備在海外部署應用的能力。自建數據中心肯定是來不及的，因此我們選擇在公有云上購買虛擬機或 baremetal 機器，并搭建和維護自己的 K8S 集群（非廠商托管方案，例如 AWS EKS [10]）。 在外層，我們通過 CDOS API 封裝不同廠商的差異，給應用部門提供統一的接口。這樣，我們的私有云演進到了混合云的階段。

網絡方面主要涉及兩方面工作：一是 K8S 的網絡方案，這個可能會因廠商而已，因為不同 廠商提供的網絡模型和功能可能不同；二是打通私有云和公有云。

4.2.2 AWS 上的 K8S 網絡方案

以 AWS 為例來看下我們在公有云上的 K8S 網絡方案。

Fig 13. K8S network solution on public cloud vendor (AWS)

首先，起 EC2 實例作為 K8S node，我們自己開發一個 CNI 插件，動態向 EC2 插拔 ENI， 并把 ENI 作為網卡給容器使用。這一部分借鑒了 Lyft和 Netflix 在 AWS 上經驗 [5, 6]。

在 VPC 內，有一個全局的 IPAM，管理整個 K8S 集群的網絡資源，角色和私有云中的 neutron 類似。它會調用 AWS API 實現網絡資源的申請、釋放和管理。

另外，我們的 CNI 還支持 attach/detach floating IP 到容器。還有就是和私有云一樣， 容器漂移的時候 IP 保持不變。

4.2.3 全球 VPC 拓撲

圖 14 是我們現在在全球的 VPC 分布示意圖。

在上海和南通有我們的私有云 VPC；在海外，例如首爾、莫斯科、法蘭克福、加州（美 西）、香港、墨爾本等地方有公有云上的 VPC，這里畫的不全，實際不止這幾個 region。

Fig 14. VPCs distributed over the globe

這些 VPC 使用的網段是經過規劃的，目前不會跟內網網段重合。因此通過專線打通后，IP 可以做到可路由。

五、Cloud Native 方案探索

以上就是我們在私有云和混合云場景下的網絡方案演進。目前的方案可以支持業務未來一段的發展，但也有一些新的挑戰。

首先，中心式的 IPAM 逐漸成為性能瓶頸。做過 OpenStack 的同學應該很清楚，neutron不是為性能設計的，而是為發布頻率很低、性能要求不高的虛擬機設計的。沒有優化過的話， 一次 neutron API 調用百毫秒級是很正常的，高負載的時候更慢。

另外，中心式的 IPAM 也不符合容器網絡的設計哲學。Cloud native 方案都傾向于 local IPAM（去中心化），即 每個 node 上有一個 IPAM，自己管理本節點的網絡資源分配，calico、flannel 等流行的網絡方案都是這樣的。

第二，現在我們的 IP 在整張網絡都是可漂移的，因此故障范圍特別大。

第三，容器的高部署密度會給大二層網絡的交換機表項帶來壓力，這里面有一些大二層設計本身以及硬件的限制。

另外，近年來安全受到越來越高度重視，我們有越來越強的 3-7 層主機防火墻需求。目前基于OVS 的方案與主流的 K8S 方案差異很大，導致很多 K8S 原生功能用不了。

針對以上問題和需求，我們進行了一些新方案的調研，包括 Calico，Cilium 等等。Calico 大家應該已經比較熟悉了，這里介紹下 Cilium。

5.1 Cilium Overview

Cilium [7]是近兩年新出現的網絡方案，它使用了很多內核新技術，因此對內核版本要求比較高，需要 4.8 以上支持。

Cilium 的核心功能依賴 BPF/eBPF，這是內核里的一個沙盒虛擬機。應用程序可以通過 BPF 動態的向內核注入程序來完成很多高級功能，例如系統調用跟蹤、性能分析、網絡攔截等等。Cilium 基于 BPF 做網絡的連通和安全，提供 3-7 層的安策略。

Cilium 組件：

1）CLI

2）存儲安全策略的 repository，一般是 etcd

3）與編排引擎集成的插件：提供了 plugin 與主流的編排系統（K8S、Mesos 等）集成

4）Agent，運行在每臺宿主機，其中集成了 Local IPAM 功能

Fig 15. Cilium

5.2 宿主機內部網絡通信（Host Networking）

每個網絡方案都需要解決兩個主要問題：

1）宿主機內部的通信：實例之間，實例和宿主機通信

2）宿主機之間的通信：跨宿主機的實例之間的通信

先來看 Cilium 宿主機內部的網絡通信。

Fig 16. Cilium host-networking

Agent 首先會創建一個?cilium_host <---> cilium_net?的 veth pair，然后將它管理的 CIDR 的第一個 IP 作為網關，配置在cilium_host?上。對于每個容器，CNI 插件會承擔創建 veth pair、配置 IP、生成 BPF 規則等工作。

同宿主機內部的容器之間的連通性靠內核協議棧二層轉發和BPF 程序。比如?inst1?到?isnt2，包首先從?eth0?經協議棧到達lxc11，中間再經過BPF 規則到達?lxc22， 然后再經協議棧轉發到達?inst2?的?eth0。

以傳統的網絡觀念來看，lxc11?到?lxc22?這一跳非常怪，因為沒有既沒有 OVS 或 Linux bridge 這樣的二層轉發設備，也沒有 iptables 規則或者 ARP 表項，包就神奇的到達了另一個地方，并且 MAC 地址還被修改了。

類似地，容器和宿主機的通信走宿主機內部的三層路由和 BPF 轉發，其中 BPF 程序連接容器的 veth pair 和它的網關設備，因為容器和宿主機是兩個網段。

5.3 跨宿主機網絡通信（Multi-Host Networking）

跨宿主機的通信和主流的方案一樣，支持兩種常見方式：

• VxLAN 隧道

• BGP 直接路由

如果使用 VxLAN 方式，Cilium 會創建一個名為?cilium_vxlan?的 device 作為 VTEP， 負責封裝和解封裝。這種方案需要評估軟件 VxLAN 的性能能否接受，以及是否需要 offload 到硬件加速。一般來說，軟件 VxLAN 的方式性能較差，而且實例 IP 不可路由。

BGP 方案性能更好，而且 IP 可路由，但需要底層網絡支持。這種方案需要在每個 node 上起一個 BGP agent 來和外部網絡交換路由，涉及 BGP agent 的選型、AS（自治系 統）的設計等額外工作。如果是內網，一般就是 BGP agent 與硬件網絡做 peering；如果 是在 AWS 之類的公有云上，還可以調用廠商提供的BGP API。

5.4 優劣勢比較（Pros & Cons）

最后總結一下 Cilium 方案的優劣勢。

Pros

首先，原生支持 K8S L4-L7 安全策略，例如在 yaml 指定期望的安全效果，Cilium 會自動將其轉化為 BPF 規則。

第二，高性能策略下發（控制平面）。Calico/iptables 最大的問題之一就是集群規模大了之后，新策略生效非常慢。iptables 是鏈式設計，復雜度是?O(n)；而 Cilium 的復雜度是?O(1)?[11]，因此性能非常好。

第三，高性能數據平面 (veth pair, IPVLAN)。

第四，原生支持雙棧 (IPv4/IPv6)。事實上 Cilium 最開始只支持 IPv6，后面才添加了對 IPv4 的支持，因為他們一開始就是作為下一代技術為超大規模集群設計的。

第五，支持運行在 flannel 之上：flannel 負責網絡連通性，Cilium 負責安全策略。如果你的集群現在是 flannel 模式，遷移到 Cilium 會比較方便。

最后，非常活躍的社區。Cilium 背后是一家公司在支持，一部分核心開發者來自內核社區 ，而且同時也是 eBPF 的開發者。

Cons

首先是內核版本要求比較高，至少 4.8+，最好 4.14+，相信很多公司的內核版本是沒有這么高的。

第二，方案比較新，還沒有哪家比較有名或有說服力的大廠在較大規模的生產環境部署了這種方案，因此不知道里面有沒有大坑。

第三，如果要對代碼有把控（稍大規模的公司應該都有這種要求），而不僅僅是做一個用戶 ，那對內核有一定的要求，例如要熟悉協議棧、包的收發路徑、內核協議棧數據結構、 不錯的 C 語言功底（BPF 程序是 C 寫的）等等，開發和運維成本比基于 iptables 的方案 （例如 Calico）要高。

總體來說，Cilium/eBPF 是近幾年出現的最令人激動的項目之一，而且還在快速發展之中。 我推薦大家有機會都上手玩一玩，發現其中的樂趣。

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

總結

以上是生活随笔為你收集整理的干货 | 云计算时代携程的网络架构变迁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。