Docker容器云，带你体验不一样的云计算时代

容器，容器云的诞生给我们的生活带来了便利，我们已经离不开容器，离不开这个云计算时代了。

我们为什么使用容器？

我们为什么使用虚拟机（云主机）， 为什么使用物理机？ 这一系列的问题并没有一个统一的标准答案，因为以上几类技术栈都有自身最适用的场景，在最佳实践之下，它们分别都是不可替代的。 原本没有虚拟机，所有类型的业务应用都直接跑在物理主机上面。计算资源和存储资源都难于增减，要么就是一直不够用，要么就一直是把过剩的资源浪费掉。所以后来我们看到大家越来越多得使用虚拟机（或云主机），物理机的使用场景被极大地压缩到了像数据库系统这样的特殊类型应用上面。

原本也没有容器，我们把大部分的业务应用跑在虚拟机（或云主机）上面。把少部分特殊类型的应用仍然跑在物理主机上面，但现在所有的虚拟机技术方案，都无法回避两个主要的问题，一个问题是虚拟化Hypervisor管理软件本身的资源消耗与磁盘IO性能降低。另一个是虚拟机仍然还是一个独立的操作系统，对很多类型的业务应用来说都显得太重了，导致我们在处理虚拟机的扩缩容与配置管理工作时效率低下，所以，我们后来发现了容器的好处，所有业务应用可以直接运行在物理主机的操作系统之上。可以直接读写磁盘，应用之间通过计算、存储和网络资源的命名空间进行隔离，为每个应用形成一个逻辑上独立的“容器操作系统”。除此之外，容器技术还有以下优点；简化部署，多环境支持，快速启动，服务编排。易于迁移......

容器技术的一些缺点；仍然不能做到彻底的安全隔离，技术栈复杂度飚升，尤其是在应用了容器集群技术之后，所以如果只是小规模的使用。做实验或测试是可以的，上生产环境需要三思而后行。

容器与容器集群技术的演进

 

Docker容器主要基于以下几点个关键技术实现的：– Namespaces – Cgroups技术 – Image镜像

容器引擎容器引擎（Engine）或者容器运行时（Runtime）是容器系统的核心，也是很多人使用“容器”这个词语的指代对象。容器引擎能够创建和运行容器，而容器的定义一般是以文本方式保存的。比如 Dockerfile。

Docker Engine ；目前最流行的容器引擎，也是业界的事实标准。Rkt：CoreOS 团队推出的容器引擎，有着更加简单的架。一直作为 Docker 的直接竞争对手存在，是 kubernetes 调度系统支持的容器引擎之一。containerd；这个新的Daemon是对Docker内部组件的一个重构以便支持OCI规范。containerd 主要职责是镜像管理（镜像、元信息等）容器执行（调用最终运行时组件执行）。向上为 Docker Daemon 提供了 gRPC 接口，向下通过 containerd-shim 结合 runC。使得引擎可以独立升级。docker-shim：；him 通过调用 containerd 启动 docker 容器，所以每启动一个容器都会起一个新的docker-shim进程，docker-shim是通过指定的三个参数；容器id，boundle目录和运行时（默认为runC）来调用runC的api创建一个容器，runC ；是 Docker 按照开放容器格式标准（OCF, Open Container Format）制定的一种具体实现，实现了容器启停，资源隔离等功能，所以是可以不用通过 docker 引擎直接使用runC运行一个容器的。也支持通过改变参数配置，选择使用其他的容器运行时实现。RunC可以说是各大CaaS厂商间合纵连横、相互妥协的结果。注：RunC在各个CaaS厂商的推动下在生产环境得到广泛的应用。Kubernetes目前基本只支持RunC容器，对于Docker超出其容器抽象层之外的功能。一概不支持，同样，Mesos也通过其Unified Containerizer只支持RunC容器，目前还支持Docker，但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC，不支持Docker超出RunC之前的功能。

为什么在容器的启动或运行过程中需要一个 docker-containerd-shim 进程呢，其目的有如下几点；– 它允许容器运行时（即 runC）在启动容器之后退出，简单说就是不必为每个容器一直运行一个容器运行时（runC） – 即使在 containerd 和 dockerd 都挂掉的情况下。容器的标准 IO 和其它的文件描述符也都是可用的 – 向 containerd 报告容器的退出状态。

rkt与containerd的区别是什么？一个主要的不同之处是，rkt作为一个无守护进程的工具（daemonless tool），可以用来在生产环境中。集成和执行那些特别的有关键用途的容器，举个例子，CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent。即kublet，更多的例子包括在Kubernetes生态环境中。使用rkt来用一种容器化的方式挂载volume，这也意味着rkt能被集成进并和Linux的init系统一起使用，因为rkt自己并不是一个init系统。kubernets支持容器进行部署，其所支持的容器不只是仅仅局限于docker，CoreOS的rkt也是容器玩家之一。虽然跟docker比起来还是明显处于绝对下风，但有竞争总要好过没有。

 

容器编排和管理系统

容器是很轻量化的技术，相对于物理机和虚机而言。这意味着在等量资源的基础上能创建出更多的容器实例出来，一旦面对着分布在多台主机上且拥有数百套容器的大规模应用程序时，传统的或单机的容器管理解决方案就会变得力不从心，另一方面，由于为微服务提供了越来越完善的原生支持，在一个容器集群中的容器粒度越来越小数量越来越多。在这种情况下，容器或微服务都需要接受管理并有序接入外部环境。从而实现调度，负载均衡以及分配等任务， 简单而高效地管理快速增涨的容器实例。自然成了一个容器编排系统的主要任务。

容器集群管理工具能在一组服务器上管理多容器组合成的应用，每个应用集群在容器编排工具看来是一个部署或管理实体。容器集群管理工具全方位为应用集群实现自动化，包括应用实例部署，应用更新，健康检查，弹性伸缩。自动容错等等......

容器编排和管理系统界的主要选手– Kubernetes：Google 开源的容器管理系统，起源于内部历史悠久的 Borg 系统，因为其丰富的功能被多家公司使用，其发展路线注重规范的标准化和厂商“中立”。支持底层不同的容器运行时和引擎（比如 Rkt），逐渐解除对 Docker 的依赖，Kubernetes的核心是如何解决自动部署，扩展和管理容器化（containerized）应用程序。目前该项目在github上Star数量为43k。 – Docker Swarm： 在 Docker 1.2 版本后将 Swarm 集成在了 Docker 引擎中。用户能够轻松快速搭建出来 docker 容器集群。几乎完全兼容 docker API 的特性，目前该项目在github上Star数量为5.3k。 – Mesosphere Marathon：Apache Mesos 的调度框架目标是成为数据中心的操作系统。完全接管数据中心的管理工作，Mesos理念是数据中心操作系统（DCOS）。为了解决IaaS层的网络、计算和存储问题，所以Mesos的核心是解决物理资源层的问题，Marathon是为Mesosphere DC/OS和Apache Mesos设计的容器编排平台，目前该项目在github上Star数量为3.7k。

中国市场的表现在中国市场，2017 年 6 月 Kubernetes 中国社区 K8SMeetup 。曾组织了国内首个针对中国容器开发者和企业用户的调研，在容器编排工具中，Kubernetes占据了70％市场份额，另外，Kubernetes 平台上运行的应用类型非常广泛。几乎包括了除hadoop大数据技术栈以外的各种类型应用。

   随着容器云的发展，时代的前进，2020年的今天在Docker容器云的引领前行！

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！