容器網路:概述

Blog:部落格園 個人

參考:《每天5分鐘玩轉Docker容器技術》

容器網路可以分為單個host上的容器網路和跨多個host的網路。

單主機網路

docker安裝時會自動在host上創建三個網路,如:

[root@test ~]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
d9cf9b2bd659        bridge              bridge              local
44689f1ca656        host                host                local
2d6cf648cb7e        none                null                local

bridgehostnone三個網路。

none網路

顧名思義,none網路就是什麼都沒有的網路。掛在這個網路下的容器除了lo,沒有其他任何網卡。容器創建時,可以通過--network none指定使用none網路。

主要應用場景:一些對安全性要求高且不需要聯網的應用,如生產隨機密碼,放到none網路中避免密碼被竊取。

host網路

連接到host網路的容器共享Docker host的網路棧,容器的網路配置與host完全一樣。可以通過--network host指定使用host網路。

主要應用場景:對網路傳輸效率有較高要求的應用。

使用host網路,會犧牲一些靈活性,比如要考慮埠衝突問題。

bridge網路

docker安裝時會創建一個名為docker0的Linux bridge,如果不指定--network,創建的容器默認都會掛到docker0上。

user-defined網路

除了以上三個自動創建的網路,用戶也可以根據業務需要創建user-defined網路。

容器間通訊

容器之間可通過IPDocker DNS Serverjoined容器三種方式通訊。

容器與外界連接

容器默認可以訪問容器網路以外的網路環境。而外界訪問容器則需要通過埠映射。

跨主機容器通訊

image

跨主機網路方案包括:

  • docker原生的overlaymacvlan
  • 第三種方案:flannelweavecalico等;

libnetwork & CNM

libnetwork是docker容器網路庫,最核心的內容是其定義的Container Network Model(CNM),這個模型對容器網路進行了抽象,由以下三類組件組成:

  • Sandbox:容器的網路棧,包含容器的interface、路由表和DNS設置。
  • Endpoint:將Sandbox接入Network。一個Endpoint只能屬於一個網路,也只能屬於一個Sandbox。
  • Network:Network包含一組Endpoint,同一Network的Endpoint可以直接通訊。

overlay

Docker overlay網路需要一個key-value資料庫用於保存網路狀態資訊,包括Network、Endpoint、IP等。

Overlay網路相對要複雜一些,支援底層更靈活的轉發。目前包括Flannel、OpenV-Switch、Weave、Calico等一系列方案都能實現用Overlay網路來聯通不同節點上的Pod。

macvlan

Macvlan是Linux kernel比較新的特性,允許在主機的一個網路介面上配置多個虛擬的網路介面,這些網路interface有自己獨立的MAC地址,也可以配置上IP地址進行通訊。Macvlan下的虛擬機或者容器網路和主機在同一個網段中,共享同一個廣播域。Macvlan和Bridge比較相似,但因為它省去了Bridge的存在,所以配置和調試起來比較簡單,而且效率也相對高。除此之外,Macvlan自身也完美支援VLAN。

在 Docker 中,macvlan 是眾多 Docker 網路模型中的一種,並且是一種跨主機的網路模型,作為一種驅動(driver)啟用(-d 參數指定),Docker macvlan 只支援 bridge 模式。

flannel

github://github.com/coreos/flannel

Flannel由CoreOS公司推出,現在主要面向Kubernetes,為其提供底層的網路虛擬化方案。

Flannel採用了典型的覆蓋網路的思路,在每個主機上添加一個隧道端點,所有跨主機的流量會經過隧道端點進行隧道封包(典型為VXLAN協議,Docker Swarm也支援),直接發送到對端。

image-20200711214736135

與傳統的基於覆蓋網路的網路虛擬化方案類似,這種設計的優勢在於有很好的擴展性,只要IP連通的主機即可構成同一個虛擬網路,甚至可以跨數據中心。問題也很明顯,一個是隧道協議目前還比較難追蹤,另一個是解包和封包處理負載重,如果沒有硬體進行處理則往往性能會有損耗。另外,當中間路徑存在負載均衡設備時,要避免均衡失效

weave

github://git-hub.com/weaveworks/weave

Weave Net是由Weave公司開發的面向容器的網路虛擬化方案。解決容器網路跨主機問題的思路主要是打通跨主機容器之間的通訊,手段無非是用覆蓋網路建立隧道,或者通過更改包頭進行轉發。

Weave Net的設計比較有意思,在每個主機上添加一個路由器,在混雜模式下使用pcap在網橋上截獲網路數據包。如果該數據包是要發送到其他主機上的,則通過UDP進行轉發,到目的主機所在的路由器上。目的路由器執行相反的過程利用pcap解析網包再發送給網橋。整個過程模擬了一種隧道方式。

image-20200711214954784

這樣設計的好處是可以進行細粒度的管理,整個轉發過程很容易追蹤;潛在的問題是對管理平面(特別是路由器的自動收斂和學習)要求比較複雜,並且執行pcap過程會比較消耗計算資源。實際部署中要考慮結合軟體定義網路和硬體處理等手段來緩解這兩個問題。

calico

項目官方網站://www.projectcalico.org/

Calico的設計則更為直接,乾脆不支援網路虛擬化,直接採用傳統的路由轉發機制,也是在每個節點上配置一個vRouter,負責處理跨主機的流量。vRouter之間通過BGP自動學習轉發策略。

image-20200711215304999

由於Calico不採用隧道格式,而是依賴於傳統的IP轉發,這就限制了它的應用場景,無法跨數據中心,無法保障中間路徑安全。但反之帶來了容易管理、轉發性能會好的一些優勢。

Calico目前支援VM、Docker、Kubernetes、Openstack等多個項目的容器網路功能。Calico項目目前正在與Flannel項目共同發起Canal項目,整合了兩者的優勢,項目地址在//github.com/projectcalico/canal。