【翻译】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/