关于容器云部署问题

我们讨论过多次，要建设容器云平台，仅有Kubernetes是远远不够，还需要很多的基础组件来支撑整个业务应用。比如日志、监控、配置、注册发现、服务网关等组件。这些组件是容器化部署好还是虚拟机/物理机上部署好，都是绕不开的问题。

初始节点数量和服务数量少的情况下，可能基础组件容器化部署是个不错的选择。其实就像我们所说的开发测试环境，目的是为了快、敏捷，所以量不会很大。随着节点数增加，服务量增加，不只是Kubernetes自身组件会遇到瓶颈，服务治理服务管理等平台基础组件也会遇到同样的问题。

七、中间件部署

我们建设容器云，很重要的原因是希望利用云上中间件的能力。如果没有中间件服务，那将需要很多的工作来构建这些服务，不过幸运的是，已经有很多中间件可以在容器云上部署。不过同样面临一个“量”的问题，量大的情况下，是否能支撑，是否比非容器化需要成倍的资源来支撑，是否给运维带来一些困难。比如某证券的Kafka集群有20多台，内存配置一般选择64G，采用SSD硬盘，并做了raid5冗余，这样的配置在容器云平台肯定是不合适的，所以需要部署于虚拟机或者物理机上。

在开发测试环境我们还是建议使用容器化环境。在生产根据实际的情况和业务场景选择合适的部署方式。数据库什么的可能就不是很合适，虽然也支持，可以部署，但从运维、安全、组件稳定性等方面考虑，非容器化部署可能更合适。

八、微服务/业务服务部署

微服务肯定是要部署到容器上。目的就是为了利用容器的轻量、隔离、标准化、弹性伸缩等特性。微服务/业务服务往往是需要不断的改进、更新，所以服务整个生命周期要足够敏捷，不只是开发敏捷。其实从这点我们也可以看到，容器化部署比较适合经常变化的、轻量的，那些笨重的、基本没有太大变化的组件如果容器化部署可能无法展现容器的优点。把容器当虚拟机用，有点画蛇添足。其实很多公司选择互联网应用场景部署于容器云作为采用实施容器云的开端，也是因为这些原因吧。看来是英雄所见略同。

我们还讨论过容器化部署时，每个镜像可能会不小，几百兆、甚至上G，跟我们传统ESB服务部署对资源需求就有很大不同。容器化隔离更好，但是每个容器都会重复占用资源。比如java应用，通常一台机器安装一个JDK就可以了，可以运行很多个Java应用。但对于容器来说，每个容器都需要一个JDK，所以每个镜像都需要打包JDK，在网络传输、存储、运行时资源占用，似乎都没有节约。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!