容器部署的未来是什么？

容器并不是一个新概念：迈向Linux容器的第一步在1979年就出现了。从那时起，应用程序的容器部署出现了十几个新的进化步伐，并且还没完。容器与其支持技术（如DevOps）和竞争对手（如虚拟机）进行交互，推动所涉及的所有技术进步。未来的容器将与现在的容器非常不同，但用户仍然可以跟踪趋势并充分利用每一步。

所有的容器架构都与VM架构不同——容器旨在虚拟化硬件和至少基本的平台软件，而不仅仅是硬件。这意味着容器应用程序共享操作系统和一些中间件，而VM模式需要为每个虚拟机复制所有软件。容器方法减少开销，允许每个服务器运行更多的应用程序。

从容器部署开始

早期的容器部署假定用户和应用程序运行良好，不需要相互保护或安全措施。这可能出现导致稳定性和安全性问题的错误或恶意做法。因此，在容器发展的头十年里，重点是改善容器的隔离。这开始于几个“监狱”概念，主要侧重于隔离容器的文件系统，并演变成具有里程碑意义的“Solaris Containers”，它利用了称为Zones的增强型Solaris OS功能来进一步隔离容器。

Google从2006年开始推出了几种容器架构，这些容器架构具有把硬件、存储和网络资源分片和分配给容器的功能，为用户提供了关于容器如何影响安全和影响共享同一服务器的其他组件性能的控制权。这些改进逐渐被引入了Linux，也导致了现代化容器的发展。

从这个时期开始，Linux LXC容器项目和推出Kubernetes编排器的谷歌LMCTFY工作跳跃式发展，并导致了Docker的出现。Docker旨在抓住容器的技术框架（隔离和资源控制）并对其进行操作。

目前，Kubernetes和Docker是容器的编排标准和架构标准，正在越来越多地融合，因此最好把它们看做一种方法。这个组合是今天容器化市场上的事实领导者（来自CoreOS的rkt是Docker的一个变种），但不是进化的终点。容器有两条新发展途径，这些途径会为未来打下基础。

容器部署和云

第一个途径是公有云容器服务的爆发。谷歌、亚马逊和微软都提供容器服务，便于用户将私有容器的使用扩展到云中，最常用于混合云应用。尽管其他容器编排模型也可用，但Kubernetes正在成为这些应用程序的编排事实标准。从基于云的容器服务的编排重点来看，容器架构演进的重点似乎是越来越多的应用程序生命周期管理，即容器部署的运营方面。

第二个途径是与虚拟机的融合。所有传统的VM提供商，包括公有云和私有软件堆栈，都对容器有一些支持。最重要的是允许部署虚拟机，而这些虚拟机反过来又成为容器主机，并支持在这种环境中对容器和虚拟机的统一管理模式。这使得DevOps、编排和之后的应用程序全生命周期管理又成为技术重点。

因为把应用程序生命周期作为与公有云容器服务路径相同，很明显，通过更支持应用程序部署、扩展和重新部署的操作，以及把资源和应用组件组织成单个资源池，容器架构得以发展。

这个单一的进化目标并没有消除容器架构演变的混乱，特别是在短期内。现在，推动容器发展的用户分成了两类：正在开发专门用于容器部署环境的应用程序，并且正在寻找通过额外的容器功能增强应用程序的方法的人；希望部署组件化地第三方或已经开发好的、在容器里的内部软件，以提高运营性能和可用性的人。这两类人正在为容器软件开辟不同的未来。

DevOps和容器架构

以开发为中心的团队正在集中精力让容器可以做一个独立的系统和平台软件能做的事——使容器从编程级别来看成为专用服务器的复制品。这就是从逻辑级别来看数据库处理、进程间连接和中间件集成的用武之处。这个团队的容器倡导者委员会似乎有一个“修复它”的心态——他们已经接受了容器，他们只是想让容器工作。

运营团队则侧重于使部署和应用程序生命周期的运营管理变得容易。这个团队实际上超越了一个容器为容器系统可能的需要和行为所做的事情。编排或DevOps一直是这里的主要重点，并且与应用运营相关的工作已经证明了以开发为中心的团队的许多目标也可以使用运营工具来实现。这样很好，因为这意味着容器的进化路径正在收敛。

从长远来看，将容器架构推向未来的是运营。容器、微服务、云计算和其他现代趋势相互结合，并和业务目标一起来创建IT策略。尽管这一策略优先考虑技术要素，但它会根据运营效率而起落。因此，随着时间的推移，容器趋势将成为应用运营趋势的重点。现在就开始计划才能在竞争中领先。

编译：Jonathan Zhang

作者：Tom Nolle

来源：http://searchmicroservices.techtarget.com/tip/What-is-the-future-of-container-deployment

投稿邮箱：[e-mail]