Docker集群工具比较：Kubernetes与Docker Swarm

最新推荐文章于 2024-03-26 08:30:00 发布

danpob13624

最新推荐文章于 2024-03-26 08:30:00 发布

阅读量432

点赞数

文章标签： docker 大数据编程语言 python linux

Kubernetes和Docker Swarm可能是在集群内部署容器的两个最常用的工具。两者都是作为辅助工具创建的，可用于管理容器集群并将所有服务器视为一个单元。但是，它们的方法差异很大。

Kubernetes

Kubernetes基于Google多年使用Linux容器的经验。从某种意义上讲，它是Google长期以来的工作的翻版，但这次是适应Docker的。这种方法在很多方面都很棒，最重要的是他们从一开始就利用自己的经验。如果您在Docker 1.0（或更早版本）附近开始使用Kubernetes，那么Kubernetes的使用经验将是很棒的。它解决了Docker本身存在的许多问题。我们可以安装持久卷，这些持久卷将使我们能够在不丢失数据的情况下移动容器，使用法兰绒在容器之间创建网络，集成了负载平衡器，使用etcd进行服务发现，等等。但是，Kubernetes是有代价的。它使用不同的CLI，不同的API和不同的YAML定义。换句话说，您不能使用Docker CLI，也不能使用Docker Compose定义容器。一切都需要专门针对Kubernetes从头开始。好像该工具不是为Docker编写的（部分正确）。 Kubernetes将集群提升到了一个新的水平，但是却以可用性和陡峭的学习曲线为代价。

码头工人

Docker Swarm采用了不同的方法。它是Docker的本地集群。最好的部分是，它公开了标准的Docker API，这意味着您用来与Docker通信的任何工具（Docker CLI，Docker Compose，Dokku，Krane等）都可以与Docker Swarm很好地兼容。这本身同时是一个优点和缺点。能够使用自己选择的熟悉工具非常棒，但是出于同样的原因，我们也受到Docker API局限性的束缚。如果该API不支持某些功能，则无法通过Swarm API解决它，并且需要执行一些巧妙的技巧。

我们将基于它们的设置和为群集中运行容器提供的功能来更详细地探索这两个工具。

配置

设置Docker Swarm非常简单，直接且灵活。我们要做的就是安装服务发现工具之一，并在所有节点上运行swarm容器。由于发行版本身打包为Docker容器，因此无论操作系统如何，发行版都以相同的方式工作。我们运行swarm容器，公开一个端口，并将服务发现的地址告知它。很难做到这一点。我们甚至可以在没有任何服务发现工具的情况下开始使用它，看看我们是否喜欢它，以及当我们对它的使用变得更严肃时，添加etcd ， Consul或其他一些受支持的工具。

Kubernetes的安装更加复杂和混乱。安装说明因操作系统而异，提供程序也有所不同。每个OS或主机提供商都带有自己的一组指令，每个指令都有一个单独的维护团队，每个团队都有各自的问题。例如，如果您选择使用Vagrant进行尝试，那么Fedora会让您感到困惑。这并不意味着您不能使用Vagrant（例如Ubuntu或CoreOS）运行它。可以，但是您需要在Kubernetes官方入门页面之外开始搜索说明。无论您有什么需求，社区都有可能提供解决方案，但是您仍然需要花费一些时间来寻找解决方案，并希望该解决方案从第一次尝试开始就可以使用。更大的问题是安装依赖于bash脚本。如果我们不生活在必须进行配置管理的时代，那么这本身并不是什么大问题。我们可能不想运行脚本，但是要让Kubernetes成为我们的Puppet ， Chef或Ansible定义的一部分。同样，这也可以克服。您可以找到用于运行Kubernetes的Ansible剧本，也可以编写自己的剧本。这些问题都不是大问题，但是与Swarm相比，它们有点痛苦。使用Docker，我们应该没有安装说明（除了一些docker run参数）。我们应该运行容器。 Swarm实现了这一承诺，而Kubernetes则没有。

尽管有些人可能并不关心使用哪种发现工具，但我喜欢Swarm背后的简单性和逻辑“包括但可拆卸的电池”。一切都可以直接使用，但我们仍然可以选择用一个组件替换另一个组件。与Swarm不同，Kubernetes是自以为是的工具。您需要忍受它为您做出的选择。如果要使用Kubernetes，则必须使用etcd。我并不是想说etcd不好（相反），但是例如，如果您喜欢使用Consul，则您的处境非常复杂，需要为Kubernetes使用一个，而其余的则需要使用另一个服务发现需求。我不喜欢Kubernetes的另一件事是，它需要在安装之前预先知道一些事情。您需要告诉它所有节点的地址，每个节点的作用，集群中有多少个奴才等等。使用Swarm，我们只需启动一个节点并告诉它加入网络。无需预先设置任何内容，因为有关群集的信息是通过八卦传播的。

设置可能不是这些工具之间最重要的区别。无论您选择哪种工具，迟早一切都会启动并运行，并且您会忘记在此过程中可能遇到的任何麻烦。您可能会说，我们不应仅选择一种工具，仅因为一种工具易于安装。很公平。让我们继续讨论在定义应使用这些工具运行的容器方面的差异。

运行容器

如何定义使用Swarm运行Docker容器所需的所有参数？你不！实际上，您所做的但与在Swarm之前定义它们的方式或方式没有任何不同。如果习惯于通过Docker CLI运行容器，则可以通过（几乎）相同的命令继续使用它。如果您更喜欢使用Docker Compose运行容器，则可以继续使用它在Swarm集群中运行它们。无论使用哪种方式运行容器，都有可能继续使用Swarm进行相同的操作，但是规模更大。

Kubernetes要求您学习其CLI和配置。您不能使用之前创建的docker-compose.yml定义。您必须创建Kubernetes等效项。您不能使用之前学习的Docker CLI命令。您将必须学习Kubernetes CLI，并有可能确保整个组织也都学习它。

无论选择哪种工具部署到集群，您都已经很熟悉Docker。您可能已经习惯使用Docker Compose作为定义将要运行的容器的参数的方法。如果您玩了几个小时以上，那么您将用它代替Docker CLI。您可以使用它来运行容器，拖尾它们的日志，缩放它们等等。另一方面，您可能是不熟悉Docker Compose的硬核Docker用户，而是更喜欢通过Docker CLI运行所有内容，或者您可能拥有自己的bash脚本来为您运行容器。无论您选择什么，它都应与Docker Swarm一起使用。

如果您采用Kubernetes，请准备对同一事物具有多个定义。您将需要Docker Compose在Kubernetes外部运行容器。开发人员将继续需要在其笔记本电脑上运行容器，您的暂存环境可能是或可能不是大型集群，依此类推。换句话说，一旦您采用Docker，就不可避免地要使用Docker Compose或Docker CLI。您必须以一种或另一种方式使用它们。一旦开始使用Kubernetes，您将发现所有Docker Compose定义（或您可能正在使用的其他任何定义）都需要转换为Kubernetes的描述方式，并且从那以后，您必须同时维护两者。使用Kubernetes时，一切都将被复制，从而导致更高的维护成本。而且不仅是重复的配置。您将在集群外部运行的命令将与集群内部的命令不同。您学习和喜爱的所有这些Docker命令都必须在集群内部获取其Kubernetes等效项。

Kubernetes背后的家伙们并没有通过强迫您“按自己的方式”做事，从而使您的生活更加悲惨。如此巨大差异的原因在于Swarm和Kubernetes使用不同的方法来解决相同的问题。 Swarm团队决定将其API与Docker的API相匹配。结果，我们（几乎）完全兼容。 Docker几乎可以做的所有事情，以及Swarm都可以做的，而且规模更大。没有什么新要做的，没有要重复的配置，也没有新的知识要学习。无论您直接使用Docker CLI还是通过Swarm，API都（或多或少）相同。这个故事的消极面是，如果您想让Swarm来做某件事，并且不属于Docker API的一部分，那么您会感到失望。让我们简化一下。如果您正在寻找用于在将使用Docker API的集群中部署容器的工具，那么Swarm是解决方案。另一方面，如果您想要一个可以克服Docker局限性的工具，则应该使用Kubernetes。它是力量（Kubernetes），而不是简单性（Swarm）。或者，至少直到最近才是如此。但是，我超越了自己。

唯一未解决的问题是这些限制是什么。主要的两个是网络和持久卷。在Docker Swarm版本1.0之前，我们无法链接在不同服务器上运行的容器。实际上，我们仍然无法链接它们，但是现在我们有了多主机网络，可以帮助我们连接运行在不同服务器上的容器。这是一个非常强大的功能。 Kubernetes使用法兰绒来完成联网，现在，从Docker 1.9版开始，该功能可作为Docker CLI的一部分使用。

另一个问题是持久卷。 Docker在1.9版本中引入了它们。直到最近，如果您保留一个卷，则该容器将与该卷所在的服务器绑定在一起。再次使用一些讨厌的技巧，例如将卷目录从一台服务器复制到另一台服务器，就无法移动它。这本身就是一个缓慢的操作，违背了Swarm之类的工具的目标。此外，即使您有时间将卷从一个服务器复制到另一台服务器，您也不知道要复制到哪里，因为集群工具倾向于将整个数据中心视为一个实体。容器将被部署到最适合它们的位置（运行的容器数量最少，可用的CPU或内存最多，等等）。现在我们有了Docker本身支持的持久卷。

网络和持久卷问题都是Kubernetes在相当长的一段时间内支持的功能之一，也是许多人选择使用Swarm的原因。这种优势在Docker 1.9版本中消失了。

选择

尝试在Docker Swarm和Kubernetes之间做出选择时，请考虑以下术语。您是否要依靠Docker本身来解决与集群有关的问题。如果这样做，请选择“群集”。如果Docker不支持某些东西，那么Swarm不太可能会支持它，因为它依赖于Docker API。另一方面，如果您想要一种可解决Docker限制的工具，那么Kubernetes可能是您的最佳选择。 Kubernetes不是基于Docker构建的，而是基于Google在容器方面的经验。它自以为是，并试图以自己的方式做事。

真正的问题是，Kubernetes的做事方式（与我们使用Docker的方式有很大不同）是否被它提供的优势所掩盖。或者，我们应该押注于Docker本身，希望它能够解决这些问题？在回答这些问题之前，请查看1.9版。我们获得了持久的数量和软件网络。我们还获得了除非停止的重启策略， 否则该策略将管理我们不想要的故障。现在，Kubernetes和Swarm之间的区别少了三件事。实际上，如今，Kubernetes与Swarm相比，优势很少。另一方面，Swarm使用Docker API，这意味着您可以保留所有命令和Docker Compose配置。就个人而言，我将赌注押在Docker引擎上进行改进，并在其之上运行Docker Swarm。两者之间的差异很小。两者都已准备就绪，但是Swarm易于设置，易于使用，并且我们可以保留构建的所有内容，然后再转移到集群中。集群和非集群配置之间没有重复。

我的建议是选择Docker Swarm。 Kubernetes过于固执己见，难以设置，与Docker CLI / API差异太大，同时，自Docker 1.9版本以来，它与Swarm相比并没有真正的优势。这并不意味着Swarm不支持Kubernetes中没有可用的功能。双向都有功能差异。但是，我认为这些差异不是主要差异，并且每个Docker版本之间的差距都在缩小。实际上，对于许多用例而言，根本没有差距，而Docker Swarm更易于设置，学习和使用。