容器技术当前的不足和发展方向

最新推荐文章于 2025-03-23 08:41:28 发布

百科全书学派

最新推荐文章于 2025-03-23 08:41:28 发布

阅读量1.8k

点赞数

本文链接：https://blog.csdn.net/load2006/article/details/52671990

版权

内核在有些关键的资源隔离还不支持，或者需要比较高的版本，例如slab 内存，文件描述符，inode等等，容器环境独立的root，有待于内核功能的进一步完善；当然有些问题在容器这种轻量级虚拟化方案中很难解决。例如当内核发现物理页不足时，需要优化回收page cache，然而这些page可能归属于某些容器的进程，回收可能导致容器中应用进程cache miss，性能急剧下降。
k8s之类编排和调度引擎，暂时缺少优先级的概念，例如在业务高峰期kill掉一些低优先级的容器，释放资源来扩展高优先级任务。
k8s在运行时尚无法调整容器的物理资源，不清楚是cgroup的限制还是k8s自己的限制；理论上说运行时的物理资源再分配，cgroup实现比hyperversor要简单；
k8s在运行时无法动态的调整pod的配置；
容器网络尚未形成一种事实上的标准；
容器编排尚未支持复杂的工作流引擎或者job调度。当然也可以说这些事情本身就不该容器关心，而是mesos/yarn之类来做的。
容器究竟能否用来跑一些有状态的服务，nosql,rdbms,hadoop？目前看git hub上有不少hadoop/spark on docker的共享。
paas+docker，or paas+vm，理论上说docker更合适，redhat看到了这个方向，用docker重构其openshift的paas平台
docker+服务治理框架，看起来很美，目前还没有落地的现成方案；阿里的edas是基于vm做scale；
分布式系统的容器话部署和安装。mirantis已经开始做openstack的容器话部署了； rancher则实现了k8s/mesos的容器话部署，app商店也很丰富；将来的应用运维的兄弟，只需要把rancher安装好就行了，接下来从nginx到redis到mysql，再到hadoop/spark，点击鼠标署即可完成部署。