为什么选择容器技术，又为什么选择了kubernetes？

做了一年多的‘基于K8S的PaaS云管理平台’，最近决定沉下心来，打算写以平台开发者的角度，从调研、设计、开发、测试、上线等一系列阶段经历的一些关键事件这个角度，记录下这个阶段我对于kubernetes云管平台的一些理解。

第一篇：为什么选择容器技术，又为什么选择了kubernetes?

1.为什么选择docker

1.1 Docker 容器的启动可以在秒级实现，比传统的虚拟机方式要快得多。

1.2 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。

1.3 更快速的交付和部署：一次创建或配置，可以在任意地方正常运行。

开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码。

1.4 更轻松的迁移和扩展

Docker 容器几乎可以在任意的平台上运行，包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。 这种兼容性可以让用户把一个应用程序从一个平台直接迁移到另外一个。

1.5 更简单的管理

使用 Docker，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分发和更新，从而实现自动化并且高效的管理。

2.为什么选择kubernetes

容器本身并不具备调度编排功能，对于大型应用，很可能需要不止一个应用实例，而是需要集群部署，这个时候，就需要用到容器集群管理技术了。

当前主流的容器集群管理技术，包括了 Docker 官方的 Docker Swarm、Twitter 背书的 Mesos 和 Google 背书的 Kubernetes。由于Apache Mesos 只是一个分布式内核，目前的发展方向是数据中心操作系统（DCOS），它同时支持 Marathon、Kubernetes 和 Swarm 等多种框架，连 Mesosphere 也是 Kubernetes 生态的一员，从编排的角度，讨论 Mesos 意义不大，故而只对比 Docker Swarm 和 Kubernetes。

上一张对比图（来自网易）

可以看到，起码就目前而言，Swarm在各个方面都明显弱于K8S。

首先，K8S社区活跃度要明显高于Swarm，甚至不在一个量级，社区活跃并不是说当遇到问题是仰仗社区解决问题，而是说明有更多厂商企业使用，有更多的最佳实践经验可以借鉴。

其次，核心功能上Swarm也还缺少很多，虽然swarm肯定会后续不断完善，但那显然需要时间的检验。

而swarm唯一的优势或许是集成在了Docker中，自然有利于开发者获得集群的能力，却也颠覆了系统级程序专注、松耦合的理念，新架构在生产环境中的稳定可靠，可能还需要更多的说服力。

而且google等厂商在之后推出了RunC标准，在CaaS中对容器进行抽象，用谁的容器都可以。

**容器运行时不再用Docker，而直接采用RunC，容器扩展功能通过插件来实现，基本就是全抛弃Docker了。**

目前RunC是三大容器厂商共同支持的标准：CoreOS Rocket, Cloud Foundry Garden和Docker容器。

所以在2016底容器白嫩派根据之争后，Kubernetes成了明显的获胜者

总结

以上都是确定好要上云之后的技术选型问题。

对企业来说，使用什么技术不重要，技术说到底都是工具，而它真正的价值在于帮助企业削减成本、提高效率、降低风险等，这大概是‘为什么选择XXX？’的根本答案吧。