歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

本文章根據網易雲資深解決方案架構師 王必成在雲原生使用者大會上的分享整理。

今天我將分享個人對於網路方案的理解，以及網易雲在交付 Kubernetes 場景時的一些網路實踐。

本文分為兩部分：

第一部分：常見容器網路方案；

第二部分：網易雲基於 VPC 深度整合的 Kubernetes 網路實踐。

常見容器網路方案

常見容器網路方案分類  

常見的容器網路方案可以從協議棧層級、穿越形態、隔離方式這三種形式進行劃分。

協議棧層級：

第一種：協議棧二層。協議棧二層比較好理解，在以前傳統的機房或虛擬化場景中比較常見，就是基於橋接的 ARP+MAC 學習，它有什麼缺陷呢？它最大的缺陷是廣播。因為二層的廣播，會限制節點的量級。

第二種：協議棧三層（純路由轉發）。協議棧三層一般基於 BGP，自主學習整個機房的路由狀態。它最大的優點是它的 IP 穿透性，也就是說只要是基於這個 IP 的網路，那此網路就可以去穿越。顯而易見，它的規模是非常有優勢，且具有良好的量級擴充套件性。但它也存在問題：在實際部署過程中，因為企業的網路大多受控。比如，有時企業網路的 BGP 是基於安全考慮不給開發者用，或者說企業網路本身不是 BGP，那這種情況下你就沒辦法了。 

第三種：協議棧二層加三層。為什麼會出現這種方案？在說二層加三層的優點之前，先提一下它的缺點。缺點是節點內部是一個子網，這對於運維同學來說很苦惱。因為大家都習慣利用傳統的雲化場景，希望每一個獨立可見的應用有一個獨立的 IP，且不會改變。這一點，二層加三層做不到。但是這個方案比較符合 Kubernetes 對於 Pod 網路假設，Pod 會漂移，IP 也會改變，不變的是 Service 和 Ingress。

但它的優點是它能夠解決純二層的規模性問題，又能解決純三層的各種限制問題，特別是在雲化 VPC 場景下可以利用 VPC 的三層轉發能力。所以，如今你看到的實際部署 Kubernetes 的網路方案中，二層加三層也比較多。後面的章節，我們再詳述那些常見的方案。

穿越形態：

按穿越的形態劃分，這個與實際部署環境十分相關。穿越形態分為兩種：Underlay、Overlay。

Underlay：在一個較好的一個可控的網路場景下，我們一般利用 Underlay。可以這樣通俗的理解，無論下面是裸機還是虛擬機器，只要網路可控，整個容器的網路便可直接穿過去 ，這就是 Underlay。

Overlay：Overlay 在雲化場景比較常見。Overlay 下面是受控的 VPC 網路，當出現不屬於 VPC 管轄範圍中的 IP 或者 MAC，VPC 將不允許此 IP/MAC 穿越。出現這種情況時，我們都利用 Overlay 方式來做。

隔離方式：

隔離方式與多種戶型相關（使用者與使用者之間的隔離方式），隔離方式分為 FLAT、VLAN、VXLAN 三種：

• FLAT：純扁平網路，無隔離；
  

• VLAN：VLAN 機房中使用偏多，但實際上存在一個問題？就是它總的租戶數量受限。眾所周知，VLAN 具有數量限制。
  

• VXLAN：VXLAN 是現下較為主流的一種隔離方式。因為它的規模性較好較大，且它基於 IP 穿越方式較好。
  

大家如今看到的所有的容器網路方案，都是由這三種不同的分類所組建起來的。

常見容器網路方案  

這些是目前在實際部署中的所有容器網路方案。

Calico：基於 BGP 的三層 Underlay。它的 IP 隧道是當網路受控時的一種妥協的三層 Overlay 且支援 Network policy。

Contiv：Contiv 方案，功能非常全，我們可以看到它有二層橋接，基於 VLAN 的網路 ；有三層路由，基於 BGP 的網路；同時它可以支援 Overlay，通過 VXLAN，去應對一些受控的網路環境，提供 ACI 去支援網路策略。

Flannel：host-gw 模式，節點內部子網，節點之間通過路由指過去。但是這種方式存在限制。當它直接指引過去時，要求你所有節點在同個二層裡。因為你直接指過去，將不能穿越不同子網。

在不能穿越子網時，應該如何處理？通過 VXLAN 的方式來解決，它可以幫助你把報文在二層網路上穿越。VPC vRouter，是公有云廠商的一些場景，通過自定義路由，Flannel 幫助你完成與各個不同公有云廠商的 VPC vRouter 對接。目前在雲化場景裡面，這是一個非常主流的方案。

Openshift SDN：基於 VXLAN 的二層+三層 Overlay 方案，同時支援 network policy，資料面基於 OVS 流表實現。

Kubenet + VPC 自定義路由：在公有云平臺中，它自行搭建 Kubernetes 叢集時使用較多。它會利用公有云平臺本身自帶的 VPC vRouter，配合 Kubernetes 自帶的節點子網方式，用路由方式去完成整個容器網路的轉發。

傳統機房自定義路由：比如你的 BGP 不管用且受控，或不是 BGP。應該怎麼辦？這種情況，我們在實際部署時也遇到過。首先，運維將這個核心路由進行配置。每個節點對應一條核心路由，也可以使用。

目前大家看到的所有容器網路方案，都可以應用到前面的三個分類。

分別適用什麼場景 

他們分別適用什麼場景？我們簡單地把現在部署的容器網路場景分為兩大類：傳統機房網、雲化 VPC 網路。無論是傳統機房網 ，還是雲化 VPC 網路。我們可以看到 Overlay 方案是通用的，它在雲化場景裡可能用的更多一些，因為它有很好的穿越性。

在上圖紅線實線指向，需要重點說明。Underlay + 三層的方案，是傳統機房網路非常流行的方案，同時它的效能非常可觀，這個在我們的客戶場景應用比較偏多。Underlay + 二層 + 三層的方案，在雲化 VPC 場景（特別是公有云）也是比較主流的一個方案，藉助 VPC 的自定義路由完成轉發。

紅色虛線指向，Underlay + 三層網路在雲化 VPC 場景下，也是可以受限使用。受限使用顧名思義，可以使用但不是每個供應商都讓你用，因為每一個雲廠商對他自己網路保護的定義不一樣。比如像 Calico 方案，它的 BGP 在 AWS 中就容易做，但在 Azure 中就不允許，因為 Azure 的 VPC 本身是不允許不受它管控範圍的 IP 通過。

在雲化 VPC 場景下存在哪些問題  

在雲化的 VPC 情況下，目前我們能看到這些網路方案都存在一些問題。

第一個問題：不關你是哪一種方案，你都需要管理兩套網路策略，一套是 VPC 層的安全組等；另一套是 Kubernetes 的 network policy。如此，你的管理成本是比較偏高的。

第二個問題：在 BGP 場景下，BGP Underlay 即使能使用但它是無法跨越多 AZ。如今，公有云廠商中跨越 AZ 一般意味著跨子網，跨子網就意味著跨越路由，但是很可惜 VPC 的 vRouter 一般不支援 BGP。BGP Underlay 可以用，但也僅限於單 AZ。

在 VPC 自定義路由的場景下（非常主流的一種網路使用方式），存在什麼問題呢？第一，節點規模受限於路由表數量，一般的廠商都會在 100 以下， AWS 支援 50 條，阿里雲預設 48 條。第二，多次網路跳轉，效能略有下降，你在節點層要跳一次，在 VPC 裡也要跳一次 ，使之效能有所影響。

之前我們說到 Overlay 場景很通用，但同時又存在兩層 Overlay 開銷問題 。IaaS 層一般有一層，容器層有一層，效能下降是非常明顯的。對於這種 PPS 敏感型業務，很明顯是不能接受的，怎麼辦呢？所以我們看到，基於 VPC 深度整合的容器網路。

基於 VPC 深度整合的容器網路  

目前很多廠商也有類似的方案，比如說 AWS EKS 的 VPC CNI 外掛，Azure AKS 的 VNET CNI 外掛，阿里雲現在公測的 Terway。基於 VPC 這種深度整合的容器網路，把 VPC 的能力上移到容器網路這一層，用 VPC 的能力去做轉發與控制。

基於 VPC 深度整合的 Kubernetes 網路實踐

接下來，為大家講解網易雲如何基於 VPC 深度整合 Kubernetes 網路。首先，這裡有很多方案，在這裡我將它們都列出來。

第一個方案，我們叫基於 VPC 單 Port 多 IP 的扁平化容器網路。如圖所示：下面是物理機，上面大框是虛機，裡面白色的小框是 Pod。第一種方式，每一臺虛擬機器，在申請完都會有一個虛擬網絡卡。

現在設計多個容器，多個 Pod 要怎麼辦呢？每申請一個 Pod，在下層的 VPC 申請一個 VPC IP，綁到這個虛擬機器的埠上，然後通過 veth pair（就是容器的空間和 GuestOS 的空間連起來），把 Pod 裡的 IP 配置上，再配置策略路由，就有一個在節點內部的轉發。

節點外部如何轉發？通過 VPC 的埠弄出來。但是這種方式存在什麼問題？第一個問題，Pod 粒度網路策略缺失。為什麼會出現此種問題？因為你從底層只申請一個埠。網路策略一般在 VPC，都在埠級別。

Pod 內部的網路策略是需要自己做，需要跑兩套網路策略。第二個問題，QoS 同樣如此。就是你埠粒度的 Port， QoS 需要自己做。第三個問題，單虛擬機器上 Pod 數量有限制。這是因為 VPC 對於這個埠的 IP 數量有限制，也是就是 Pod 數量有限制。

第二個方案，基於 VPC 多 Port 方案的扁平化容器網路，大家比較容易理解，簡單來說就是每建立一個 Pod，你申請一個埠，就可以直接把這個虛擬網絡卡移到 Pod 虛擬空間裡。但是存在什麼問題呢？

如果我直接移上去之後，繞開這個節點的 Kubernetes-Proxy，報文一旦不經過它，原有的 Pod 的能力，比如 Sevice 的轉發解析怎麼辦？這個就會失效。這個問題應該如何解決？另一個問題，原有的一些網路方案的網路策略，QoS 也可能會失效，因為報文沒有經過 host 協議棧，任何方案都沒有用。

我們的解決方案  

第一種方案：基於 VPC VIP 的 Service。利用 VPC VIP，每建立一個 Sevice，就同時申請一個 VPC VIP。然後用這個 VIP 把原來的 CluserIP 換掉，再把 endpoint 加到 VIP 的後端。當流量進到二層後，它就會進入到 VIP 中，然後進行轉發。但是這裡有一個問題，目前的 Kubernetes ClusterIP 是在 API Server 裡做的。在這個方案中，比較糟糕的是在設計時需要修改這一塊的程式碼。

第二種方案：通過 VPC 的埠安全組，實現 Pod 粒度的網路策略。比如，兩個 APP 互相之間要有通訊，我就可以在 Pod 的埠上做文章，把這個 Policy 實現。但是有個問題 ，你需要完成對 Kubernetes 整個網路策略進行語義轉換。在 Kubernetes 的網路策略中，同一個 Namespace 裡面的哪些 Pod 能夠訪問哪些 Pod 的哪些埠，哪些 Namespace 能夠訪問哪些 Pod 的哪些埠，那麼你必須完成這種語義轉換。

第三種方案：基於 VPC Port 的 QoS 保證。那麼你可以在 VPC 的 Port 上，去完成這個 QoS 在每一個 Pod 的類似保證，但是還是一樣有問題，就是你怎麼去跟這個 IaaS 的整個原始 QoS 設計去協同。

我們知道，在這個公有云或私有云的主機上（Hypervisor），一般來講它的網路能力一般是主流的 10G 網絡卡，也就是說整個主機上的所有流量，不管是虛機負載還是虛機裡面的 Pod 負載，進出都是 10G。

一般來講，他們對雲主機都會做限速，虛機預設就是有 1Gbs 流量的限速。如今到了這個容器級別，你的虛機裡面就會跑很多個容器，那你的量級會產生變化。而且以前你在一個 Pod 級別做了一個 QoS，那我們是不是要考慮虛擬機器的能力？

你要考慮整個 Kubernetes 的設計，所以它其實是有一個很強的 QoS 的設計層級在裡面的。那但是這個具體的細節,因為時間的關係不再進行講解，下次再與大家分享。

結語

此次主要為同學們介紹常見的容器網路方案分類、主流的容器網路方案和其適用的場景，重點論述  VPC  場景下不同方案存在的問題；最後為同學們介紹網易雲在 VPC 場景下深度整合的容器網路方案的一些設計和實踐。後續有機會再為各位同學詳細介紹，我們在高效能資料面方面的一些想法和設計。

網易雲端計算基礎服務深度整合了 IaaS、PaaS 及容器技術，提供彈性計算、DevOps 工具鏈及微服務基礎設施等服務，幫助企業解決 IT、架構及運維等問題，使企業更聚焦於業務，是新一代的雲端計算平臺，點選可免費試用。

相關文章：
【推薦】 雲架構師進階攻略（1）