中文文献阅读记录
文献阅读目录
1 基于macvlan的Docker容器网络系统设计
2 面向应用的轻量级虚拟化高可用性技术研究
3 基于高性能计算的并行算法研究
1
Docker 网络现状
利用Linux network namespace基础,包括网络设备,v4,v6协议栈,IP路由表防火墙,namespace实现资源隔离
依靠网络虚拟化技术,Linux网桥和veth pair的网络技术栈
网桥是虚拟交换设备,可以提供网络访问,功能与物理的二层交换机相同
veth pair 虚拟网络设备对,类似管道
Docker实现了四种网络模式
host 模式 和宿主机共用一个network namespace,容器不会虚拟自己的网卡配置自己的IP等共享宿主机资源
文件系统各进程列表等还是和宿主机隔离的, 很好的解决了容器与外界通信的地址转换,降低了隔离性,还会引起网络资源的竞争和冲突
container模式 container指与存在的某个容器共享网络资源,两个容器的进程可以通过lo回环网卡设备通信,增加容器间通信的便利性和效率,将一个应用的多个组件放在不同的容器中,容器配成container模式,降低了容器间的隔离性。
none模式
每个docker容器拥有自己的network namespace ,并不为Docker容器进行网络配置,需要用户为docker容器添加网卡,配置IP,自由度大可自定义网络环境
bridge模式
默认的网络模式,容器都有自己的network namespace,宿主机上的docker容器可以通过veth pair 连接到linux网桥上,docker0 网桥上的veth网卡相当于交换机上的端口,
可以将多个容器或虚拟机连接其上,docker0网桥可以为其上的容器转发数据帧,使得同一台宿主机上的docker容器间可以相互通信,
docker daemon 会从RFC1918所定义的私有IP网段中,选择一个和宿主机不同的IP地址和子网分配给docker0,连接到docker0的容器会选择一个未使用的IP使用,docker0的IP充当这些容器的
默认网关,docker容器的网段和主机不在同一个平面,docker容器会通过Linux宿主机的IP——Forward功能与外界通信
docker 网络模型存在的问题
1 容器间不能跨主机通信,属于单机型
2 不支持vlan隔离 vlan隔离企业广泛应用,两层隔离提高带宽利用率,有效隔离了广播域,支持多租户,
虚拟机或者容器放在vlan中,不是直接暴露在互联网
3 IP地址管理不完善,容器只能从私有网段中随机获取一个IP,不支持指定IP的方式,不支持DHCP,docker容器重启后容器的IP地址会改变
4 没有网络的QoS支持
docker相关技术概述
传统的CS架构
Docker daemon 主要的用户接口
docker server 接受来自client的请求,根据不同的请求分发给daemon的不同的模块
通过driver模块实现docker容器的执行
创建: Docker registry 下载吗graphdriver 将下载的镜像以graph的形式存储到本地
创立网络环境时,可以由networkdriver创建并配置网络环境
执行 execdriver驱动
libcontainer 独立容器管理包
networkdriver 和exedriver 通过libcontainer 实现
UTS IPC PID Network Mount User 等5 个namespace子系统
cgroup 实现对容器的资源限制
docker 组件介绍
docker daemon 核心的后台进程
六种namespace 隔离技术
UTS CLONE_NEWUTS 主机名与域名
IPC 信号量,消息队列和共享内存
PID 进程编号
Network 网络设备,网络栈,端口
Mount 挂载点
User 用户和用户组
容器虚拟化的核心技术
Chroot
linux的一个系统调用,命令,可以为进程建立新的目录环境,进程除了访问该目录环境之外, 其他的外部文件目录均不可访问
好处:1 限制了一个容器的用户权限,安全性保障
2 建立一个与宿主机系统和其他容器系统隔离开的系统目录,方便容器内部软件的使用
3 快速的引导容器的启动和重启,在指定的系统根目录文职引导init进程,实现容器的快速启动。
namespaces隔离技术
六种隔离技术
cgroups 资源分配技术
通过任务的不同对资源进行分组划分,可以提供一个整合的系统资源管理模式接口,cgroup组之间的任务可以相互联系,并且任务也是可以在组织间进行转移
双机热备技术
两种不同的模式,active/active
一个出现故障。另一个全部转移,负载突然增大系统的运行速度下降,服务的响应时间延长
应用场景,服务器不只是一种服务,用户的访问流量也并不是十分庞大
Active/Standby
定时进行状态同步,冗余备份适用于服务器支撑单独的服务,并且服务的请求量较大的情形。
现有的Docker网络解决方案
1 pipework 小巧灵活,缺点是不自动化,配置不持久没有与docker daemon集成
2 socketplane 基于OVS的voerlay解决方案,可以解决多主机容器间的容器直接通信问题,功能全
但是bug 多不够稳定,性能较差
3 flannel:overlay网络的解决方案,可以很好地域库贝尔netes结合,可使得kubernetes部署在除GCE以外的其他Iaas平台,确点是没有VLAN划分,不支持多租户
4 libnetwork: 官方可插拔的网络后端方案,旨在将docker的网络功能从docker核心代码分离
缺点功能不够完善
目前普遍采用OVS的overlay方案,其实质是隧道技术
OVS方案
缺点:
OVS 第三方依赖,重量级
性能 比veth 和linux bridge好,隧道需要对数据包进行封装和解封装,开销就会带来性能损失
Debug 困难
macvlan 比较简单
跨节点容器通信
flannel技术
pod中的container共享同一个网络空间,flannel充当了一个桥接的角色
hpl经常用于测试高性能计算的性能
容器调度算法的研究
lXC命令接触
论文问题汇总
是否可以考虑高性能计算的通用性,相关领域专家不会部署和使用
考虑传统MPI的结合
现在的商业云计算中可能更多是考虑成本,导致节点的性能低下不能够很好地承担任务
阿姆达尔定律中加速比是有上限的不可能一直无限拓展下去
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 583614868@qq.com
文章标题:中文文献阅读记录
文章字数:1.7k
本文作者:钟帅豪
发布时间:2020-01-13, 11:38:54
最后更新:2020-01-15, 19:31:47
原始链接:http://jhshz520.github.io/2020/01/13/中文文献阅读记录/版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。