通过前面14~22节内容，结合Containerd学习了容器网络的一些基础知识，包括容器网络接口CNI以及Calico网络方案的一些内容。 从本节将学习容器持久化存储的相关知识。 容器的本质是一种特殊的进程，它使用namespace进行隔离，使用cgroup进行资源限制，并且以联合文件系统的形式挂载了单独的rootfs。 Containerd默认配置的snapshotter是overlayfs，overlayfs是联合文件系统的一种实现，overlayfs将只读的镜像层成为lowerdir，将读写的容器层成为upperdir，最后联合挂载呈现出mergedir。 容器中新写入的文件默认存储在容器的执行层，当容器被删除时，这些数据也就丢失了。如果想要在容器被删除后保留之前创建的文件，就需要将文件保存在宿主机上。
通过前面2节完成了calico node集群的二进制部署，并在集群各个节点上部署calico cni插件，测试了calico cni插件与containerd的集成。 本节将学习Calico网络的一些基本概念。 Calico Node的核心组件 Calico是一个纯三层的虚拟网络，Calico为每个容器分配一个ip，每个宿主机(Calico Node)都是一个虚拟路由器，将不同宿主机的容器连接起来，实现容器间跨主机通信。
前面一节完成了calico node集群的部署，本节将在各个节点上部署calico cni插件， 并在两个主机节点上各启动一个连接到calico网络的containerd容器，测试两个容器网络是否是打通的。 部署容器运行时Containerd和CNI 在各个服务器节点上安装容器运行时Containerd。
前面几节内容学习了容器网络接口CNI及CNI规范的一些基础知识，从本节开始学习开源虚拟网络方案Calico。 Calico是一个可用于容器、虚拟机和本机主机工作负载的开源网络和网络安全解决方案。 Calico支持广泛的平台，包括Kubernetes, OpenShift, Docker EE, OpenStack和裸金属服务。 Calico同时实现并提供了calico网络CNI插件，因此可以将Calico用作容器网络插件。 本文将回到原始时代，从零开始纯手工以二进制形式部署Calico，这样能先从整体上理解Calico的各个组件。
前面学习了CNI为容器网络创建定义的配置格式及基本的操作执行流程。 本节将从源码加深对CNI接口的理解。 CNI项目https://github.com/containernetworking/cni的libcni下包含CNI接口，供容器运行时调用，转发调用具体的CNI插件。 libcni.CNI就是具体的go语言的接口，源码如下：
容器运行时在调用CNI插件创建容器网络时，CNI插件需要为容器网络接口分配和维护一个IP地址，并配置该网络接口所需要的路由，着给了CNI插件很大的灵活性，但也给它们带来了很大负担。 许多CNI插件需要重复编写相同的代码来支持用户可能需求的集中IP管理方案(如:dhcp, host-local)。为了减轻第三方CNI插件的编写负担，将IP管理功能独立出来，CNI规范定义了第二种插件类型 IP Address Management插件(IPAM插件)。这样，CNI插件就可以在执行过程中需要的时候直接调用相应的IPAM插件，由IPAM插件负责确定IP/子网、网关、路由并将这些信息返回到主CNI插件中。 IPAM插件可以从协议(例如DHCP)、本地文件系统存储的数据、网络配置文件中的ipam，或者以上这些方式的组合中来获取IP/子网、网关、路由等信息。
本节来学习CNI的网络配置。 CNI网络配置(Network Configuration) CNI的网络配置是JSON格式的，可以是存储在磁盘中的文件，也可以由容器运行时以其他方式生成。 下面是cni json配置文件中的一些重要字段: cniVersion(string): 描述cni配置遵循的cni规范版本(版本号为语义化版本,如0.4.0) name(string): 表示network name，在主机(或其他管理域)上的所有容器中应该是唯一的 type(string): 表示cni插件的可执行文件名 args(dictionary, optional): 由容器运行时提供的可选参数。例如，可以通过将标签添加到args下的标签字段，将标签字典传递给CNI插件 ipMasq(boolean, optional): 如果插件支持此字段，将为这个网络上的主机设置一个ip伪装(ip masquerade)。如果主机将充当分配给容器的子网的网管，那么这个配置字段是必须的 ipam(boolean, optional): 包含具体IPAM(IP地址管理)值的键值对 type(string) 表示ipam插件的可执行文件名，如dhscp, host-local, static dns(dictionary, optional): 包含具体DNS配置的键值对 nameservers(list of strings, optional): 一个对配置网络可见的按优先级顺序排列的dns服务器列表，列表中的每个值是一个IPV4或IPV6的字符串 domain(string, optional): 用于短主机名查找的本地域名 search(list of strings, optional): 用于短主机名查找的优先级排序搜索域列表，被大多数解析器(resolver)在解析时优先于domain options (list of strings, optional): 一组可以传递给解析器(resolver)的选项值 cni网络的JSON配置除了上面这些标准字段外，某个具体的插件还可以定义自己的附加字段，但如果配置了插件未定义的字段将会报错。args中配置的附加字段可以用来传递任意数据，如果插件不认识args中传递的字段，将会直接忽略而不会报错。
CNI(容器网络接口)是云原生计算基金会(CNCF)的一个项目，它定义了一个规范，同时提供了一个Go语言的库(Library），用于开发在Linux容器中配置网络接口的插件，CNI项目还内置提供了一系列受支持的插件。 CNI只关心容器创建时的网络分配，以及当容器被删除时已经分配网络资源的释放。 CNI作为容器网络的标准，使得各个容器管理平台可以通过相同的接口调用各种各样的网络插件来为容器配置网络。
通过上节内容的学习，nerdctl在启动容器时连接的网络默认是bridge，除此之外还可以使用--net选项指定其他网络模式。 --network value, --net value Connect a container to a network ("bridge"|"host"|"none") (default: "bridge") 从nerdctl命令的帮助中给出了使用--net选项指定启动容器时连接的网络，默认是brdige，另外还可以选择none和host。 因为容器连接的网络是由CNI插件实现的，所以除了bridge, host, none这3个选项外，还可以指定手动添加的CNI配置。 下面分别看一下这几种不同的网络。
从本节开始学习容器网络，根据前面已经学习过的内容，单机模式下使用容器的最佳组合是nerdctl+containerd+buildkit，这套组合已经可以在本地开发、测试和单机容器部署方面替代docker了。关于容器网络的学习，就先从nerdctl启动容器的创建的brdige网络开始吧。