在最近于加拿大溫哥華召開的OpenStack峰會上，6000多名與會人士接受了使用容器情況方面的調查。被問及是否在生產環境中有容器時，臺下一小部分聽眾舉手示意――據我估計大概有5%。但是被問及誰在接下來幾年考慮將容器遷移到生產環境時，幾乎人人都舉手。

這一幕生動地表明，雖然容器是一項現處于早期階段的技術，但眾多企業組織為它制定了宏偉計劃。由于Docker和Kubernetes等多種選擇，用戶們在認真考慮自己的選擇道路。容器提供了幾個明顯的優勢：簡化和加快了應用程序的部署、可移植性以及占用少量的資源，但是也存在風險。

 [[137674]]

一大風險就是整合。開源社區正在考慮如何將容器整合到現有的云和自動化框架當中，比如Magnum和幾個OpenStack項目。另一個問題就是容器網絡。用戶們常常問我如何設計一套同時支持容器和虛擬機的網絡解決方案。虛擬機和容器(以及部署的裸機系統)通常帶來了全然不同的網絡模型。

不妨后退一步，考慮一下如今的容器網絡是如何工作的。容器網絡基于一種簡單的架構，主要是單主機解決方案。比如說，Docker網絡模型基于幾個簡單的假定：

•它充分利用與容器相連接的本地(每個主機里面的)Linux網橋。

•每個計算節點都有集群看得見的IP地址。

•每個容器都有集群看不見的專有的IP地址。

•網絡地址轉換(NAT)協議用來將容器的專有IP地址綁定至計算節點的公共IP地址。

•此外，負載均衡系統可用來將服務映射至一組IP地址和端口。

•iptable用于應用程序與租戶之間的網絡分段和隔離。

如果運用到容器網絡上，這種模型在許多方面顯得不盡如人意。它限制了用容器構建的多租戶云解決方案跨多個主機進行擴展的功能。高可用性方面的配置很有限。無論工作負載的移動性如何，一致的連接性和安全性也成問題。另外，iptable和NAT的結合使用限制了可擴展性和性能，這讓使用容器的主要優勢之一蕩然無存。

那么，面向容器的網絡解決方案應該提供什么呢?另外，你又該如何評估解決方案與特定應用程序的契合度?我們不妨把這分成三個問題;這些答案應該可以幫助你更深入地了解容器網絡方面的獨特之處。

1. 你會在基于容器的基礎設施上運行哪種類型的應用程序?

這直接影響到你網絡基礎設施的藍圖以及如何構建網絡基礎設施。你的應用程序需要豐富的網絡拓撲結構以及高級服務嗎?它們是多租戶模式，還是簡單的“扁平網絡”就足以勝任?

面向容器的虛擬網絡解決方案讓最終用戶(租戶)和云操作人員都可以定義并控制各自的網絡要求。解決方案還必須提供跨多個物理主機的微分段(micro-segmentation)和隔離所需要的構件。

2. 性能和可擴展性方面的要求是什么?

你在思考這個問題時，要考慮基礎設施上應用程序的要求。應當考慮這樣的解決方案：在一種完全分布式的架構中提供隔離和網絡功能，從而為你應用程序的發展和擴展鋪平道路。隨著部署的云越來越龐大，網絡解決方案應該跨多個物理主機向外擴展，還應該在云編排框架里面緊密地整合起來。

3. 你需要將容器與虛擬機和裸機工作負載互聯起來嗎?

大多數應用程序需要用容器支持混合工作負載，所以要尋求同時支持兩者的解決方案。一致的抽象模型(網絡、子網、路由器、接口和浮動IP地址)和一套用于配置和自動化的一致的API，是完成這項工作的方法。

云用戶呼吁面向任何工作負載的網絡模型與功能強大的網絡抽象結合起來，從而簡化容器到容器的聯系，并且增添先進的網絡功能和微分段。

你在網絡和容器方面有什么樣的挑戰和要求?歡迎留言交流!