重学容器16: 容器网络接口CNI简介
CNI(容器网络接口)是云原生计算基金会(CNCF)的一个项目，它定义了一个规范，同时提供了一个Go语言的库(Library），用于开发在Linux容器中配置网络接口的插件，CNI项目还内置提供了一系列受支持的插件。 CNI只关心容器创建时的网络分配，以及当容器被删除时已经分配网络资源的释放。 CNI作为容器网络的标准，使得各个容器管理平台可以通过相同的接口调用各种各样的网络插件来为容器配置网络。
重学容器15: nerdctl创建容器时指定容器连接的网络
通过上节内容的学习，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配置。 下面分别看一下这几种不同的网络。
重学容器14: 初识容器网络之bridge
从本节开始学习容器网络，根据前面已经学习过的内容，单机模式下使用容器的最佳组合是nerdctl+containerd+buildkit，这套组合已经可以在本地开发、测试和单机容器部署方面替代docker了。关于容器网络的学习，就先从nerdctl启动容器的创建的brdige网络开始吧。
重学容器13: 在k8s集群上部署buildkit
前面已经完成了rootless模式下buildkitd的二进制部署，本节将buildkitd部署到k8s集群中。 具体的环境信息k8s集群版本1.20.7，服务器系统CentOS 7.9，Jenkins Master通过使用kubernetes-plugin使运行job的jenkins slave(pod)在k8s集群上的jenkins namespace内动态创建。
重学容器12: 使用buildkit实现容器镜像的远程构建
本节做一个实战的练习，使用buildkit完成容器镜像的远程构建，即实现本地的buildctl客户端远程请求服务器上的buildkitd完成一个容器镜像的构建并推送到镜像仓库中。 部署buildkitd服务端, 暴露为TCP服务 下面将在服务器上以二进制的形式部署服务端buildkitd，并将其gRPC API以TCP服务的形式暴露出来。 此处在部署buildkitd的时候是以具备生产环境可用为目的，为了安全性会以rootless的形式启动buildkitd，同时为gRPC Server和Client生成TLS证书，开启TLS认证以保障服务的安全。
重学容器11: 容器镜像构建工具和方案介绍
本节一起看一下都有哪些可用于构建容器镜像的工具和方案。可能你会疑问，构建镜像不就是使用docker build就可以吗，即使将来docker真的退出历史舞台，不还有containerd吗，前面第5节的时候也介绍了在containerd下可以使用nerdctl+buildkit构建容器镜像。 如果你只是在单机本地构建镜像的话，使用docker build或nerdctl+containerd+buildkit确实没有问题，但实际中由于不同场景和技术背景下的限制，如docker build依赖于docker daemon，这些限制使得在一些特殊的场景下本机构建镜像的方式不再可用。
重学容器10: 容器仅仅是一种特殊的进程
前面学习了容器运行时containerd的基本使用，containerd的架构，namespace, cgroup, rootfs等容器背后的技术。 本节做一个阶段性的小节。此时，如果有人问"容器是什么?"，我们可能会给出以下的回答: 容器实际上是一种特殊的进程。它使用namespace进行隔离，使用cgroup进行资源限制，并且它还以联合文件系统的形式挂载了单独的rootfs。 为了更方便的准备运行容器所需的资源和管理容器的生命周期，还需要容器引擎如containerd。 容器镜像实际上就是一种特殊的文件系统，它包含容器运行所需的程序、库、资源配置等所有内容，构建后内容保持不变。在启动容器时镜像会挂载为容器的rootfs。 既然容器仅仅是一种特殊的进程，下面我们实际去探索一下它的存在。继续前面启动的redis容器为例，可以使用nerdctl inspect <container id>和ctr c info <container id>查看一下容器的信息。 下面的命令可以打印出容器在宿主机上的进程id:
重学容器09: Containerd是如何存储容器镜像和数据的
前面我们简单理解了Containerd的架构，本节来看一下Containerd是如何存储镜像和容器的，涉及到内容包括如何镜像存储和RootFS。 从pull镜像到启动容器 Containerd的配置文件中有如下两项配置: root = /var/lib/containerd state = "/run/containerd" root配置的目录是用来保存持久化数据的目录，包括content, snapshot, metadata和runtime。 下面在一台测试的服务器上，删除所有的镜像和容器后，再执行下面的命令重新初始化一下这些目录，以准备后边的实验。
Kubernetes Calico网络在OpenStack上的安全组配置
最近跨网段配置k8s calico网络遇到了问题，简短记录一下解决过程。 测试环境本地的物理服务器上有一个k8s集群，版本是1.20，calico网络组件版本为3.17。 现在需要往这个k8s集群中添加2个新的node节点，新的节点在本地Openstack的虚拟机上。 Openstack虚拟机的网络和测试环境物理服务器之间网络已经打通，但属于不同的网段， 已在Openstack中安全组中配置了允许物理机服务器网段所有TCP协议进入。
kubernetes apiserver的node鉴权
起因 近日使用团队内部一直在维护的ansible role playbook初始化一个新的k8s集群(v1.19)时遇到了问题，kubectl get node命令显示各个节点一直是NotReady状态，同时各节点上的kubelet日志一直报下面的错误: ... kubelet.go:2209] node "node1" not found ... 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 ... 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" ... 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生成的配置已经不正确了。