docker核心原理——unionfs、namespace、cgroup

docker

核心原理

docker的核心原理其实就是cgroup+namespace+unionfs 组合实现的隔离机制,资源控制等。

隔离机制

  • 在容器进程启动之前重新挂载它的整个根⽬录“/”,⽤来为容器提供隔离后的执⾏环境⽂件系统
  • 通过Linux Namespace 创建隔离,决定进程能够看到和使⽤哪些东⻄。
  • 通过control groups 技术来约束进程对资源的使⽤

unionfs

首先看rootfs,rootfs 是Docker 容器在启动时内部进程可⻅的⽂件系统,即Docker容器的根⽬录。rootfs通常包含⼀个操作系统运⾏所需的⽂件系统,例如可能包含经典的类Unix操作系统中的⽬录系统,如/dev、/proc、/bin、/etc、/lib、/usr、/tmp及运⾏Docker容器所需的配置⽂件、⼯具等。

在传统的linux操作系统内核启动时,⾸先挂载⼀个只读(read-only)的rootfs,当系统检测器完整性之后,再将其切换为读写(read-write)模式。⽽在Docker架构中,当Docker daemon 为Docker容器挂载rootfs时,沿⽤的Linux内核启动时的⽅法,即将rootfs设为只读模式。在挂载完毕之后,利⽤联合挂载(union mount)技术在已有的只读rootfs上再挂载⼀个读写层。这样,可读写层处于Docker容docker器⽂件系统的最顶层,其下可能联合挂载了多个只读层,只有在Docker容器运⾏过程中⽂件系统发⽣变化是,才会把变化的⽂件内容写到可读写层,并且隐藏只读层中的⽼版本⽂件。

如图所示,还可以在rootfs之上继续挂载读写层,也可以挂载只读层(可以用于共享)。上层的修改不会影响到下层的只读层。而只读层的修改会同步到上层可写层

docker核心原理——unionfs、namespace、cgroup_第1张图片

有了容器镜像“打包操作系统”的能⼒,这个最基础的依赖环境也终于变成了应⽤沙盒的⼀部分。这就赋予了容器所谓的⼀致性:⽆论在本地、云端,还是在⼀台任何地⽅的机器上,⽤户只需要解压打包好的容器镜像,那么这个应⽤运⾏所需要的完整的执⾏环境就被重现出来了

namespace

概念

是一种资源隔离技术,可以和c++里的namespace类比

  • namespace 是 Linux 内核⽤来隔离内核资源的⽅式。通过 namespace 可以让⼀些进程只能看到与⾃⼰相关的⼀部分资源,⽽另外⼀些进程也只能看到与它们⾃⼰相关的资源,这两拨进程根本就感觉不到对⽅的存在。具体的实现⽅式是把⼀个或多个进程的相关资源指定在同⼀个 namespace 中。

  • Linux namespaces 是对全局系统资源的⼀种封装隔离,使得处于不同 namespace 的进程拥有独⽴的全局系统资源,改变⼀个 namespace 中的系统资源只会影响当前 namespace ⾥的进程,对其他namespace 中的进程没有影响。

namespace解决了什么问题呢?

Linux 内核实现 namespace 的⼀个主要⽬的就是实现轻量级虚拟化(容器)服务。在同⼀个namespace 下的进程可以感知彼此的变化,⽽对外界的进程⼀⽆所知。这样就可以让容器中的进程产⽣错觉,认为⾃⼰置身于⼀个独⽴的系统中,从⽽达到隔离的⽬的。也就是说 linux 内核提供的namespace 技术为 docker 等容器技术的出现和发展提供了基础条件。

有哪些namespace
  • Mount Namespace隔离了⼀组进程所看到的⽂件系统挂载点的集合,因此,在不同MountNamespace的进程看到的⽂件系统层次结构也不同
  • UTS Namespace隔离了uname()系统调⽤返回的两个系统标示符nodename和domainname,在容器的上下⽂中,UTS Namespace允许每个容器拥有⾃⼰的hostname和NIS domain name,这对于初始化和配置脚本是很有⽤的,这些脚本根据这些名称来定制它们的操作
  • IPC Namespace隔离了某些IPC资源(interprocess community,进程间通信)使划分到不同IPC Namespace的进程组通信上隔离,⽆法通过消息队列、共享内存、信号量⽅式通信
  • PID Namespace隔离了进程ID号空间,不同的PID Namespace中的进程可以拥有相同的PID。PID Namespace的好处之⼀是,容器可以在主机之间迁移,同时容器内的进程保持相同的进程ID。PID命名空间还允许每个容器拥有⾃⼰的init(PID 1),它是 “所有进程的祖先”,负责管理各种系统初始化任务,并在⼦进程终⽌时收割孤⼉进程
  • Network Namespace提供了⽹络相关系统资源的隔离,因此,每个Network Namespace都有⾃⼰的⽹络设备、IP地址、IP路由表、/proc/net⽬录、端⼝号等。
  • User Namespace隔离了⽤户和组ID号空间,⼀个进程的⽤户和组ID在⽤户命名空间内外可以是不同的,⼀个进程可以在⽤户命名空间外拥有⼀个正常的⽆权限⽤户ID,同时在命名空间内拥有⼀个(root权限)的⽤户ID

命名空间查看

ls /proc/{PID}/ns

cgroup

cgroup全称是control groups被整合在了linux内核当中,把进程(tasks)放到组⾥⾯,对组设置权限,对进程进⾏控制。可以理解为⽤户和组的概念,⽤户会继承它所在组的权限。cgroups是linux内核中的机制,这种机制可以根据特定的⾏为把⼀系列的任务,⼦任务整合或者分离,按照资源划分的等级的不同,从⽽实现资源统⼀控制的框架,cgroup可以控制、限制、隔离进程所需要的物理资源,包括cpu、内存、IO,为容器虚拟化提供了最基本的保证,是构建docker⼀系列虚拟化的管理⼯具

解决如下问题

  • 资源控制:cgroup通过进程组对资源总额进⾏限制。如:程序使⽤内存时,要为程序设定可以使⽤主机的多少内存,也叫作限额
  • 优先级分配:使⽤硬件的权重值。当两个程序都需要进程读取cpu,哪个先哪个后,通过优先级来进⾏控制
  • 资源统计:可以统计硬件资源的⽤量,如:cpu、内存…使⽤了多⻓时间
  • 进程控制:可以对进程组实现挂起/恢复的操作,

cgroup设计到许多子系统,每种子系统可以进行不同的资源调控

1. cpu⼦系统:该⼦系统为每个进程组设置⼀个使⽤CPU的权重值,以此来管理进程对cpu的访
问。
2. cpuset⼦系统:对于多核cpu,该⼦系统可以设置进程组只能在指定的核上运⾏,并且还可以
设置进程组在指定的内存节点上申请内存。
3. cpuacct⼦系统:该⼦系统只⽤于⽣成当前进程组内的进程对cpu的使⽤报告
4. memory⼦系统:该⼦系统提供了以⻚⾯为单位对内存的访问,⽐如对进程组设置内存使⽤上
限等,同时可以⽣成内存资源报告
5. blkio⼦系统:该⼦系统⽤于限制每个块设备的输⼊输出。⾸先,与CPU⼦系统类似,该系统
通过为每个进程组设置权重来控制块设备对其的I/O时间;其次,该⼦系统也可以限制进程组
的I/O带宽以及IOPS
6. devices⼦系统:通过该⼦系统可以限制进程组对设备的访问,即该允许或禁⽌进程组对某设
备的访问
7. freezer⼦系统:该⼦系统可以使得进程组中的所有进程挂起
8. net-cls⼦系统:该⼦系统提供对⽹络带宽的访问限制,⽐如对发送带宽和接收带宽进程限制

运⾏⼀个docker容器,查看容器的cgroup 和 linux namespace

docker pull nginx
docker run -p 80:80 -d nginx

cd /sys/fs/cgroup //查看cgroup ⼦系统变化 并找到其对应的PID
cd /proc/{PID}/ns //查看命名空间

ps -ef | grep nginx

例如ps -ef |grep nginx可以看到有哪些nginx进程

[root@localhost cpu]# ps -ef| grep nginx
root     14976 14953  0 13:59 ?        00:00:00 nginx: master process nginx -g daemon off;
101      15010 14976  0 13:59 ?        00:00:00 nginx: worker process
101      15011 14976  0 13:59 ?        00:00:00 nginx: worker process

可以看到worker由master fork出来,那么看master是父进程是哪个,其实就是docker containerd shim 进程。

docker containerd shim 进程在宿主机中进程树大概是下面这样。属于docker进程组

docker核心原理——unionfs、namespace、cgroup_第2张图片

现在可以查看docker containerd shim 和 nginx master 和worker 的命名空间

#docker containerd shim 进程的ns
ll /proc/14953/ns
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 ipc -> ipc:[4026531839]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 net -> net:[4026531992]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 pid -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 pid_for_children -> pid:[4026531836]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 time -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 user -> user:[4026531837]
lrwxrwxrwx. 1 root root 0 Dec 12 14:10 uts -> uts:[4026531838]

ll /proc/14976/ns
#nginx master进程
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 ipc -> ipc:[4026532397]
lrwxrwxrwx. 1 root root 0 Dec 12 13:59 mnt -> mnt:[4026532395]
lrwxrwxrwx. 1 root root 0 Dec 12 13:59 net -> net:[4026532400]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 pid -> pid:[4026532398]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 pid_for_children -> pid:[4026532398]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 time -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 user -> user:[4026531837]
lrwxrwxrwx. 1 root root 0 Dec 12 14:12 uts -> uts:[4026532396]

#nginx worker进程
ll /proc/15010/ns
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 ipc -> ipc:[4026532397]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 mnt -> mnt:[4026532395]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 net -> net:[4026532400]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 pid -> pid:[4026532398]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 pid_for_children -> pid:[4026532398]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 time -> time:[4026531834]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 user -> user:[4026531837]
lrwxrwxrwx. 1 101 101 0 Dec 12 14:12 uts -> uts:[4026532396]

不难发现,worker和master的ns是一样的,而与docker containerd shim 进程 ns是不一样的。虽然都在宿主机中运行,但是由于ns不同,他们两个是隔离的。

同时可以在子系统下,根据对应pid查看其资源分配情况。不过docker需要手动限制,或者docker run启动的时候限制

docker run --memory 64m  -p 80:80 -d  nginx
# 查看对应资源分配
sudo cat /sys/fs/cgroup/memory/docker/<container_id or container_name>/memory.limit_in_bytes

不过笔者的cgroup下却没有docker目录,这个暂时还不知道为啥。查了一下可能是Docker 配置使用了不同的 cgroup 驱动程序。所以路径也有所不同。

查看容器详细信息,在里面也没发现cgroup路径,无奈只能进容器里看了。

docker inspect  b5ce5ac1e4ae
#
docker exec -it b5ce5ac1e4ae bash
cat /proc/self/cgroup
13:hugetlb:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
12:cpuset:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
11:memory:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
10:freezer:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
9:blkio:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
8:devices:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
7:rdma:/
6:cpu,cpuacct:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
5:pids:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
4:misc:/
3:net_cls,net_prio:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope
2:perf_event:/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope

# 这里就可以看到挂载了哪些进来。 这些地方是读写层,那么可以在对应宿主机(只读层)去查看即可,或者直接在docker里查看
# 退出来
cd /sys/fs/cgroup/memory/system.slice/docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope

[root@localhost docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope]# ls
cgroup.clone_children  memory.kmem.failcnt             memory.kmem.tcp.limit_in_bytes      memory.max_usage_in_bytes        memory.move_charge_at_immigrate  memory.stat            tasks
cgroup.event_control   memory.kmem.limit_in_bytes      memory.kmem.tcp.max_usage_in_bytes  memory.memsw.failcnt             memory.numa_stat                 memory.swappiness
cgroup.procs           memory.kmem.max_usage_in_bytes  memory.kmem.tcp.usage_in_bytes      memory.memsw.limit_in_bytes      memory.oom_control               memory.usage_in_bytes
memory.failcnt         memory.kmem.slabinfo            memory.kmem.usage_in_bytes          memory.memsw.max_usage_in_bytes  memory.pressure_level            memory.use_hierarchy
memory.force_empty     memory.kmem.tcp.failcnt         memory.limit_in_bytes               memory.memsw.usage_in_bytes      memory.soft_limit_in_bytes       notify_on_release
[root@localhost docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope]# cat memory.max_usage_in_bytes
14090240
[root@localhost docker-b5ce5ac1e4ae9b644fc8950eb8293077878a47b198c3a468738062d425fee312.scope]# cat memory.limit_in_bytes
67108864



正好是64m

你可能感兴趣的:(云原生,golang,服务器,docker,容器,云原生)