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