虽然容器技术这几年很热，受到很多人追捧，但容器的生产应用在传统行业却始终难以成为主流。在多数采用了容器技术的公司也只是测试和运行并不重要的系统。究其原因，容器自身特性和目前的技术水平使其只能成为小众化产品，对于大多数应用场景的需求却难以满足。是容器技术不好吗？似乎也不是。从 Google 若干年前就使用 Borg 的情况看，容器的应用场景也是很多的。但是在互联网企业中的应用场景和传统企业的应用场景是不一样的，不能直接照搬过来，必须要考虑传统行业的实际需求。除了传统行业技术人员的自身容器技术认知、组织架构和基础设施建设外，容器云平台产品化的能力也远未达到生产就绪的条件。我们曾经说，当前大部分厂商的产品只不过仅仅适合 PoC 测试的工具，远未达到生产就绪的条件。

容器云平台的前景发展取决于能多大程度上满足生产就绪的要求，容器云平台必须真正提升到容器化 PaaS 平台的层级，使其成为能支撑企业级应用场景，才是私有化容器云生产就绪发展的可行途径。

一、 对容器技术的认知局限

并不像互联网公司，传统行业内的技术人员对容器等技术的认知大部分还处于比较基础的阶段。传统行业并不像互联网公司有那么的技术人员，靠人堆起了对新技术的支持，传统行业更多是使用成熟的技术来服务于业务，技术只是工具、是加速器而不能喧宾夺主。虽然像亚马逊等公司通过技术实现了逆袭，把副业做成了主业，但不可能每家公司都这样。所以对大多数传统行业的公司来说，使用技术工具来帮助完成业务，提升业务效率才是目的。

所以在传统行业的大多数企业对技术人员的要求无论在量或者质上，都不可能像互联网公司那样。业务模式不一样，技术场景不一样，人才架构不一样，技术认知不一样等等都带来了技术应用的差异，照抄照搬只会是死路一条。因此，对于传统行业，必须容器云平台提出更高的产品化要求，才能适合、满足这些行业的业务场景要求。

二、 组织架构的局限

容器云平台是由运维团队来建设，还是由开发团队来建设，这是个问题。传统泾渭分明的开发运维部门职责划分，一定是和容器云平台的建设冲突的。容器云平台适合在既懂开发又懂运维的团队建设，类似于 Google SRE 。容器既是技术问题，也和业务密切相关。在互联网公司开发人员可以用较低的学习成本来熟悉容器的使用，可以快速的熟悉 docker 、 kubernetes 的命令和操作，把业务服务直接融于容器之中，一个人可以完成一个团队的工作（这也让很多人误解 “ 开发运维一体化 ” ，不过这不是的）。 Google SRE 运维基础平台如容器云平台，同时开发运维工具，也运维业务应用，它使业务开发人员专注于业务研发，而不需要考虑开发、测试、生产环境和运维工具的维护。所以传统的开发运维组织架构需要调整，开发专注于业务应用开发，运维负责环境、工具及就绪的业务应用的运维以及运维自动化、智能化工具的开发。而传统基础设施资源则可以独立出来，自建、外包、公有云等方式都可以根据需要满足需求。

三、 基础设施及架构局限

由于组织架构的局限性，导致大部分传统行业的公司的基础设施架构相对落后，依然是独立的单体系统建设思路，然后做集成，通过一层一层的打补丁，使系统之间的关系越来越复杂。就像上面提到的，基础设施资源需要融合打通，向全公司提供基础设施资源服务。这样在其之上的 PaaS 平台、应用系统、工具系统等都可以共享这些资源，在降低成本提升效率的同时，也降低了运维的难度，使 IT 架构简单化。

云计算最重要的就是要实现基础设施资源的融合和统一管控。目前很多公司所提供的方案都达不到要求，都是传统的单体系统建设思维，所以在建设容器云平台之前，必须要认识到基础设施资源融合建设的重要性。

四、 生产就绪

生产和测试的要求是不一样的。互联网企业的需求和传统企业的需求也是不一样的。不同的场景面临着不同的需求，所以不是一个容器或容器云平台就能满足所有的需求。

（一） 仅有容器是不够的

我们知道容器云平台首先要有容器引擎如 Docker ，然后需要管理和调度容器的工具，比如 Kubernetes ，然后需要有运行容器的基础设施资源。通过网络把容器调度到公有或私有云端运行，就构建了容器云平台。容器里运行着业务应用和业务服务，要监控其运行状况、资源使用，维护其状态，定位其问题等等就需要相应的日志系统、监控系统、告警系统、服务治理系统等等。容器云平台可以私有化部署，封装了基础设施资源的管理和维护。通常为了资源的弹性扩容效率，基于虚拟化之上部署容器云平台（也可以虚拟化和物理服务器并存）。同时也可能存在多云，需要调度容器到不同的云上运行，这就需要云管平台来管理多云环境，并且支持容器在不同云环境的调度和运行管理。

这里云管的职责范围需要和容器云平台的职责范围厘清楚，不是云管去管理容器云平台，而是云管去支撑容器云平台。云管可以提供各种类型的云资源服务，并且支持云资源的弹性扩缩容，这就避免了私有化容器云资源的局限性，使容器云平台获得更大的资源调度能力。

（二） 容器云平台资源管理需要云管支撑

私有化容器云的前景需要和云管平台集成或融合，使之成为一体两层。否则容器云平台的资源管理将会是一个负担。所以云管和容器云平台之间的职责范围就需要定义明确。

简单的说，云管就是管理云基础设施资源，为容器云平台提供云基础设施资源服务。容器云平台调度容器到这些云平台上。云管不是什么“云”都管，把所有的功能都糅合到一起，乱点鸳鸯谱。明确容器云和云管的职责范围和其所在的层次，才能设计出生产就绪的产品，满足实际的需要。

云管为容器云平台提供不同类型的计算资源、存储资源和网络资源等。举例来说，私有容器云环境下，容器和容器节点等所使用的网段和 IP 地址就可以由云管平台来进行管理和自动分配。实现资源的使用情况跟踪和统计计费，避免重复的工作和额外的投入。这也是我们“平台融合”的建设思路。

云管直接支撑容器云平台的另外的好处是可以方便的从云管平台获得基础设施资源的运行信息，比如节点的 CPU 数、 Memory 数、使用量、进程数、 file descriptor 数、所在宿主机等，甚至数据中心信息、机房、机柜、机架、机位、端口等信息都可以轻松下钻获取。这也是我们所提倡的分层自服务能力设计。从整体看是一体的，分开看又是独立的，各部分职责清晰，范围明确，不会出现重复的建设和冗余的集成。

（三） 容器云是支撑应用的平台

我们在建设容器云平台时提出“以应用管理为中心”，容器云平台的核心是支撑应用的托管、部署、运行和管理、治理。重点支撑 DevOps 中的 Dev 能力。

容器云平台服务治理能力，不是 SpringCloud 、也不是 istio 等。那些简单把微服务框架等同于服务治理的说法要么是不懂、要么是故意在误导微服务的设计和使用，也间接的误导了容器云平台的场景设计和使用。容器可以看作是一种资源，而容器云平台是基于容器资源支撑业务应用的。容器云平台结合相应的组件构建的容器化 PaaS 平台则提供了更完整的 PaaS 平台服务能力，因此容器云平台可以看作是简化版的 PaaS ，它需要提供的是平台服务能力，不仅仅是容器服务能力。 Docker 就可以提供容器服务了，但对用户来说要求相对比较高了。容器云平台或者 PaaS 平台要让不懂容器的人能够顺利的用起来，而不是需要高昂的学习成本。因此容器云在应用的打包、部署、管理、运维、监控、日志、调度、服务治理等方面要能提供完善的支撑能力。这样，容器云平台作为应用运行时支撑平台，结合微服务架构和 DevOps 闭环流程，能很好的满足和支撑企业的业务敏捷、弹性等的需求。

五、 认识到容器云平台的局限和优势

当前在进行系统建设时，不能只看一个点，只考虑一个系统，必须从企业全局系统建设的角度考虑，明确容器云平台的定位及和其他系统的关系。容器云平台作为 PaaS 层的一种实现，向下使用基础设施资源，向上支撑业务应用，中间需要相应的平台配套组件设施。这样整个体系就相对完整了。在建设容器云平台时还需要理解容器的特点，选择合适的场景和工具。

（一） 开源技术的局限性

容器作为一种开源技术，在不断的发展完善中。由于其技术的快速迭代和变化，使很多对稳定性要求高的企业不敢轻易尝试这些技术。开源的项目基本上都是不成熟的技术，需要众多的开源贡献者不断的完善，而开源的技术一旦趋于成熟，往往就不开源了，所以这也是很多传统企业难以大量生产使用的一个原因。开源技术由于其不成熟，需要大量的技术人员来支撑，这个成本其实是不低的。而成熟之后面临着继续付出商业化 license 费用，或者更换组件，都不是最好的选择。甚至有些开源慢慢就没落了，不得不更换，这也带来很大的风险。

（二） 容器自身技术特点的局限性

很多企业并不追求技术有多新，而是追求系统的可靠性与稳定性，不能出意外。这和容器的特点是矛盾的。

我们知道容器的特性就是轻量、弹性、无状态。不过其自身特点也使其应用受限。容器的这些特点适合微服务架构有弹性伸缩的业务应用，比如互联网类业务，非常匹配。但传统企业还是以单体系统为主，这些系统相对比较笨重，而且维护繁琐，往往不支持扩展，而且如果重启可能会带来数据丢失等问题，并不适合以容器化部署。其实我们也一直强调，像 Kafka 、 Redis 等中间件，可以在测试环境部署用于快速搭建组件测试环境，却不适合用于生产。这些组件生产环境一定要考虑物理化部署。它们不需要天天变更、重启，需要的是稳定的运行和稳定的服务。

不同的场景需求可能完全是不一样的。测试和生产环境也不是百分百匹配的，而是基于业务需求和业务场景而确定的。

（三） 容器云平台的优势

基于容器所构建的容器云平台的优势也来源于容器的特点，适合轻量、变化快、弹性扩缩容、

容器云平台要使用基础设施资源。通常我们基于虚拟化来构建容器云平台节点，这样可以实现节点的快速扩展。而虚拟化平台如果和容器云平台集成，就可以实现容器节点的弹性扩展。但虚拟化管理通常是云管的能力，云管又可以集成其他云资源，这样通过云管抽象，就把公有云、私有云、行业云等的基础设施资源服务按照标准的方式提供给容器云平台。在云管上不提供中间件等服务，云管只管云基础设施资源。

容器云平台支撑微服务架构的应用则具备天生的优势。而通过微服务化在企业内部构建可重用的技术服务、数据服务、业务服务等来构建服务中台则能支撑企业业务应用的敏捷迭代，这才是比较好的匹配。

六、 容器化PaaS平台

PaaS 是一套云操作系统，所以其不容易实现。它要比 IaaS 和 SaaS 的实现困难许多。不过容器技术的应用为 PaaS 平台的实现提供了一种简化的思路、一种组件化思路。可以结合微服务架构的思想构建容器化 PaaS 平台，每个容器其实就是云操作系统的一个组件 / 进程， Kubernetes 相当于内核实现管理和调度这些组件 / 进程，而容器化 PaaS 平台则是多集群多类型资源多类型应用的企业级云操作系统。提供应用开发、应用托管、应用运维的 PaaS 平台能力。

如果容器和容器云平台能实现这样的能力，那么容器云平台的应用场景将会扩展支持众多的传统业务场景和需求，真正实现容器云平台的质变飞跃。