前面我们从实际操作角度学习了containerd，部署了containerd，并学习使用了ctr, crictl, nerdctl等命令行工具，体验了容器镜像的构建、拉取、推送，容器的启动和管理，并结合containerd容器学习了容器隔离性和资源限制背后的技术namespace和cgroups。在积累了这些实际操作的经验之后，本节一起来从概念角度学习一下Containerd的架构，进一步加深理解。本节学习内容主要来自Containerd的官方文档Containerd Architecture。
go-elasticsearch是ES官方提供的Go语言客户端。本文将结合ES 7.12对这个库做一个基本入门使用的演示。 1.开发环境准备 创建一个空的项目，并使用go moudles引入go-elasticsearch的依赖: mkdir go-es-showcase cd go-es-showcase go mod init go-es-showcase export GOPROXY="https://goproxy.io" go get github.com/elastic/go-elasticsearch/[email protected] go get github.com/stretchr/testify 这里基于go testing单元测试编码风格来演示对go-elasticsearch这个库的使用。 首先在项目的根目录下创建一个名称为go_esclient_test.go，并演示一下如何创建客户端:
ES为提供了一套HTTP RESTful API，开发和运维人员可以直接调用这些API来配置和访问ES服务。 这些API的功能十分丰富，从集群监控、运维管理到应用开发所需的索引、文档相关操作。本文将从应用开发的角度整理ES应用开发人员应该熟练掌握的API。 1.索引的创建、修改和删除 创建索引PUT /<index-name>，例:
本节我们一起来了解一下容器资源隔离性技术namespace。 namespace即命名空间，主要用来做访问隔离，针对一类资源进行抽象封装给一个容器使用，对于这类资源，每个容器都有自己的抽象，它们之间彼此不可见实现了访问隔离，例如PID namespace用来隔离进程号，User namespace用来隔离用户和用户组。
本节我们一起来了解一下容器的资源限制技术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才正式稳定可用。
1.容器核心技术和Docker的创新:镜像技术 容器技术主要包括Cgroup和Namesapce这两个内核级别的特性。 Cgroup是control group的缩写即控制组，主要用来做资源控制，可以将一组进程放到一个控制组里，通过给这个控制组分配可用资源，达到控制这组进程可用资源的目的，对不同资源的具体管理是由各个子系统分工完成的，例如cpu控制cpu使用率，memory控制内存的使用上限等等。 Namespace即命名空间，主要用来做访问隔离，针对一类资源进行抽象封装给一个容器使用，对于这类资源，每个容器都有自己的抽象，它们之间彼此不可见实现了访问隔离，例如PID namespace用来隔离进程号，User namespace用来隔离用户和用户组，linux共有6种命名空间。 另外，容器还需要rootfs实现文件系统隔离。rootfs是一个容器启动时其内部进程可见的文件系统，在容器内用户视角下修改文件时，一般会采用Copy-On-Write(COW)机制。镜像的本质就是一个rootfs。
对于用惯了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的辉煌已经远去了。
在第2节中，我们部署了containerd，配置好了ctr和crictl这两个命令行工具，并且使用ctr启动了一个用于测试的redis容器，但是这个容器还不具备网络能力，只能在容器内部自己玩耍。 本节我们将尝试手工配置containerd与cni插件的集成，为容器加入基本的网络能力。
1.Containerd启动容器涉及的模块 前面我们梳理了docker、k8s、containerd、runc之间的渊源，Containerd早已脱离Docker成为了一个稳定可靠的容器运行时。 单从containerd的角度来看启动一个容器的过程大致是下图所示的流程: containerd-run-container-1.png 我们可以使用Containerd的命令行工具ctr来启动一个容器，也可以在我们的应用中编写客户端程序为我们的应用加入启动容器的功能。
话说Kubernetes都要弃用Dockershim了，因此是时候学习Containerd了。 本文先简单整理一下Kubernetes、Docker、Containerd之间的渊源和纠葛。 1.Docker, OCI和Containerd 这里略过早期Docker的发展历史，大概就是在docker如日中天的时候，社区要搞容器化标准，成立了OCI(Open Container Initiaiv)，OCI主要包含两个规范，一个是容器运行时规范(runtime-spec)，一个是容器镜像规范(image-spec)。 docker的公司也在OCI中，这里略过在推动标准化过程中各大厂各自心里的"小算盘"和"利益考虑"，docker在这个过程中由一个庞然大物逐渐拆分出了containerd、runc等项目， docker公司将runc捐赠给了OCI，后来将containerd捐赠给了CNCF。