青蛙小白

#Containerd

← 全部文章

重学容器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。 下面在一台测试的服务器上，删除所有的镜像和容器后，再执行下面的命令重新初始化一下这些目录，以准备后边的实验。

重学容器08: 简单理解Containerd的架构

前面我们从实际操作角度学习了containerd，部署了containerd，并学习使用了ctr, crictl, nerdctl等命令行工具，体验了容器镜像的构建、拉取、推送，容器的启动和管理，并结合containerd容器学习了容器隔离性和资源限制背后的技术namespace和cgroups。在积累了这些实际操作的经验之后，本节一起来从概念角度学习一下Containerd的架构，进一步加深理解。本节学习内容主要来自Containerd的官方文档Containerd Architecture。

重学容器06: 容器资源限制背后的技术cgroups

本节我们一起来了解一下容器的资源限制技术CGroups。CGroups即Linux Control Group其作用是限制一组进程可以使用的资源上限(CPU、内存等)。 1.CGroups的基本概念 学习CGroup需要先了解几个CGroup的基本概念: Task: 在cgroup中，task可以理解为一个进程，但这里的进程和一般意义上的OS进程不太一样，实际上是进程ID和线程ID列表，后边再讨论 CGroup: 即控制组。一个控制组就是一组按照某种标准划分的Tasks。可以理解为资源限制是以进程组为单位实现的，一个进程加入到某个控制组后，就会受到相应配置的资源限制。 Hierarchy: cgroup的层级组织关系，cgroup以树形层级组织，每个cgroup子节点默认继承其父cgroup节点的配置属性。这样每个Hierarchy在初始化会有root cgroup Subsystem: 即子系统，更准确的表述应该是资源控制器(Resource Controller)更合适一些。子系统表示具体的资源配置，如CPU使用，内存占用等。Subsystem附加到Hierarchy上后可用。 当前的cgroup有两个版本v1和v2，据说是随着越来越多的特性被加入导致cgroups v1变得难以维护，从linux kernel 3.1开始了cgroups v2的开发，v2到linux kernel4.5才正式稳定可用。

重学容器05: 使用nerdctl + buildkitd构建容器镜像

1.容器核心技术和Docker的创新:镜像技术 容器技术主要包括Cgroup和Namesapce这两个内核级别的特性。 Cgroup是control group的缩写即控制组，主要用来做资源控制，可以将一组进程放到一个控制组里，通过给这个控制组分配可用资源，达到控制这组进程可用资源的目的，对不同资源的具体管理是由各个子系统分工完成的，例如cpu控制cpu使用率，memory控制内存的使用上限等等。 Namespace即命名空间，主要用来做访问隔离，针对一类资源进行抽象封装给一个容器使用，对于这类资源，每个容器都有自己的抽象，它们之间彼此不可见实现了访问隔离，例如PID namespace用来隔离进程号，User namespace用来隔离用户和用户组，linux共有6种命名空间。 另外，容器还需要rootfs实现文件系统隔离。rootfs是一个容器启动时其内部进程可见的文件系统，在容器内用户视角下修改文件时，一般会采用Copy-On-Write(COW)机制。镜像的本质就是一个rootfs。

重学容器04: containerd的高阶命令行工具nerdctl

对于用惯了docker cli的用户来说，containerd的命令行工具ctr使用起来不是很顺手，此时别慌，还有另外一个命令行工具项目nerdctl可供我们选择。 nerdctl是一个与docker cli风格兼容的containerd的cli工具。 nerdctl已经作为子项目加入了containerd项目，它的github地址是https://github.com/containerd/nerdctl，而且从最近的nerdctl 0.8开始，nerdctl直接兼容了docker compose的语法(不包含swarm)， 这很大提高了直接将containerd作为本地开发、测试和单机容器部署使用的体验。本来k8s后续将不再支持dockershim，docker在k8s社区的地位急剧下降，现在单机直接使用containerd易用性也不断被完善，也许docker的辉煌已经远去了。