導(dǎo)語(yǔ)：

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03?技術(shù)方案選型

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

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

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

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

04?總結(jié)

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

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

總結(jié)

以上是生活随笔為你收集整理的为啥Underlay才是容器网络的最佳落地选择的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。