如何看待Docker網(wǎng)絡(luò)管理的未來

今天就跟大家聊聊有關(guān)如何看待Docker網(wǎng)絡(luò)管理的未來，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

      最近有很多關(guān)于Docker網(wǎng)絡(luò)管理的討論，對這個問題大家眾說紛壇。引起爭論的主要原因是近年來使用Docker的人越來越多，用戶逐漸意識到Docker的網(wǎng)絡(luò)缺陷亟待解決。當(dāng)然，實際情況也是這樣，目前Docker的網(wǎng)絡(luò)能力嚴(yán)重不足，不支持復(fù)雜的設(shè)置，現(xiàn)在Docker的網(wǎng)絡(luò)模型存在性能問題且不易擴(kuò)展。不過對于一個基本的應(yīng)用而言Docker的網(wǎng)絡(luò)模型已經(jīng)很不錯了。然而，我們不能永遠(yuǎn)停留在使用“基本應(yīng)用”的級別上，伴隨著云計算和微服務(wù)的普及，這些還遠(yuǎn)遠(yuǎn)不夠。作為libcontainer的貢獻(xiàn)者之一，我想通過本文，發(fā)表一些自己的觀點。


       首先我需要先聊聊一些和網(wǎng)絡(luò)相關(guān)背景知識。一開始的時候，Docker使用者和開發(fā)者就意識到Docker網(wǎng)絡(luò)模型的不足，因為他們需要給Docker容器分配更多的IP地址，而使用LXC作為容器引擎卻不會為這個問題而感到苦惱。容器已經(jīng)存在了相當(dāng)長一段時間，只是由于Docker的出現(xiàn)好多人才去學(xué)習(xí)Linux的命名空間（namespace），包括網(wǎng)絡(luò)的命名空間，它是Linux容器網(wǎng)絡(luò)的基石。Docker Tinkerer Extraordinaire 寫了很多的博客并開發(fā)了pipework工具，它可以幫助了解Docker的網(wǎng)絡(luò)以及如何在Docker中構(gòu)建復(fù)雜網(wǎng)絡(luò)。雖然pipework很強(qiáng)大，但它也僅僅只是一個第三方的工具罷了，我們希望Docker原生的支持。
     
      我從Docker 0.7版本開始就關(guān)注它的網(wǎng)絡(luò)問題了，但我并不是直接一頭扎進(jìn)源碼里研究。相反，我首先嘗試研究LXC網(wǎng)絡(luò)，我希望它可以幫助我找到問題的關(guān)鍵點并運用到Docker上。我聯(lián)系了Jerome并且對在未來在Docker中嵌入golang-pipwork hack達(dá)成了共識。接下來就是個漫長的故事。時間過去七個月了，我們并沒有在**Docker-network-land**這個項目上投入太多的精力，在GitHub上也鮮有人討論網(wǎng)絡(luò)相關(guān)的問題。當(dāng)我打開那些需要解決的問題的鏈接的時候，我覺得是時候需要改變了。Docker們關(guān)心的是那些優(yōu)先級比較高的問題因為我們已經(jīng)有了pipework以及pipework衍生的工具。與此同時，越來越多的實用性工具使得我們能突破Docker的網(wǎng)絡(luò)局限。人們不再關(guān)心Docker的網(wǎng)絡(luò)問題，而只是通過一小部分人修復(fù)那些已經(jīng)存在的問題并添加一些新功能。


      轉(zhuǎn)眼過了幾個月的時間，我們最終決定開始改變現(xiàn)狀。我們向官方提出了網(wǎng)絡(luò)方面的[建議]()并建立了一個關(guān)于libnetwork的聊天室，盡管這些距離我們某些不成熟的想法有些遙遠(yuǎn)?，F(xiàn)在參與討論的人越來越多。在我的觀點看來，這對Docker來說是至關(guān)重要的。值得欣慰的是社區(qū)里很多人也開始意識到這個問題。


      Docker的網(wǎng)絡(luò)問題是極其復(fù)雜的，包括表面的和深層次的。它會涉及到非常多的項目，小到本地開發(fā)環(huán)境，大到類似牛逼的Kubernetes項目。當(dāng)你閱讀了Kubernates關(guān)于網(wǎng)絡(luò)方面的[設(shè)計文檔后，你會發(fā)現(xiàn)一些好點子。在過去的一年時間里，我們開發(fā)了很多工具和類庫去解決網(wǎng)路問題。我真的希望正在進(jìn)行的討論不會影響（fuck）到我們現(xiàn)有的工作，而是能夠為新人創(chuàng)造更好的環(huán)境。我之所以使用Fuck這個詞是因為我曾見識過一個壞決定是如何讓所有人失望的，這也是我對Docker的一點擔(dān)心。也許這些都只是人生經(jīng)歷罷了，正如俗語有云：歷史交不給我們什么，所以我只是替古人擔(dān)憂罷了。
  
        對于我來說Docker不僅僅意味著軟件交付，不僅僅意味著DevOps。它是另一種開發(fā)工具。對我而言，Docker應(yīng)該是一個工具，而且也許更重要的是一個平臺。嗯，是開放平臺，并且不是我們經(jīng)常討論的那種軟件平臺。如果Docker準(zhǔn)備讓用戶或者公司在現(xiàn)有的平臺上構(gòu)建其解決方案，那它就不應(yīng)該依賴其它項目。我希望官方不會這樣做，因為Docker的伙計們已經(jīng)知道擺脫依賴LXC并使用自己的libcontainer項目來替代。類似的處理思路應(yīng)該用到網(wǎng)絡(luò)問題的上。
      
      目前看到有一些計劃是打算將OVS項目關(guān)聯(lián)到Docker上來，從Linux Kernel  3.3開始，OVS項目就是內(nèi)核的一部分。當(dāng)我聽到這個的時候我覺得是不是腦袋讓驢踢了。首先聲明我并不是反對使用OVS，實際上，它是一個非常不錯的網(wǎng)絡(luò)工具套件。它的設(shè)置比較復(fù)雜，對于新手來說有一個陡峭的學(xué)習(xí)曲線，但是一旦學(xué)會，OVS就可以幫你事半功倍。關(guān)于這個話題我聽到的一個討論是：“**如果OVS工作在Docker上，那么工作一切都變得很美好**”。讓我告訴你，親們：如果讓我花費大量時間學(xué)習(xí)它，最后的結(jié)果只能是：“還好，可以用”。我并不想說的那么憤世嫉俗，實際情況是在某些常用環(huán)境下OVS會崩潰。因此，使用OVS只是一種瘋狂的想法罷了。我并不想大家都認(rèn)同我的說法。是的，你可以什么都不做，也可以把他當(dāng)做日?；A(chǔ)工作。你可以讓系統(tǒng)管理員和網(wǎng)絡(luò)工程師很開心，但是不全是這樣，同時也會讓開發(fā)者很孤獨。這是一個復(fù)雜的話題，當(dāng)然解決問題并非只有一種方法(沒有銀彈)，所以我們不奢望真的有銀彈罷了。

      這個帖子并不是討論是否將OVS成為Docker的一部分。我選擇談到OVS是因為，這可能是解決Docker網(wǎng)絡(luò)問題的方案之一。我們討論的范圍有且不限于Docker的第三方項目，無論它是否開源。截止到目前，Docker們已經(jīng)做了一些工作去避免這種問題的出現(xiàn)。很重要的一點是我們之前談到的問題：避免對某個項目的依賴。一旦你決定使用某個項目，你的注意力就不得不集中在避免損害已經(jīng)作為有機(jī)整體的平臺構(gòu)建項目的相互依賴的問題上。正如我們現(xiàn)在討論的項目例如 flannel、weave、docket等，還有更多的新增的項目平臺帶來的眾多依賴項目上。

      目前有一個基于可插拔的網(wǎng)絡(luò)后端設(shè)置看起來是個不錯的建議。但是這還需要一點時間，直到有基于硬件的可插拔的架構(gòu)設(shè)計而不僅僅是解決網(wǎng)絡(luò)問題，還更多的Docker參與和時間的檢驗。這個改變發(fā)生在Docker的核心，目前正在從移動終端轉(zhuǎn)移到網(wǎng)絡(luò)部分。我認(rèn)為，給Docker們建立一個健壯的默認(rèn)的后臺，而不是給用戶一些列的解決方案，強(qiáng)迫他們使用固定的路徑，是一個比較穩(wěn)妥的做法。不可避免的我們會對其他項目引用和依賴，這將不會影響目前的Docker用戶，并且不會給未來的Docker用戶帶來影響。我們都明白不可能讓每個人都滿意，但是你可以創(chuàng)建一個友好的環(huán)境，用來建立自己的解決方案，這樣使得不同用戶可以共同工作而不會相互影響。如果你和我一樣加入可插拔的API項目，那么我們就是在同一條船上的人了。

      說起Docker網(wǎng)絡(luò)的未來，我真的很興奮，我非常期待Docker能做出最正確的決定。最重要的是，我希望本文能激發(fā)更多的人能參與其中一同完善這個項目。

看完上述內(nèi)容，你們對如何看待Docker網(wǎng)絡(luò)管理的未來有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。