導(dǎo)語：

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

04?總結(jié)

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

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

總結(jié)

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

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