為啥Underlay才是容器網(wǎng)絡(luò)的最佳落地選擇

導(dǎo)語：

幾年前，當(dāng)博云啟動(dòng)自研容器網(wǎng)絡(luò)研發(fā)的時(shí)候，除了技術(shù)選型的考慮，我們對于先做 Underlay 還是 Overlay 網(wǎng)絡(luò)也有過深度的 討論 。當(dāng)時(shí)的開源社區(qū)以及主流容器廠商，多數(shù)還是以 Overlay 網(wǎng)絡(luò)方案為主，但在我們對眾多客戶真正需求的深入了解之后，發(fā)現(xiàn)部分客戶對容器內(nèi)外網(wǎng)絡(luò)直通有著非常強(qiáng)烈的需求。思慮再三，我們決定還是先做 Underlay 網(wǎng)絡(luò)（后來又做了Overlay）。隨著行業(yè)與公司自身的發(fā)展，我們建設(shè)實(shí)施的項(xiàng)目越來越多，這讓我們對容器網(wǎng)絡(luò)的思考也越來越深入，從而觀點(diǎn)也越來越清晰：

內(nèi)外直通的Underlay網(wǎng)絡(luò)才是容器網(wǎng)絡(luò)的正確打開方式。

01

從需求出發(fā)，考慮容器網(wǎng)絡(luò)方案

如上圖所示，這是目前企業(yè)微服務(wù)容器化部署的典型場景，也是驅(qū)動(dòng)我們做 Underlay網(wǎng)絡(luò)的直接原因：

1. 服務(wù)部署在Kubernetes集群內(nèi)部（如圖：服務(wù)1、服務(wù)2）；

2. 數(shù)據(jù)庫、注冊中心、Redis、MQ等組件部署在集群之外；

3. 部分服務(wù)也可能部署在集群之外, 比如容器平臺(tái)試用階段（如圖：服務(wù)3）

這些服務(wù)和組件，需要能直接互聯(lián)互通。

如若需要滿足以上需求，最簡單有效的方案就是直接把 Kubernetes 內(nèi)外網(wǎng)絡(luò)打通，也就是采用 Underlay 網(wǎng)絡(luò)模式。

當(dāng)然，如上需求也有別的辦法可以解決。比如，細(xì)化分析服務(wù)和組件間的流量，采用ingress、egress，包括改寫應(yīng)用代碼等方式，在特定情況下，這也是可以用的。然而，一方面，這些都是特定場景下的特定解決方案，缺乏一定的通用性；另一方面，容易出現(xiàn)配置復(fù)雜、引入額外風(fēng)險(xiǎn)、出錯(cuò)難以定位等問題。遠(yuǎn)遠(yuǎn)沒有通過Underlay網(wǎng)絡(luò)直接將內(nèi)外網(wǎng)打通這么簡單有效。

還有另外的辦法就是將所有服務(wù)和組件都放入Kubernetes集群內(nèi)部，但是這種方案仍是針對特定場景的非通用方案，很難保證企業(yè)所有的應(yīng)用都在一個(gè)Kubernetes集群里。

同樣，對于容器內(nèi)外網(wǎng)絡(luò)直接互聯(lián)互通的需求場景還有：

• 特定用途的Kubernetes集群對外提供服務(wù)。比如專門用作提供PaaS中間件服務(wù)的Kubernetes集群、專門用作CI/CD服務(wù)的Kubernetes集群、專門用作提供大數(shù)據(jù)服務(wù)的Kubernetes集群等；

• 跨多集群的服務(wù)/組件互聯(lián)互通；

• 為了在試點(diǎn)階段降低風(fēng)險(xiǎn)，部分服務(wù)跑在集群內(nèi)、部分服務(wù)跑在集群外 等場景。

02

與虛擬機(jī)對比，從容器本質(zhì)考慮容器網(wǎng)絡(luò)方案

在容器的應(yīng)用實(shí)踐過程中，除了應(yīng)用場景，我們也從底層基礎(chǔ)設(shè)施的角度對容器進(jìn)行了持續(xù)的思考。

從基礎(chǔ)設(shè)施的角度看容器： 容器和虛擬機(jī)的本質(zhì)都是一樣的，是上層應(yīng)用的承載基礎(chǔ)設(shè)施。

因此，從底層角度看，對容器網(wǎng)絡(luò)的需求跟虛擬機(jī)是一致的。那么，虛擬機(jī)網(wǎng)絡(luò)的落地模式是怎樣的呢?

如上圖右側(cè)部分所示，IaaS層的落地網(wǎng)絡(luò)方案可以認(rèn)為是有行業(yè)標(biāo)準(zhǔn)的，不管是基于VMware 還是 OpenStack，基本都是采用OVS（或類似OVS）的二層 Underlay 網(wǎng)絡(luò)方案。

因此，從基礎(chǔ)設(shè)施的角度往上看，容器網(wǎng)絡(luò)采用跟 IaaS 類似的方案，即將虛擬機(jī)和容器放到同一個(gè)網(wǎng)絡(luò)層面上，是最合理的選擇。

PS：在公有云上，虛擬機(jī)都在VPC里，因此目前公有云的容器網(wǎng)絡(luò)方案，也是主要采用將容器和虛擬機(jī)放到同一個(gè)VPC中，可以直接互聯(lián)互通的方案。這也是對上述判斷的典型證明。

同時(shí)，對于部分客戶反饋的 Unberlay 網(wǎng)絡(luò)占用 IP 地址過多的問題，從虛擬機(jī)和容器的對比角度，也可以獲得合理的解釋：如果使用虛擬機(jī)部署，占用 IP 地址數(shù)量與容器 Underlay 網(wǎng)絡(luò)是一樣的。IP 地址的數(shù)量是由應(yīng)用數(shù)量決定的，使用容器并沒有引入多余 IP 地址占用。另外，Ipv6已經(jīng)開始規(guī)模落地，在Ipv6時(shí)代，IP 地址數(shù)量將不會(huì)是問題。

03

技術(shù)方案選型

容器典型的開源  Unberlay 網(wǎng)絡(luò)選型方案有 Calico 和 MACVLAN，這兩個(gè)方案的問題也比較明顯：

Calico ：需要在數(shù)據(jù)中心路由器（或三層交換機(jī)）打開 BGP 路由協(xié)議，而 BGP 是廣域網(wǎng)的路由協(xié)議，一般在數(shù)據(jù)中心內(nèi)部不會(huì)啟動(dòng)，低端三層交換機(jī)/路由器對齊的支持情況也有風(fēng)險(xiǎn)。

MACVLAN： 幾年前有部分客戶采用此容器網(wǎng)絡(luò)方案，MACVLAN最大的問題就是社區(qū)活躍度已經(jīng)很低，一些問題長期沒有在社區(qū)中解決。同時(shí)，面向未來的擴(kuò)展性也比較差。

以上也是博云基于 OVS 自研 Underlay（也支持Overlay）網(wǎng)絡(luò)的原因。

04

總結(jié)

在容器網(wǎng)絡(luò)方案中，Overlay網(wǎng)絡(luò)方案有著對底層網(wǎng)絡(luò)要求低（落地過程不需要跟網(wǎng)絡(luò)部門打交道）、落地容易、IP地址占用少等特點(diǎn)，也有自己適用的特性需求場景。但是隨著越來越多的客戶將 Kubernetes 和容器大規(guī)模應(yīng)用到生產(chǎn)環(huán)境中，博云客戶中選擇使用 Underlay 網(wǎng)絡(luò)模式的比例也越來越高。這讓我們更加明確認(rèn)識(shí)到：

內(nèi)外直通的Underlay網(wǎng)絡(luò)才是容器網(wǎng)絡(luò)的正確打開方式。