基于軟件容器網絡對NAT的依賴以及NAT自身的局限性，網絡工程師在其基礎設施內部署容器時面臨一些顯著的挑戰，但通過了解容器主機如何支持NAT模式可幫助我們避免這些問題。

首先，讓我們看看主機如何創建新的網絡命名空間(這在概念上類似于MPLS/VPN模型中的虛擬路由和轉發實例)以及被稱為虛擬以太網(vEth)的特殊網絡接口。vEth接口是用于連接命名空間的一對端點，主機將vEth的一端放在默認命名空間用于與外部世界通信，另一端放在新創建的命名空間。

默認命名空間中的vEth被綁定到橋接，例如Docker中的docker0以及LXC中的lxcbr0。主機使用Linux中的iptables來配置NAT以及輕量級動態主機配置協議(DHCP)服務器來分配地址，例如dnsmasq。

 [[148045]]

規避NAT

幸運的是，我們有技術可避免NAT。Cohesive Networks公司首席技術官Chris Swan在2014年Container Camp會議中談論Docker網絡時將其容器網絡哲學恰當地總結為讓容器成為“網絡的一等公民”。

我們可以直接連接容器到主機的網絡接口來實現這一點。容器與主機共享本地區域網絡(LAN)，它們從LAN的DHCP服務器獲取IPv4地址或者使用靜態機制。所有4層網絡端口完全暴露，雖然這種直接的暴露比管理映射端口更好，但維持強大的安全狀態需要紀律性。

直接連接到物理接口的一種方法是橋接vEth端點與面向互聯網的物理接口。不過，這種方法需要修改物理端口，即移除IP地址并將其分配到橋接接口。

系統管理員可使用混淆命名的“macvlan”網絡類型來連接到物理接口，而不需要使用vEth網絡類型。Macvlan類型與IEEE 802.1Q VLAN無關;它可被認為復用多個MAC地址到單個網絡接口的方法。Macvlan類型通常部署在橋接模式，實現更簡單的橋接，而非傳統的學習橋接—不需要學習，生成樹協議也沒必要。

消除NAT的第二種方法是將主機變成全面的路由器，甚至是使用邊界網關協議的路由器。主機會將前綴路由到主機中的容器，每個容器會使用全球唯一的IP地址。在即將耗盡的IPv 4地址空間時代，提供IPv4獨特地址顯然不太現實。而IPv6讓這種主機作為路由器的技術更加簡潔;該協議的稀疏尋址模式允許巨大的易于管理的地址空間。

由于3層網絡不會受到洪泛影響，它的使用消除了2層網絡廣播域中創建的大量故障域。你是否經歷過數據中心范圍的網絡危機?單個以太網廣播域幾乎肯定遭遇過生成樹故障或者其他洪泛相關的事件。

挑戰：MAC地址的擴散

然而，連接容器接口到外部網絡帶來新的挑戰：數據中心網絡中大量可見的MAC地址。頂級機架(ToR)交換機可支持的MAC地址數量各有不同，但可處理更多MAC地址的交換機(而不會洪泛所有幀)花費更多。當MAC地址超過限制時，主機中的物理網絡接口卡也可切換到混雜模式，這會降低性能。

在直接連接到主機物理接口的容器之間我們如何實現終端到終端的可達性，而不會讓ToR交換機中2層網絡轉發表受到影響?2014年年底Linux內核中推出的ipvlan功能也許是答案。Macvlan驅動程序是使用MAC地址作為解復用器，而ipvlan驅動程序則是使用3層網絡(IP)地址。當ipvlan驅動程序部署在L3模式時，容器MAC地址不會暴露在網絡。只有物理接口的主機MAC地址在網絡中可見。

Linux內核3.19中有ipvlan功能，但更穩定的功能出現在4.0-rc7及更高版本。在截至寫這篇文章的時候，你將需要編譯定制的內核來嘗試ipvlan，因為Linux版本使用更舊更穩定的內核。

挑戰：大規模vEth網絡類型

最后，雖然在大多數容器環境可能不太明顯，但為大規模部署使用vEth網絡類型可能損害容器網絡性能。谷歌公司Victor Marmol在其《容器和容器集群中的網絡》的談話中，他描述了其公司在使用vEth網絡類型時，性能比默認命名空間降低了50%。

Macvlan和ipvlan功能消除了vEth網絡類型所需要的一些處理工作，內核開發人員Eric W.Biederman將macvlan描述為“簡單、愚蠢和快速”，而在ipvlan驅動程序中性能得到保持，期望在未來看到macvlan和ipvlan驅動程序在性能方面的改進。