【翻譯】Docker網絡管理的將來

【編者的話】做者是一個極客，從Docker的0.7版本開始就關注了Docker的網絡問題，本文雖然帶有些感情色彩，但也不難看到做者對Docker的癡迷程度，不難看出他那顆想讓Docker更好的心。文章分析了Docker的網絡歷史，對相關的解決方案發表了本身的見解，做者期待Docker官方能作出最正確的決定。

      最近有不少關於Docker網絡管理的討論，對這個問題你們衆說紛壇。引發爭論的主要緣由是近年來使用Docker的人愈來愈多，用戶逐漸意識到Docker的網絡缺陷亟待解決。固然，實際狀況也是這樣，目前Docker的網絡能力嚴重不足，不支持複雜的設置，如今Docker的網絡模型存在性能問題且不易擴展。不過對於一個基本的應用而言Docker的網絡模型已經很不錯了。然而，咱們不能永遠停留在使用「基本應用」的級別上，伴隨着雲計算和微服務的普及，這些還遠遠不夠。做爲libcontainer的貢獻者之一，我想經過本文，發表一些本身的觀點。

       首先我須要先聊聊一些和網絡相關背景知識。一開始的時候，Docker使用者和開發者就意識到Docker網絡模型的不足，由於他們須要給Docker容器分配更多的IP地址，而使用LXC做爲容器引擎卻不會爲這個問題而感到苦惱。容器已經存在了至關長一段時間，只是因爲Docker的出現好多人才去學習Linux的命名空間（namespace），包括網絡的命名空間，它是Linux容器網絡的基石。Docker Tinkerer Extraordinaire 寫了不少的博客並開發了pipework工具，它能夠幫助瞭解Docker的網絡以及如何在Docker中構建複雜網絡。雖然pipework很強大，但它也僅僅只是一個第三方的工具罷了，咱們但願Docker原生的支持。
     
      我從Docker 0.7版本開始就關注它的網絡問題了，但我並非直接一頭扎進源碼裏研究。相反，我首先嚐試研究LXC網絡，我但願它能夠幫助我找到問題的關鍵點並運用到Docker上。我聯繫了Jerome而且對在將來在Docker中嵌入golang-pipwork hack達成了共識。接下來就是個漫長的故事。時間過去七個月了，咱們並無在**Docker-network-land**這個項目上投入太多的精力，在GitHub上也鮮有人討論網絡相關的問題。當我打開那些須要解決的問題的連接的時候，我以爲是時候須要改變了。Docker們關心的是那些優先級比較高的問題由於咱們已經有了pipework以及pipework衍生的工具。與此同時，愈來愈多的實用性工具使得咱們能突破Docker的網絡侷限。人們再也不關心Docker的網絡問題，而只是經過一小部分人修復那些已經存在的問題並添加一些新功能。

      轉眼過了幾個月的時間，咱們最終決定開始改變現狀。咱們向官方提出了網絡方面的[建議]()並創建了一個關於libnetwork的聊天室，儘管這些距離咱們某些不成熟的想法有些遙遠。如今參與討論的人愈來愈多。在個人觀點看來，這對Docker來講是相當重要的。值得欣慰的是社區裏不少人也開始意識到這個問題。

      Docker的網絡問題是極其複雜的，包括表面的和深層次的。它會涉及到很是多的項目，小到本地開發環境，大到相似牛逼的Kubernetes項目。當你閱讀了Kubernates關於網絡方面的[設計文檔後，你會發現一些好點子。在過去的一年時間裏，咱們開發了不少工具和類庫去解決網路問題。我真的但願正在進行的討論不會影響（fuck）到咱們現有的工做，而是可以爲新人創造更好的環境。我之因此使用Fuck這個詞是由於我曾見識過一個壞決定是如何讓全部人失望的，這也是我對Docker的一點擔憂。也許這些都只是人生經歷罷了，正如俗語有云：歷史交不給咱們什麼，因此我只是替古人擔心罷了。
  
        對於我來講Docker不只僅意味着軟件交付，不只僅意味着DevOps。它是另外一種開發工具。對我而言，Docker應該是一個工具，並且也許更重要的是一個平臺。嗯，是開放平臺，而且不是咱們常常討論的那種軟件平臺。若是Docker準備讓用戶或者公司在現有的平臺上構建其解決方案，那它就不該該依賴其它項目。我但願官方不會這樣作，由於Docker的夥計們已經知道擺脫依賴LXC並使用本身的libcontainer項目來替代。相似的處理思路應該用到網絡問題的上。
      
      目前看到有一些計劃是打算將OVS項目關聯到Docker上來，從Linux Kernel  3.3開始，OVS項目就是內核的一部分。當我聽到這個的時候我以爲是否是腦殼讓驢踢了。首先聲明我並非反對使用OVS，實際上，它是一個很是不錯的網絡工具套件。它的設置比較複雜，對於新手來講有一個陡峭的學習曲線，可是一旦學會，OVS就能夠幫你事半功倍。關於這個話題我聽到的一個討論是：「**若是OVS工做在Docker上，那麼工做一切都變得很美好**」。讓我告訴你，親們：若是讓我花費大量時間學習它，最後的結果只能是：「還好，能夠用」。我並不想說的那麼憤世嫉俗，實際狀況是在某些經常使用環境下OVS會崩潰。所以，使用OVS只是一種瘋狂的想法罷了。我並不想你們都認同個人說法。是的，你能夠什麼都不作，也能夠把他當作平常基礎工做。你可讓系統管理員和網絡工程師很開心，可是不全是這樣，同時也會讓開發者很孤獨。這是一個複雜的話題，固然解決問題並不是只有一種方法(沒有銀彈)，因此咱們不奢望真的有銀彈罷了。

      這個帖子並非討論是否將OVS成爲Docker的一部分。我選擇談到OVS是由於，這多是解決Docker網絡問題的方案之一。咱們討論的範圍有且不限於Docker的第三方項目，不管它是否開源。截止到目前，Docker們已經作了一些工做去避免這種問題的出現。很重要的一點是咱們以前談到的問題：避免對某個項目的依賴。一旦你決定使用某個項目，你的注意力就不得不集中在避免損害已經做爲有機總體的平臺構建項目的相互依賴的問題上。正如咱們如今討論的項目例如 flannel、weave、docket等，還有更多的新增的項目平臺帶來的衆多依賴項目上。

      目前有一個基於可插拔的網絡後端設置看起來是個不錯的建議。可是這還須要一點時間，直到有基於硬件的可插拔的架構設計而不只僅是解決網絡問題，還更多的Docker參與和時間的檢驗。這個改變發生在Docker的核心，目前正在從移動終端轉移到網絡部分。我認爲，給Docker們創建一個健壯的默認的後臺，而不是給用戶一些列的解決方案，強迫他們使用固定的路徑，是一個比較穩妥的作法。不可避免的咱們會對其餘項目引用和依賴，這將不會影響目前的Docker用戶，而且不會給將來的Docker用戶帶來影響。咱們都明白不可能讓每一個人都滿意，可是你能夠建立一個友好的環境，用來創建本身的解決方案，這樣使得不一樣用戶能夠共同工做而不會相互影響。若是你和我同樣加入可插拔的API項目，那麼咱們就是在同一條船上的人了。

      提及Docker網絡的將來，我真的很興奮，我很是期待Docker能作出最正確的決定。最重要的是，我但願本文能激發更多的人能參與其中一同完善這個項目。

原文地址：http://containerops.org/2014/11/11/future-of-Docker-networking/