資訊專欄INFORMATION COLUMN
摘要：模式容器直接使用宿主機的網絡配置，包括網卡，路由等，這種方案下，從網絡層面來看，容器就不是容器了，只是一個宿主機上的進程端口而已。
注：本篇僅僅是對各個網絡方案的簡介和思考。需要深入學習如何部署和使用的同學請自行度娘~
中小docker用戶的苦惱docker的使用者十分廣泛，不止有網易蜂巢，daocloud，時速云這類的已經成熟化的公有云服務，許多中小型企業內部也在試圖將docker容器應用到內部的運維工作中。
在成熟的容器服務架構中，往往會依賴IaaS層去實現更好的隔離效果，一個很明顯的例子就是網絡的連通性和隔離性。許多企業使用neutron作為這方面的支持并且能獲得不錯的效果。
而中小型企業內部，甚至一些個人用戶的docker環境就很少考慮租戶隔離了，連通性和性能是這類用戶的至高需求。
比如下面這段對話：
“我們部門這套業務是基于dubbo的架構來開發的，現在其中的服務A要放你們容器環境里面跑。”
“可以啊，來來來，我幫你打鏡像，我幫你跑，要幾個實例？OK沒問題。”
“你們容器集群里的服務，我們的dubbo注冊中心都訪問不到啊！搞什么鬼？”
“不好意思不好意思，我們的容器IP是虛擬的IP，你沒法主動訪問我們的。不過我們用了k8s，可以把整個服務以一個IP：port的形式提供給注冊中心，你看我們還幫你們做了負載均衡。”
“我們不需要你們幫我們做負載均衡，我們就想把容器當虛擬機一樣用嘛~”
“這...”
實際上，對于每一個初步接觸docker的人來說，網絡是絕對的痛點，要搭建一套能讓容器跨機器的集群，是玩轉容器，建設CaaS的第一步。這里簡單介紹一下幾種使用較為普遍的容器網絡方案，并詳細講述筆者在“遠古時期”的網絡方案解決思路。
host模式容器直接使用宿主機的網絡配置，包括網卡，路由等，這種方案下，從網絡層面來看，容器就不是容器了，只是一個宿主機上的進程（端口）而已。
使用這種模式的性能損耗最少（直接用宿主機的網卡，能有什么損耗）。但是除非在容器中我們做好端口的自動化配置，否則端口被占用了，容器就啟動不了。
flannel已經日趨成熟，從原本的udp，vxlan支持，到后來的aws，host-gw，gce網絡。這里主要說udp，vxlan，host-gw。
udp和vxlan在flannel中其實只是封裝協議的不同而已。筆者了解不多，不敢多做解釋，不過這兩種方式的性能其實是差不多的（很多人會覺得vxlan性能更好）。flannel實現的是一個三層網絡。但是udp,vxlan協議是通過隧道方式進行跨機互聯，簡單地說就是：
容器a的數據包pkg->宿主機A的docker0->路由到宿主機A的flannel0網卡->被封裝->宿主機A的物理網卡->宿主機B的物理網卡->路由到宿主機B的flannel0網卡->被解封->通過暴露出來的目的容器IP找到docker0->docker0轉給容器的虛擬網卡
封裝解封的過程導致flannel會有20-30%的損耗。
host-gw是一個比較新鮮的方式，在slaver節點屬于同一個二層網絡，且可以自由配置slaver節點網絡的前提下，我們使用host-gw，會使得slaver節點上創建出一系列路由規則，通過這套路由規則，將容器發出的數據包轉發給相應的機器。這種模式性能會更好。
flannel的主要缺點在于，既沒有租戶隔離（即：一套環境里，每一個容器都可以訪問到其他任何容器），也沒有對外開放（集群外沒有搭建flannel的機器ping不通容器）。
calico是一種容器級路由和防火墻工具，它能夠在容器級別上為每個容器實例或k8s的Pod實例指定訪問規則，達到服務間可控的訪問。
Calico的原理是通過修改每個主機節點上的iptables和路由表規則，實現容器間數據路由和訪問控制，并通過Etcd協調節點配置信息的。因此Calico服務本身和許多分布式服務一樣，需要運行在集群的每一個節點上。
calico已經并入了k8s的CNI插件。在每一個slaver節點上啟動一個calico容器，去劫持docker的創建命令，接管容器網絡的配置。
calico吸引人的地方在于：他有一套自己的管理體系，給不同的子網絡增加了標簽，可以通過這種方式實現容器網絡的隔離；同時業內認為他的性能也是很好的，基本接近裸機的網絡性能，然而筆者在自己的環境中測試了幾次，效果并不盡如人意，。
接下來說下橋接+IPAM模式。這個方案針對的是一種比較特殊的使用場景：
docker有許多用法，微服務是其中一種，通過docker技術圈內愛好者的交流，我們了解到確實有一些企業試圖，或者已經將容器當做虛擬機在用。上文中的對話就是這個使用場景之一，這種場景下的網絡問題總結為：同一個網絡環境中的機器里，非docker機器主動連接docker機器上的容器是連不通的。
解決方法：
1.給這個網絡環境中非docker的機器也部署虛擬網絡，將flannel，calico這類組件在全網絡范圍內做分布式的部署。（考慮到機器數量，可能存在的VM，VM會有起停操作，這個方案基本不可行）
2.給容器一個和宿主機器同一層網絡的IP，即二層網絡IP，路由到宿主機的物理網卡，進行轉發。
我們知道docker1.9以后增加了network特性，docker daemon可以自己創建一個network，通過選擇network給容器配置網絡。
在二層網絡的基礎上，我們在宿主機建立一個網橋，橋接了物理網卡和docker network（當然了type必須是bridge）。設置好路由規則和gateway，docker容器創建時橋接到相應的network上，就可以正常地訪問二層網絡內的任何機器/容器。
同樣的，因為這種方式下容器創建后IP是一個二層網絡內的IP，所以外部機器可以很方便地訪問容器。這是一種全暴露的網絡模式。做到了完全的連通，但沒辦法做到網絡的隔離。
那IPAM又是什么鬼？
假設這種情況：橋接模式下，容器和宿主機是同一個網段，比如172.16.1.0/24,假設該網段中的.1~.10都是宿主機，我們在.1的宿主機上創建的容器，其IP必定是172.16.1.2,172.16.1.3，...會發現容器的IP和宿主機重復了。這就麻煩了，要么我們就連不上容器，要么我們就連不上IP為172.16.1.2的宿主機。（簡單地說下原因：每個宿主機彼此并不知悉對方的IP和MAC信息，我們創建的那個網橋也沒有這方面的記錄，容器啟動時，網橋上已經記錄了本機的IP：172.16.1.1，但沒有記錄172.16.1.2，所以就會給容器分配172.16.1.2這個IP）
那就開發一個服務用于管理IP吧,docker原生支持network plugin，其中一個插件就是IPAM,即ip分配管理服務。docker network創建/銷毀容器時會使用IPAM去申請/釋放一個合法的IP。如果沒有指定IPAM插件，docker daemon會自動配置的網段中選一個IP，其邏輯是按數字從小到大進行分配。
我們開發一個IPAM，通過IPAM來進行IP的申請和釋放，并在整個集群中建立一個IP的管理中心，維護整個容器集群的IP資源。保證一個IP只能同時被最多一個容器使用。
這種方案的性能看起來應該是和flannel host-gw，calico差不多的，因為其本質還是路由轉發，不同之處是給容器分配了二層網絡IP，所有容器都暴露了，因此這種模式下網絡就難以做租戶隔離（容器更像一個瘦VM了~），而這種情況下，dubbo的服務可以直接在容器上部署，k8s的service特性，kube-proxy組件基本可以酌情棄用。
總結綜上所述：
host 損耗小 靈活度低，IP資源不足 沒有隔離
flannel udp/vxlan 損耗較大 靈活，IP資源充足 有內外網隔離，沒有租戶隔離
flannel host-gw 損耗較小 靈活，ip資源充足 有內外網隔離，沒有租戶隔離
calico 損耗較小 靈活，ip資源充足 有內外網隔離，有租戶隔離
橋接+ipam 損耗很小 開發成本大，二層網絡IP資源有限 無任何隔離
展望：calico可能會是最適合容器云的網絡方案，因為租戶的網絡隔離是生產化過程中絕對不可缺少的。如果僅在內部小規模使用，追求簡單配置，可以使用flannel，如果將容器vm化，可以考慮使用橋接+ipam。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/32500.html
摘要：模式容器直接使用宿主機的網絡配置，包括網卡，路由等，這種方案下，從網絡層面來看，容器就不是容器了，只是一個宿主機上的進程端口而已。 注：本篇僅僅是對各個網絡方案的簡介和思考。需要深入學習如何部署和使用的同學請自行度娘~ 中小docker用戶的苦惱 docker的使用者十分廣泛，不止有網易蜂巢，daocloud，時速云這類的已經成熟化的公有云服務，許多中小型企業內部也在試圖將docker...
摘要：產品簡介概述開放式分發節點，在全國的上百個數據中心，為用戶提供開放式的邊緣計算存儲網絡資源。低成本產品大幅度降低了客戶基礎設施和硬件資源成本。容器資源產品目前處于內測階段，內測用戶目前支持在控制臺對容器資源的開啟關閉重啟重裝鏡像功能。產品簡介概述UODN（UCloud Open DeliveryNetwork）開放式分發節點，在全國的上百個數據中心，為用戶提供開放式的邊緣計算、存儲、網絡資源...
摘要：無論這個連接是外部主動建立的，還是內部建立的。協議有表示層數據的表示安全壓縮。在整個發展過程中的所有思想和著重點都以一種稱為的文檔格式存在。 部署基礎知識url：協議：//網站地址：端口（/）路徑地址?參數eg： http://www.baidu.com:80/abc/dd/ www.baidu.com找服務器 80端口：找服務器上提供服務的應用 nginx uri：/ab...
摘要：無論這個連接是外部主動建立的，還是內部建立的。協議有表示層數據的表示安全壓縮。在整個發展過程中的所有思想和著重點都以一種稱為的文檔格式存在。 部署基礎知識url：協議：//網站地址：端口（/）路徑地址?參數eg： http://www.baidu.com:80/abc/dd/ www.baidu.com找服務器 80端口：找服務器上提供服務的應用 nginx uri：/ab...
閱讀 1837·2021-09-23 11:21
閱讀 698·2019-08-30 15:55
閱讀 832·2019-08-29 15:40
閱讀 528·2019-08-29 12:56
閱讀 3158·2019-08-26 12:00
閱讀 3552·2019-08-23 18:24
閱讀 2246·2019-08-23 17:08
閱讀 1637·2019-08-23 17:03
