在过去几年，容器走过了漫长的道路–从利基技术发展成为部署现代云原生应用和服务的关键平台，而随着部署的增长，这个生态系统也在不断发展。
容器作为一个概念其实已经存在很多年，它一直是作为分配计算机资源的一种方法，这也是虚拟机的功能。
这两者的区别是，虚拟化在裸机级别运行，容器是从操作系统内核交付，并且，本质上为每个单独应用或代码模块提供单独的执行环境。
曾经企业主要是使用虚拟机，直到Docker给容器注入新生命力—通过将容器技术与工具相结合，使其成为敏捷开发的理想工具。
由于容器比虚拟机更轻且速度更快，企业也喜欢使用容器来部署基于微服务的架构和部署DevOps举措。
自五年前Docker平台推出以来，容器生态系统已经迅速扩张。这是好事情，因为这项技术最初缺乏很多支持工具和功能（例如协调和负载均衡）–这些工具都围绕虚拟机创建，这也促使开发人员迅速填补这个空白。
构建生态系统
我们看到，在编排方面，Kubernetes已经在很大程度赢得了这场比赛。它不仅用于越来越多的内部部署容器平台，而且所有主要云服务提供商提供容器服务时都将Kubernetes作为编排层。
与此同时，支持容器的底层技术也建立了更多的标准化，这些技术包括容器运行时（实际运行容器的引擎）以及用于存储和分发容器映像的文件格式。
在运行时方面，在Linux基金会支持下成立的开放容器倡议组织（OCI）负责对容器以及进行监督，并且，Docker贡献了runc：基于其自身技术的参考部署，其中提供基本功能。
随后Docker将runc整合到名为containerd的功能更丰富的运行时中，以供自己使用，并将其提交给云原生计算基金会（CNCF），这是监督Kubernetes的机构。
Docker也在自己的产品中使用containerd。由于它包含runc，containerd仍然与OCI规范兼容。
在一段时间后，OCI成立了一个新的工作组，旨在为标准容器映像格式创建规范。Dcoker也参与到创建规范的工作中，并将产生的OCI格式整合到其自己的平台，作为Docker V2映像。
因此，容器运行时和容器映像都开始有自己的标准。所有容器运行时最终都需要遵守OCI标准，这意味着如果基础设施的其他部分也兼容OCI的话，则应该可相对容易地混合和匹配来自不同来源的软件组件作为容器部署的一部分。
解决容器安全难题
那些想要使用容器的企业非常关注容器的安全性，因为它们并不提供虚拟机部署中虚拟管理程序实现的实例之间的隔离级别。
这是因为所有在主机运行的容器都是通过调用相同共享内核来访问资源，这使得潜在漏洞可能影响所有容器。
目前容器领域正在试图以不同方式解决这个问题。例如，OpenStack支持的Kata容器项目最近发布了1.0版，它的策略是创建类似于容器的轻量级虚拟机。
它通过使用遵守OCI规范的虚拟机管理程序来实现此目的，并将外部世界视为容器运行时。该管理程序会创建一个轻量级虚拟机，封装最小的操作系统内核和实际容器。
这与一些现有平台整合容器支持的方式类似。Pivotal Container Service（PKS）在VMware的vSphere或者谷歌Cloud Platform的虚拟机内运行容器，而亚马逊的AWS运行多个容器服务，所有容器服务将容器放在EC2实例内。
这些都是用标准虚拟机作为容器主机，而Kata Containers似乎是用轻量级虚拟机伪装作为容器运行时。
与此同时，谷歌已经开发出另一种解决方案来提高容器安全性，即通过gVisor开源项目。在这里他们没有使用虚拟机管理程序，而是充当主机内核和容器应用之间的额外内核。
gVisor内核具有正常用户级特权，并可拦截来自应用的系统调用，通过执行该操作来为它们提供服务。换句话说，gVisor就像是代理或者缓冲层，阻止应用直接访问主机内核或者其他资源。
然而，gVisor和Kata Containers都带来增加额外性能开销和潜在应用兼容性问题。对于gVisor更是如此，谷歌警告称它不会支持每次Linux系统调用。
另外，容器生态系统仍在继续扩张，第三方工具和平台在不断涌现，以填补构建容器基础设施所需的缺失部分。
其中新工具可为特定工作负载提供持久性存储，例如StorageOS或者PortWorx。其他工具还提供监视和高级网络功能，有些工具则集中在构建容器映像存储库。
另外，其他供应商和项目专注于围绕容器构建平台来创建交钥匙式交付管道，以支持现代云原生应用（例如CircleCl和GoCD）的整个构建、测试和部署。
可以说，很多像亚马逊这样的云服务提供商已经提供这种功能，而传统平台即服务产品（例如Red Hat的OpenShift）已经变成围绕容器的开发者平台。
不过，目前容器可能不像虚拟机那样成熟，特别是在管理和编排领域，但这个市场正在迅速发展，容器正成为云计算时代应用开发的***工具。
