容器化上云之可行性评估

容器平台本质上是一个分布式集群管理平台，首先要从应用负载的性质上分析容器化的合理性。

总的来说，分布式应用负载包括三类：

l   计算密集型

典型的计算密集型负载是传统HPC（高性能计算）应用。

l   存储密集型

典型的存储密集型负载是大数据应用。

l   长任务

典型的长任务负载是web类应用。

计算密集型和存储密集型的工作负载通常运行于专门的分布式集群管理系统之上，下面主要对长任务类型的负载的容器化进行分析。

首先考虑单个应用或应用组件的容器化，即一个最小部署单元的容器化。

容器基于linux内核技术实现，由于容器实现原理中固有的技术限制，对应用有如下要求：

l   能够基于linux运行；

l   应用不能修改系统内核模块和内核参数；

l   应用不依赖于特定的内核版本；

l   容器镜像大小最大不超过3GB；

l   应用对网络带宽的要求不大于1GE；

l   应用对内存的要求不大于32GB；

l   应用对CPU的要求不大于32vcpu；

同时，为了更好的运行容器化应用，充分发挥容器平台的优势，应用通常需要遵从以下最佳实践：

l   进程无状态化，对业务请求处理的正确性不依赖于本地文件或内存数据；

l   软件与配置分离，即容器作为不可变的软件发布包，将环境相关的配置外置到容器镜像以外，以实现多环境部署；

l   快速启动和优雅退出；

l   提供健康检查的接口，包括存活检查和业务就绪检查；

l   将日志对接到统一运维平台集中处理；

l   版本前向兼容性，在滚动升级中支持新老版本并存；

为了满足和遵从上述技术要求和最佳实践，通常应用需要经过如下改造和适配：

l   应用运行时改造，目标是适应容器化的运行时环境和减小运行时基础软件包的大小，例如从传统重量级应用中间件切换到轻量级应用中间件；

l   应用无状态化改造，主要涉及会话状态，内存中间计算结果状态，本地文件写操作等，改为采用分布式缓存，数据库，分布式文件系统等外置存储方案；

l   应用配置改造，将环境相关的配置信息改为采用环境变量、文件注入、外部配置服务等方式加载，并考虑可动态生效配置的热加载方案；

l   基础镜像体系建立，合理的基础镜像体系能够增加安全性，加快镜像构建和镜像分发的速度；

l   增加健康检查接口，包括应用存活检查和业务就绪检查，通常采用Restful API接口；

解决了单个组件容器化的问题以后，下一步要考虑多个容器之间相互访问的问题。

不同应用组件之间相互集成时存在两类场景：

l   本地通信，例如采用localhost方式访问，通常为采用多进程模型的应用。

l   远程通信，采用TCP或UDP协议通过网络相互访问。

本地通信的场景中，首先考虑采用Kubernetes的Pod模型进行封装，同一个Pod内的不同容器共享一套本地网络和本地存储环境，能够达在单机上运行多个进程相同的效果。

远程通信的场景中，虽然容器之间网络互通，但由于容器具有动态性，可能随时增加或减少实例，因此无法通过容器实例的IP地址相互访问，需要采用Kubernetes的Service模型进行封装，将可变的容器实例地址转换为不可变的Service地址，Service地址的形式包括域名和ClusterIP两种。

容器

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。