容器技术发展趋势.docx

容器技术发展趋势1 前言 时至今日，没有人质疑容器技术的未来 现在，没有人会否认容器技术的作用与地位。2013 年 Docker 问世，热度迅速蹿升并被大范围使用，如此势头在开源界当属少见。DataDog 连续三年发布 Docker 问卷调查，2017 年报告显示 Docker 的采用率上升 40%。调查数据显示 2015 年起就有不少大型公司已经开始尝试使用 Docker，并且近 60% 的企业宣称使用 Docker 的机器规模超过 500 台，不过 100-499 台规模的使用比率也获得了显著上升。有分析认为 Docker 的出现在早期解决的是大公司痛点问题，而现在 Docker 正在寻求成为各类公司的通用平台技术。Sysdig 调查了 4.5 万个企业，统计显示平均每台机器上会运行 10 个容器实例，甚至有企业在一台机器上启用 95 个容器实例。当 Docker 逐渐生产环境中不可或缺的部分之后，势必要寻求工具更高效地管理和编排这些容器。目前市面上被广为熟知的编排方案是 Kubernetes、Mesos、Amazon ECS、Google Engine 等，而 Docker 也推出了自己的原生系统编排方案。2 Kubernetes ?vs Docker Swarm 两股流派 Kubernetes 出身于谷歌，是其多年大规模容器管理技术的开源版本，在容器浪潮中完成了短时间内的迅速发展，是目前容器生态中最受欢迎的开源项目。项目于 2014 年 6 月首次亮相 GitHub，即 Docker 项目开源的一年多之后；项目已经被捐赠给 CNCF（Cloud Native Computing Foundation）组织，其目标是成为“跨集群的应用级别容器部署、扩展和运维自动化平台”，它会支持包括 Docker 在内的一系列容器工具。而 Docker Swarm 则是 Docker 主推的原生的集群工具，意图让用户像使用单机 Docker API 一样来驱动整个集群。2016 年 7 月发布的 Docker1.12 把 Swarm 内置到 Docker 中，这种内置的做法引来了一些争议，有人认为这对 Kubernetes 和 Mesos 造成了一定的威胁。在很多人眼里，Kubernetes 更开源、汇聚了更多的力量，而 Docker Swarm 则是 Docker 处于商业化的本心。这里，先抛开 Kubernetes 和 Docker 的历史背景，也不提两者社区背后曾经有过的争论；我们单纯从技术设计的角度来看看两者技术层面的差异。1. 遵循的两种网络标准 在不同的用户环境中，如公共云、专有云、混合云中，容器的网络模型都有不同之处，为此容器平台提供了插件机制，来支持不同的网络实现。目前关于容器网络接口的配置主要有两种标准：容器网络模型（Container Network Model， CNM）和容器网络接口（Container Network Interface，CNI）。CNM 由 Docker 主导，吸引了 Cisco、VMware 等公司的应用；而 CNI 更归属社区，被运用于 Mesos、Cloud Foundry、K8S 之中。CNM 是 Docker 主导的网络方案，而且 libnetwork 和 Docker 原生编排等能力紧密集成在一起，内置的服务发现和负载均衡等能力对于开发者而言非常友好。但是正因如此，也对网络驱动的实现带来了一定挑战，在 Docker 17.06 中 Swarmkit 开始支持 node scope 网络，会简化一部分网络模型支持的复杂性。CNI 是社区主导的网络方案，整个方案很简洁，只提供基本的网络管理和 IPAM 管理接口，同时和其他网络能力（如 DNS，负载均衡等）保持正交。好处是网络驱动容易实现，三方编排可以方便地控制网络接口和容器对象的生命周期。不足之处则是，编排系统需要集成多个方案才能完整解决用户的诉求，比如在 Kubernetes 中，DNS 和 Ingress 都是通过 addon 的方式实现的，这也为部署和维护引入和复杂性。2. 两种设计的对比 CNM 是 Docker 提出的规范。Docker 引擎中的 libnetwork 是 CNM 的缺省实现，现在 CNM 已经被 Cisco Contiv, Project Calico,Weave 等项目所采纳。阿里云也提供了基于 CNM 的 VPC，MacVLAN 等网络驱动。CNM 提供了 Docker daemon 与网络驱动实现之间的控制接口。Docker 提供了原生网络驱动包括 none, bridge, overlay 以及 Macvlan/Ipvlan 等。除了 Linux 容器支持，Libnetwork 也推出了对 Wind