我们提到了社区生态的发展使得Kubernetes得到了良性的发展和传播。比起相对封闭的Docker社区开放的CNCF社区获得了更大成功,但仅仅是社区的活力对比还不足以让Docker这么快的败下阵来,其根本原因是Kubernetes的对容器编排技术的理解比起Docker更胜一筹。这种优势几乎是压到性的降维打击,Docker毫无还手之力。
接下来便为大家介绍在这场容器大战之中,Kubernetes如何占据优势地位。
容器编排
所谓容器编排,其实就是处理容器和容器之间的关系,在一个分布式的大型系统里,不可能是以多个单一个体存在的,它们可能是一个与多个,一群与一群这样相互交织着。
![](https://i-blog.csdnimg.cn/blog_migrate/ea16b557f18d7e0e963f8fab12c70ed0.png)
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的容器编排功能
![](https://i-blog.csdnimg.cn/blog_migrate/e5e9470a456c1a986f0fde92b34682c2.png)