Docker与k8s的恩怨情仇—Kubernetes的创新

我们提到了社区生态的发展使得Kubernetes得到了良性的发展和传播。比起相对封闭的Docker社区开放的CNCF社区获得了更大成功，但仅仅是社区的活力对比还不足以让Docker这么快的败下阵来，其根本原因是Kubernetes的对容器编排技术的理解比起Docker更胜一筹。这种优势几乎是压到性的降维打击，Docker毫无还手之力。

接下来便为大家介绍在这场容器大战之中，Kubernetes如何占据优势地位。

容器编排

所谓容器编排，其实就是处理容器和容器之间的关系，在一个分布式的大型系统里，不可能是以多个单一个体存在的，它们可能是一个与多个，一群与一群这样相互交织着。

Docker的容器编排功能

Docker构建的是以Docker容器为最核心的PaaS生态，包括以Docker Compose为主的简单容器关系编排，以及以Docker Swarm为主的线上运维平台。用户可以通过Docker Compose处理自己集群中容器之间的关系，并且通过Docker Swarm管理运维自己的集群，可以看到这一切其实就是当初Cloud Foundry的PaaS功能，所主打的就是和Docker容器的无缝集成。

Docker Compose做到的是为多个有交互关系建立一种“连接”，把它们全部编写在一个docker-compose.yaml文件中，然后统一发布(我后面说到的组里的ELK功能就是这样做的)，这样做也有优点，就是对于简单的几个容器之间的交互来说非常便利。但是对于大型的集群来说却有些杯水车薪，并且这种每出现一种新需求就需要单独做一项新功能的开发模式，将使后期代码维护变得十分困难。

Kubernetes如果要和Docker对抗，肯定不能仅仅只做Docker容器管理这种Docker本身就已经支持的功能了，这样的话别说分庭抗礼，可能连Docker的基本用户都吸引不到。因此在Kubernetes设计之初，就确定了不以Docker为核心依赖的设计理念。在Kubernetes中，Docker仅是容器运行时实现的一个可选项，用户可以依据自己的喜好任意调换自己需要的容器内容且Kubernetes为这些容器都提供了接口。此外，Kubernetes准确的抓住了Docker容器的一个致命性的弱点进行了自身创新。

接下来就让我们一起来了解，这个给Docker造成降维打击的内容究竟是什么？

Kubernetes的容器编排功能

<