Kubernetes網絡方案的三大類別和六個場景

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

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

今天我將分享我的對於網絡方案的理解，以及網易雲在交付 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、架構及運維等問題，使企業更聚焦於業務，是新一代的雲計算平臺，點擊可免費試用。

相關文章：
【推薦】 金融事業部QA培訓體系
【推薦】 virtualenv簡介以及一個比較折騰的scrapy安裝方法
【推薦】 Omad羣組部署、依賴部署一鍵解決