近兩年，容器已經(jīng)隨著 Docker 技術(shù)的傳播火遍全球，現(xiàn)在已經(jīng)有越來越多的企業(yè)用戶在開發(fā)、測試甚至生產(chǎn)環(huán)境中開始采用 Docker 等容器技術(shù)。
然而，目前主流的 Docker 管理平臺，比如 K8S，當企業(yè)想構(gòu)建一套網(wǎng)絡方案，需要精通 Linux 提供的各種高級網(wǎng)絡功能，這個技術(shù)門檻太高了。特別是對專注于業(yè)務開發(fā)的 Docker 用戶而言，這類操作往往顯得過于復雜。
而且，由于在虛機中部署容器，云平臺和 Docker 平臺都有自己的虛擬化網(wǎng)絡實現(xiàn)方案，二者功能重疊，使用時會相互嵌套，導致的其網(wǎng)絡性能損耗非常嚴重，甚至達到 80%。
所以，雖然容器技術(shù)正在逐步被大家認可與應用，但其網(wǎng)絡性能以及配置的復雜程度一直都在被大家所詬病。今天的內(nèi)容，將會給大家介紹一種容器部署方案，幫助大家解決網(wǎng)絡這個難題。
首先，我們先看看 Docker 提供了哪些網(wǎng)絡功能，Docker 的網(wǎng)絡模型是這樣的:
Docker 的網(wǎng)絡結(jié)構(gòu)分為 3 個層次：Network、Endpoint 和 Container。對比到物理設備可以這么理解：Network 是交換機，Endpoint 是網(wǎng)卡，Container 就是服務器。
決定 Network 這個交換機的工作方式的組件，就是 Network Driver。常用的 Driver 有兩個：
Bridge Driver
Bridge Driver 是種比較直接的方式：Bridge 指的是 Linux Kernel 實現(xiàn)的虛機交換機。每個網(wǎng)絡在宿主機上有一個 Bridge 實例，默認是 Docker0，有對應的 IP 地址和網(wǎng)段，每個 Docker 實例從網(wǎng)段里面分配一個地址。結(jié)構(gòu)如下：
在同一個 Bridge 下的 Endpoint 是一個二層網(wǎng)絡，要實現(xiàn)跨宿主機的 Endpoint 之間通信，只能走三層網(wǎng)絡，也就是通過路由轉(zhuǎn)發(fā)過去。要對外提供服務，還需要對宿主機的 IP 端口做轉(zhuǎn)換(Nat)。這種情況下主要網(wǎng)絡性能損失發(fā)生在端口轉(zhuǎn)換(Nat)和路由上面。
同時這也和青云 SDN 1.0 里面的基礎網(wǎng)絡實現(xiàn)方式是完全一樣，優(yōu)點是結(jié)構(gòu)簡單可靠，缺點也很明顯: 不能把多個宿主機連成一個二層網(wǎng)絡。這個問題會導致 Docker 實例的 IP 地址，必須跟當前宿主機定義的網(wǎng)段一致。如果啟動到別的宿主機上，IP 就需要更換。
Overlay Driver
Overlay Driver 的作用是把位于多個宿主機的 Docker 實例連接在一個虛擬的二層網(wǎng)絡里面。相比 Bridge，在功能上有一定進步，本質(zhì)上是一個分布式的虛擬交換機。
舉個送快遞的例子，方便大家理解：有的公司對員工提供內(nèi)部郵件的服務，位于不同寫字樓的員工可以用工位號互發(fā)郵件。公司的收發(fā)室拿到郵件后，會重新再打個包，上面寫著雙方寫字樓的地址，交給真正的快遞公司去投遞。收件方的收發(fā)室會拿到郵件后，會拆掉外面的信封，把里面的郵件按工位號送給收件的員工。
這例子里面，工位號就是 Underlay 的地址， 寫字樓的地址是 Overlay 的地址。Docker 的這個虛擬二層網(wǎng)絡，就是企業(yè)內(nèi)部郵件，但是真正派件的還是快遞公司。跟普通快遞相比，多了個環(huán)節(jié)：收發(fā)室對郵件重新包裝，不僅打包費時間，多的包裝也占了重量，也就帶來了額外的性能損失。
目前，Overlay 模式的虛擬網(wǎng)絡應用已經(jīng)很普遍，青云給用戶提供的虛擬二層網(wǎng)絡也是相同的工作原理。
Docker 目前有兩種方式部署：
今天和大家分享的就是為什么要在云平臺上部署 Docker。
雖然看起來在公有云的虛擬機部署 Docker 的做法比較奇葩，目前也沒有公有云能讓用戶直接部署 Docker 在物理機上，當然，Softlayer 這種物理機托管的云除外。
因為 Docker 本身的安全性還不夠讓人放心。雖然 Docker 已經(jīng)有各種安全保護，包括 Namespace 提供的隔離機制、Selinux、Apparmor 等安全機制，以及近才有的Unprivileged Container 功能來控制 Docker 實例在宿主機上的用戶權(quán)限，但是由于容器的本質(zhì)是跟宿主機共用同一個 Linux Kernel，一旦 Kernel 本身有安全漏洞，就有可能被 Docker 用戶利用，侵入到云平臺的物理機。
比如幾個月前發(fā)現(xiàn)的 COW 漏洞，就有可能讓 Docker 實例獲得物理機的 Root 權(quán)限，實現(xiàn)容器的“越獄”。這個漏洞存在了十幾年才被人發(fā)現(xiàn)，完全有可能還有很多類似漏洞存在，只是沒有被公開而已。
所以，公有云直接讓用戶在多租戶的物理機上運行 Docker，是極不安全的做法。
因此，要在公有云使用 Docker，就只有在虛擬機里面運行 Docker 這一個選擇。那么在公有云上部署 Docker 業(yè)務，存在哪些問題呢？其實，主要還是性能和功能兩方面。
網(wǎng)絡性能
網(wǎng)絡虛擬化的本質(zhì)是用軟件實現(xiàn)物理網(wǎng)卡和交換機的功能，因此虛擬網(wǎng)絡中的所有流量都會消耗 CPU 資源。
Linux 在處理網(wǎng)絡流量時，有幾個方面會消耗 CPU：
其中 1 和 2 占的 CPU 消耗較高，這是因為地址轉(zhuǎn)換和路由都會對數(shù)據(jù)包的包頭做修改，并重新計算 Checksum， 而且地址轉(zhuǎn)換還需要查詢 Conntrack 的連接表和 IPtables 的地址轉(zhuǎn)換規(guī)則，這些功能都是全靠宿主機的 CPU 完成。
云平臺提供的 SDN 網(wǎng)絡，是層網(wǎng)絡虛擬化，已造成一定的性能損失。但是可以通過利用物理網(wǎng)卡的硬卸載功能，比如 Vxlan Offload， 具體包括 Gso、Gro、Rx Checksum 等在這一層減少虛擬化帶來的部分性能損失。
雖然容器本身由于跟宿主機共享 Kernel 的這個特性，相比 VM 網(wǎng)絡性能更好，沒有 第 5 條的損失，但是 Docker 搭建的虛擬網(wǎng)絡，仍然會帶來顯著的性能損失。
同時，由于第二層虛擬化無法利用硬卸載功能，所以性能損失通常會高于層。兩層網(wǎng)絡虛擬化帶來的性能損耗相疊加，將顯著影響網(wǎng)絡性能。
舉個例子：
在上海一區(qū)（SH1A），使用 IPerf -C 命令進行的基本性能測試 (關閉云平臺的網(wǎng)絡限速)結(jié)果如下：
虛擬主機之間：帶寬 9Gbps；
虛擬主機內(nèi)：使用 Docker Overlay 插件的 Docker 實例之間帶寬下降為 2.3 Gbps。
由此可見，這種使用 Docker Overlay 的方案會帶來近 3/4 的性能損耗。而如果算上對外提供服務所需要的地址轉(zhuǎn)換帶來的性能損失，整體性能損失將更為巨大。
配置復雜
首先，Docker 自身的網(wǎng)絡復雜。Bridge 和 Overlay 都需要配合地址轉(zhuǎn)換功能使用，而地址轉(zhuǎn)換的規(guī)則不僅多，而且復雜。
我近遇到個私有云客戶，其在云平臺上面部署基于 K8S 的業(yè)務系統(tǒng)。他們遇到一個問題，同一個宿主機的 Docker 實例之間，用 K8S 提供的業(yè)務 IP 無法訪問，而不同宿主機之間用相同的 IP 訪問正常。
這個開發(fā)團隊，通宵加班好幾天，也沒搞清楚怎么回事，來找我?guī)兔鉀Q。這個問題實際上是因為 K8S 少下發(fā)了一條 IPtables 規(guī)則，沒有對同宿主機的這種情況做源地址轉(zhuǎn)換。
這個問題對熟悉 Linux 網(wǎng)絡功能的人來說，不是什么難題，但是對專注于業(yè)務開發(fā)的 Docker 用戶而言，可就很難解決了。
我說這個例子的目地就是要說明，配置 Docker 虛擬網(wǎng)絡是件難度很高的事情。
另一方面，要在云平臺上面，使用 Docker 對外提供服務，還需要跟云平臺的網(wǎng)絡做整合。
通常是在云平臺的 IP 和 Docker 的 IP 之間做地址轉(zhuǎn)換。本身 Docker 實現(xiàn)這些功能就比較復雜，而在此基礎上，再做一層地址轉(zhuǎn)換，會帶來額外的復雜度。
使用 Docker 管理平臺的初衷是簡化產(chǎn)品部署，而通過這樣的方式跟云平臺整合，卻與這一方向背道而馳。
性能問題的根源在于云平臺和 Docker 平臺都有自己的虛擬化網(wǎng)絡，二者功能重疊，使用時相互嵌套。而配置復雜的難度一個是 Docker 自身網(wǎng)絡復雜，另一個方面是跟云平臺的網(wǎng)絡整合也復雜。
目前青云的 SDN 直通方案通過讓 Docker 實例掛載云平臺提供的虛擬網(wǎng)卡的方式，讓 Docker 實例直接使用云平臺的 SDN 功能，代替 Docker 的虛擬網(wǎng)絡。
一方面減少了第二層虛擬網(wǎng)絡的性能損失；另一方面，云平臺的 SDN 是通過 API 和控制臺封裝好的服務，Docker 直接使用就可以了，不需要自己再配置 Docker 的網(wǎng)絡，所以大幅降低了使用難度。
SDN 網(wǎng)絡直通方案包含兩個方面：
插件已經(jīng)開源，地址是 https://Github.Com/Yunify/Docker-Plugin-Hostnic
這是青云Qingcloud 自主開發(fā)的一款 Docker 網(wǎng)絡插件。在啟動 Docker 實例的時候，通過該插件，可以將虛擬主機上的綁定的多個網(wǎng)卡一一掛載到 Docker 實例上, 并可以配置 IP 地址和路由。
啟動之后，Docker 實例就加入了云平臺 SDN 提供的網(wǎng)絡，能夠使用云平臺所有的網(wǎng)絡功能。云平臺網(wǎng)卡管理，就是能夠讓虛擬主機掛載多個網(wǎng)卡。網(wǎng)卡對應到 Docker 的網(wǎng)絡組件，就是Endpoint，這個設備受云平臺管理，底層由 SDN 內(nèi)部的控制器下發(fā)規(guī)則，可以使用 DHCP 管理 IP 地址，并接入所有云平臺的網(wǎng)絡模塊。
相比 Docker 的網(wǎng)絡功能，青云的網(wǎng)卡可以提供更多的功能:
VPC
前面說過，Docker 的 Overlay 網(wǎng)絡實際上是虛擬的二層網(wǎng)，而 VPC 提供的是一個虛擬的三層網(wǎng)。可以理解為一個分布式的核心交換機。青云的 VPC 多可以創(chuàng)建 252 個虛擬網(wǎng)絡，容納超過 6 萬臺虛擬主機。
就技術(shù)上來看，虛擬二層網(wǎng)使用 Vxlan 實現(xiàn)，是現(xiàn)在較成熟的技術(shù)。而虛擬的三層網(wǎng)，是 SDN 技術(shù)的一個關鍵點，因為它背后需要有個分布式網(wǎng)關才能做到虛擬機數(shù)量增加時，VPC 整體網(wǎng)絡性能不變。
目前 SDN 廠商和技術(shù)好的云計算公司都有各自的實現(xiàn)，還沒有看到靠譜的開源產(chǎn)品能夠做到。
當 Docker 掛載上青云的網(wǎng)卡時，就加入了對應的 VPC，跟其他實例連在了一起。用戶可以根據(jù)網(wǎng)卡對應的網(wǎng)絡來定義實例間是二層還是三層聯(lián)通。
公網(wǎng) IP
每個網(wǎng)卡可以綁定自己獨享的公網(wǎng) IP，也可以使用 VPC 共享的公網(wǎng) IP 對外提供服務。公網(wǎng)和私網(wǎng)地址的轉(zhuǎn)換，由云平臺的分布式網(wǎng)關來做，不需要 Docker 配置任何 IPtables 規(guī)則。
負載均衡器
網(wǎng)卡可以作為負載均衡器的后端，以集群的方式，對外提供高可用和高性能的服務。相比 Docker 的負載均衡器，青云的負載均衡器有許多優(yōu)點:
給虛擬主機掛載網(wǎng)卡之后，需要使用到 Hostnic 插件，有 3 步：
這樣就完成了對 Docker 實例網(wǎng)絡的所有功能配置。
前面說的公網(wǎng) IP、負載均衡器和防火墻，都可以通過青云控制臺、SDK、 CLI 或者 API 的方式去單獨配置。對這些功能使用上有疑問的話，可以通過工單跟我們的工程師溝通，不必在死磕 Docker 那些復雜的網(wǎng)絡配置。
除了青云自己研發(fā)的 Hostnic，現(xiàn)在已經(jīng)有另外一款 Docker 插件支持青云 SDN 直通。是希云Csphere 開發(fā)的 Qingcloud-Docker-Network，同樣也已經(jīng)開源： Https://Github.Com/Nicescale/Qingcloud-Docker-Network 。
跟 Hostnic 相比，這款插件整合了青云 API，能夠在啟動 Docker 實例時，自動創(chuàng)建，并綁定網(wǎng)卡，使用起來更方便一些。
對于公有云，目前只能選擇在虛擬主機里面使用 Docker，但是對于私有云，可以在青云提供的容器主機里面部署 Docker。
容器主機的工作原理跟 Docker 一樣，都是用到了 Linux Kernel 的容器技術(shù)，但是用起來更接近虛擬主機，有著幾乎相同的功能，比如：掛載 SSH 密鑰、Web Terminal、鏡像制作、備份等功能，跟虛擬主機鏡像全兼容，還能做到在線擴容 CPU、內(nèi)存、系統(tǒng)硬盤。
也就是說，對于私有云用戶，可以使用跟公有云虛擬主機完全一樣的操作方式，在容器主機里面部署 Docker，從而減少 KVM 虛擬化這一層在性能上的損失，能達到接近物理機的性能。
跟直接在物理機上部署 Docker 相比，使用容器主機可以有云平臺便捷的功能，比如秒級創(chuàng)建或者消毀一個容器主機。云平臺的副本可以保證物理機宕機后，通過離線遷移，迅速恢復業(yè)務。再加上前面說的這些云平臺的網(wǎng)絡功能，為構(gòu)建用戶業(yè)務集群，節(jié)省大量時間。同時青云的 SDN 網(wǎng)絡在 Linux Kernel 上有深度優(yōu)化，相比直接在物理機上使用 Docker 的 Overlay 網(wǎng)絡性能還會好不少。
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構(gòu)成任何投資及應用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關內(nèi)容。本站擁有對此聲明的最終解釋權(quán)。
