1.隔离不彻底 目前 Windows 容器的实现模式分为:"进程容器"和"Hyper-V 容器"。"进程容器"是通过任务名管理来模拟资源隔离的,所以这种隔离是不彻底的,最常见的限制就是没法 OOM kill。而"Hyper-V 容器"是通过 内核隔离技术来实现,因此这种隔离是最彻底的。 2.升级难平滑 比起"长通道版",显然"半年通道版"来得更加敏捷高效,但是转而来的是更复杂的升级管理。 (1)严格内核版本要求的"进程容器":由于进程容器是通过任务名模拟的,这就导致了容器的 base 镜像内核版本必须等于节点内核版本。换句话说,1903 SAC 的容器是没法跑在 1809 SAC 的节点上,反之亦然。 (2)有限兼容的"Hyper-V 容器":"Hyper-V 容器"的向后兼容是有限制的。比方说,在 2004 SAC 的容器上,通过 Hyper-V 技术创建的容器,只能兼容 2014 SAC,1909 SAC 和 1903 SAC,而无法运行1809 SAC。 (3)安全管理困境:当碰到安全补丁的时候,问题会变得更麻烦,除了节点要打安全补丁以外,容器也要重新 re-package。 3.文件难管理 目前的 Windows 容器的文件管理比较 tricky。由于 Docker EE 只实现了主机目录级别的挂载,这就导致 Windows 要读写某个文件的时候,必须把其整个目录挂载进来。于此同时,由于主机的 ACL 管理不能被投影到容器内,这就导致了Windows 容器对文件的权限修改是不能被主机所接收的。
答复内容摘自《云原生技术与架构实践年货小红书》,这本电子书收录开发者藏经阁 下载连接:https://developer.aliyun.com/topic/download?id=1127
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。