通过上节内容的学习，nerdctl在启动容器时连接的网络默认是bridge，除此之外还可以使用--net选项指定其他网络模式。
1--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网络开始吧。
...前面已经完成了rootless模式下buildkitd的二进制部署，本节将buildkitd部署到k8s集群中。 具体的环境信息k8s集群版本1.20.7，服务器系统CentOS 7.9，Jenkins Master通过使用kubernetes-plugin使运行job的jenkins slave(pod)在k8s集群上的jenkins namespace内动态创建。
...本节做一个实战的练习，使用buildkit完成容器镜像的远程构建，即实现本地的buildctl客户端远程请求服务器上的buildkitd完成一个容器镜像的构建并推送到镜像仓库中。
下面将在服务器上以二进制的形式部署服务端buildkitd，并将其gRPC API以TCP服务的形式暴露出来。 此处在部署buildkitd的时候是以具备生产环境可用为目的，为了安全性会以rootless的形式启动buildkitd，同时为gRPC Server和Client生成TLS证书，开启TLS认证以保障服务的安全。
...本节一起看一下都有哪些可用于构建容器镜像的工具和方案。可能你会疑问，构建镜像不就是使用docker build就可以吗，即使将来docker真的退出历史舞台，不还有containerd吗，前面第5节的时候也介绍了在containerd下可以使用nerdctl+buildkit构建容器镜像。
如果你只是在单机本地构建镜像的话，使用docker build或nerdctl+containerd+buildkit确实没有问题，但实际中由于不同场景和技术背景下的限制，如docker build依赖于docker daemon，这些限制使得在一些特殊的场景下本机构建镜像的方式不再可用。
前面学习了容器运行时containerd的基本使用，containerd的架构，namespace, cgroup, rootfs等容器背后的技术。 本节做一个阶段性的小节。此时，如果有人问"容器是什么?"，我们可能会给出以下的回答:
既然容器仅仅是一种特殊的进程，下面我们实际去探索一下它的存在。继续前面启动的redis容器为例，可以使用nerdctl inspect <container id>和ctr c info <container id>查看一下容器的信息。
下面的命令可以打印出容器在宿主机上的进程id:
前面我们简单理解了Containerd的架构，本节来看一下Containerd是如何存储镜像和容器的，涉及到内容包括如何镜像存储和RootFS。
Containerd的配置文件中有如下两项配置:
1root = /var/lib/containerd
2state = "/run/containerd"
root配置的目录是用来保存持久化数据的目录，包括content, snapshot, metadata和runtime。
下面在一台测试的服务器上，删除所有的镜像和容器后，再执行下面的命令重新初始化一下这些目录，以准备后边的实验。
最近跨网段配置k8s calico网络遇到了问题，简短记录一下解决过程。 测试环境本地的物理服务器上有一个k8s集群，版本是1.20，calico网络组件版本为3.17。 现在需要往这个k8s集群中添加2个新的node节点，新的节点在本地Openstack的虚拟机上。 Openstack虚拟机的网络和测试环境物理服务器之间网络已经打通，但属于不同的网段， 已在Openstack中安全组中配置了允许物理机服务器网段所有TCP协议进入。
...近日使用团队内部一直在维护的ansible role playbook初始化一个新的k8s集群(v1.19)时遇到了问题，kubectl get node命令显示各个节点一直是NotReady状态，同时各节点上的kubelet日志一直报下面的错误:
1... kubelet.go:2209] node "node1" not found
2... reflector.go:127] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.Node: failed to list *v1.Node: nodes "node1" is forbidden: User "system:node:node1" cannot list resource "nodes" in API group "" at the cluster scope
3... failed to ensure node lease exists, will retry in 7s, error: leases.coordination.k8s.io "node1" is forbidden: User "system:node:node1" cannot get resource "leases" in API group "coordination.k8s.io" in...mespace "kube-node-lease"
4... kubelet_node_status.go:470] Error updating node status, will retry: error getting node "node1": nodes "node1" is forbidden: User "system:node:node1" cannot get resource "nodes" in API group "" at the cluster scope
从日志中初步分析是kubelet对apiserver的访问权限问题引起，由于使用这个ansible role是团队内部一直在维护的，目前管理着线上线下共4套k8s集群，一直没有这个问题出现。于是初步怀疑已有的4套集群是经历了各个历史版本逐步升级到1.19的，这个过程中可能k8s给自动做了相关的配置兼容性， 现在初始化的这个新集群因为是全新安装，可能我们的ansible playbook生成的配置已经不正确了。
...前面我们从实际操作角度学习了containerd，部署了containerd，并学习使用了ctr, crictl, nerdctl等命令行工具，体验了容器镜像的构建、拉取、推送，容器的启动和管理，并结合containerd容器学习了容器隔离性和资源限制背后的技术namespace和cgroups。在积累了这些实际操作的经验之后，本节一起来从概念角度学习一下Containerd的架构，进一步加深理解。本节学习内容主要来自Containerd的官方文档Containerd Architecture。
...