前面我们提到过容器两大核心技术——Namespace和Cgroup，这篇分享将使用这些底层原理带着大家直观感受一下容器的玩法。需要说明的是，前几篇关于容器化技术的分享只是开胃菜，说白了，就是想替同学们扫清一些学习障碍，更多相关知识点请自行查阅官方文档。
Linux Namespace 有如下种类：
注意，后面的模拟代码会用到相关的系统调用参数！
与 Linux Namespace 相关的系统调用如下：
Fancy的技术博客
/，即以根（root）开始的，而在使用chroot之后，系统的目录结构将以指定的位置作为 / 位置
pivot_root 系统调用，如果系统不支持，才会使用chrootdockerinit 需要在容器内完成一系列初始化操作，比如完成根目录的准备、挂载设备和目录、配置 hostname 等注意，后面的模拟代码会用到相关的系统调用！
一个最常见的 rootfs，或者说容器镜像，会包括如下所示的目录：
因为我们只是模拟，所以只创建几个目录：
拷贝命令到新创建的bin目录：
注意，还需要把命令依赖的so文件拷贝到lib目录，查找so文件需要用到 ldd 命令：
还有些文件我们不希望写死在镜像中，如下图所示：
因此，我们在rootfs外面再创建一个conf目录，把上面3个文件放进去，然后把这个conf目录mount进容器，具体操作看后面的代码。
关于mount再多说一嘴，其主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。
简单来说，绑定挂载实际上是一个inode（不清楚inode是啥的自行google吧）替换的过程，如下图所示：
最后一步，执行chroot命令，告诉操作系统，我们将使用 $HOME/test 目录作为 /bin/bash 进程的根目录：
这个挂载在容器根目录上，用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。至于很多同学都知道的 UnionFS，说白了，就是基于旧的rootfs以增量的方式来维护而已。
有兴趣的同学可以用下面的代码再来模拟一遍Docker：
容器有自己的 Network Namespace 和与之对应的网络接口eth0，宿主机上也有自己的eth0，而宿主机上的eth0对应着真正的物理网卡，也就是说，宿主机上的eth0才可以和外面通讯。那么容器是怎么跟外面通讯的呢？
如上图所示，要解决容器与外面通讯需要解决两个问题：
veth 方案，至于 macvlan/ipvlan 会简单提一下首先，启动一个不带网络配置的容器：
找到这个容器进程的pid：
通过 /proc/$pid/ns/net 这个文件得到容器 Network Namespace 的ID，然后在 /var/run/netns/ 目录下建立一个符号链接，指向这个容器的 Network Namespace：
完成这步操作之后，在后面的 ip netns 操作里，就可以用pid的值作为这个容器的 Network Namesapce 的标识了。
接下来，用 ip link 命令来建立一对veth的虚拟设备接口，分别是veth_container和veth_host：
把veth_container这个接口放入到容器的 Network Namespace 中：
把veth_container重新命名为eth0，因为这时候接口已经在容器的 Network Namesapce 里了，所以不会和宿主机上的eth0命名冲突：
接着对容器内的eth0做基本的网络IP和缺省路由配置：
完成这一步，就解决了让数据包从容器的 Network Namespace 发送到宿主机的 Network Namespace 上的问题，如下图所示：
将veth_host这个设备接入到docker0这个bridge上：
至此，容器和docker0组成了一个子网，docker0上的IP就是这个子网的网关IP，如下图所示：
要让子网可以通过宿主机上eth0去访问外网，还需要添加下面的iptables规则：
最终的veth网络配置如下图所示：
最后测试一下是否能ping通外网：
如果发现ping不通，先检查下是否打开IP转发功能：
这里简单提一嘴 macvlan/ipvlan 方案：对于macvlan，每个虚拟网络接口都有自己独立的mac地址；而ipvlan的虚拟网络接口是和物理网络接口共享同一个mac地址。同时它们都有自己的 L2/L3 的配置方式。有兴趣的同学可以按照如下步骤为容器手动配置上ipvlan的网络接口：
docker run --init --name ipvlan-test --network none -d busybox sleep 36000
pid1=$(docker inspect ipvlan-test | grep -i Pid | head -n 1 | awk '{print $2}' | awk -F "," '{print $1}')
echo $pid1
ln -s /proc/$pid1/ns/net /var/run/netns/$pid1
ip link add link eth0 ipvt1 type ipvlan mode l2
ip link set dev ipvt1 netns $pid1
ip netns exec $pid1 ip link set ipvt1 name eth0
ip netns exec $pid1 ip addr add 172.17.3.2/16 dev eth0
ip netns exec $pid1 ip link set eth0 up
完成上面的操作后，ipvlan网络二层的连接如下图所示：
前面几篇分享简单提到过容器网络相关内容，出门右转看 容器网络性能分析 和 浅析容器跨主机通信，有兴趣的同学可以再深入思考下Kubernetes相关的网络问题：
使用Cgroup可以根据具体情况来控制系统资源的分配、优先顺序、拒绝、管理和监控，提高总体效率。
下面列举的是 Cgroup V1 相关子系统：
Linux Cgroups 给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织在操作系统的 /sys/fs/cgroup 路径下，可以通过 mount 命令查看：
如果没有看到上述目录，可以自行做mount，如下所示：
mkdir cgroup
mount -t tmpfs cgroup_root ./cgroup
mkdir cgroup/cpuset
mount -t cgroup -ocpuset cpuset ./cgroup/cpuset/
mkdir cgroup/cpu
mount -t cgroup -ocpu cpu ./cgroup/cpu/
mkdir cgroup/memory
mount -t cgroup -omemory memory ./cgroup/memory/
一旦mount成功，那些mount的目录下面就会有很多相关文件，如下图所示：
在使用 CPU Cgroup 前，先介绍三个重要的参数：
了解了上面的参数，那么应该能看懂下面这条docker命令：
接下来，我们使用原生的Cgroup来实现上面的命令。
首先，创建一个 CPU Cgroup：
设置 cpu.cfs_quota_us 为 20000：
查看当前Shell进程的PID：
然后，在bash中启动一个死循环来消耗cpu，正常情况下应该使用100%的CPU，即消耗一个内核：
将这个测试Shell进程的PID加入 CPU Cgroup：
加入之后可以看到CPU使用率降到了20%：
关于Kubernetes的CPU限制出门右转看 Kubernetes资源limits和requests的栗子。
在 容器IO性能分析 中提到过Cgroup有V1和V2两个版本，V1版本中的 blkio Cgroup 只能限制 Direct IO，不能限制 Buffered IO。
这是因为 Buffered IO 会把数据先写入到内存 Page Cache 中，然后由内核线程把数据写入磁盘，而 Cgroup V1 的子系统都是独立的，即 Cgroup V1 blkio 的子系统是独立于 memory 子系，所以无法统计到由 Page Cache 刷入到磁盘的数据量。
这个 Buffered IO 无法被限速的问题，在 Cgroup V2 里被解决了。Cgroup V2 从架构上允许一个控制组里有多个子系统协同运行，这样在一个控制组里只要同时有 io 和 memory 子系统，就可以对 Buffered IO 作磁盘读写的限速，如下图所示：
虽然 Cgroup V2 能解决 Buffered IO 磁盘读写限速的问题，但是目前 runC、containerd以及Kubernetes都是刚刚开始支持 Cgroup V2，所以还需要等待一段时间。
骚年，都看到最后了，不晓得你是否慢慢找到了学习容器的赶脚，更多好玩的有趣的内容敬请期待下篇分享！