Docker 容器介绍

1. 简介

1.1 容器和VM

什么是容器：

• 一种操作系统级别的虚拟化的方案
• 只能运行相同或相似内核的操作系统
• 依赖Linux内核特性：Namespace和Cgroups

1.2 依赖内核特性

• Namespaces：命名空间，容器的独立资源

  • Mount
  • PID
  • Net
  • IPC
  • UTS: Unix Time-Sharing, allow a single system to appear to have different host and domain names to different processes.
  • User

• Cgroups：控制组

  • 资源限制：对进程组使用的资源总额进行限制。例如设定应用运行时的内存上限，当超过该限额就会 OOM(Out of Memory)

  • 优先级分配：通过分配CPU时间片数量、硬盘IO及带宽大小来控制进程的优先级

  • 资源统计：统计系统的资源使用量，如CPU使用量，内存用量等

  • 进程控制：可以对进程组执行挂起、恢复等操作

1.3 分层文件系统

层状文件系统，当进程需要修改文件时，AUFS创建该文件的一个副本

• aufs: ubuntu, 未合入内核
• devicemapper (dm): centos, 性能差
• overlay: 合入内核，当前主流

镜像：多个镜像层 (Image Layer) 叠加而成的只读文件系统 (UnionFile System)

• bootfs：最底层文件系统，用于系统引导，包含bootloader和kernel，容器启动后会被卸载以节约内存资源
• rootfs：位于bootfs之上，为容器的根文件系统
  • 传统模式：系统启动时，内核以“只读”模式挂载rootfs，完整性自检后，再重新挂载为“读写”模式
  • docker：rootfs由内核挂载为“只读”模式，而后通过“联合挂载”技术额外挂载一个“可写”层

容器：在镜像的基础上，增加了一个读写层 (Top Layer)。运行状态下的容器，由一个可读写的文件系统、隔离的进程空间和进程构成

2. Docker

Docker 使用 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 OverlayFS 类的 Union FS 等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 0.7 版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 1.11 版本开始，则进一步演进为使用 runC 和 containerd

2.1 启动容器

docker        ctr(独立于docker时)
 |             |
 V             V
 dockerd -> containerd ---> shim -> runc -> runc init -> process
                      |-- > shim -> runc -> runc init -> process
                      +-- > shim -> runc -> runc init -> process

组件通信流程：

• dockerd：docker engine的守护进程
• containerd：由dockerd启动的子进程，它们之间通过RPC进行通信
• containerd-shim：被containerd拉起后，start/exec/create拉起runC进程，通过exit、control文件和containerd通信，通过父子进程关系和SIGCHLD监控容器中进程状态
• runC：真正用户想启动的进程，由runc的init进程启动，即runc init [args …]
• 在整个容器生命周期中，containerd通过epoll 监控容器文件，监控容器的OOM等事件

2.2 Containerd

Containerd 标准化的产物，主要负责：

• 管理容器的生命周期(从创建到销毁)
• 拉取/推送容器镜像
• 存储管理(管理镜像及容器数据的存储)
• 调用 runC 等容器运行时
• 管理容器网络

Containerd 标准化：

• 彻底从docker引擎中分离
• 可被 Kubernetes CRI 等项目直接调用
• 当 containerd 和 runC 成为标准化容器服务的基石后，上层应用可以直接建立在 containerd 和 runC 之上。

Containerd 架构：

• 被设计成 snapshotter 的模式，这也使得它对于 overlay 文件系、snapshot 文件系统的支持比较好。
• storage、metadata 和 runtime 的三大块划分非常清晰，通过抽象出 events 的设计，网络层面的复杂度交给了上层处理，仅提供 network namespace 相关的一些接口添加和配置 API。这样保留最小功能集合的纯粹和高效，将更多的复杂性及灵活性交给了插件及上层系统。

2.3 Containerd-shim

• 允许 runC 在启动容器之后退出，即不必为每个容器一直运行一个容器运行时
• 即使 containerd 和 dockerd 都挂掉，容器的标准 IO 和其它的文件描述符也都是可用的
• 向 containerd 报告容器的退出状态

2.4 RunC

runC 是标准化的产物，它根据 OCI 标准来创建和运行容器。

RunC 默认要支持 seccomp ( secure computing mode，即安全计算模型)，编译时，先安装 libseccomp-dev

容器的状态转移：

3. 标准化

3.1 CRI

Container Runtime Interface (CRI), it defines an API between Kubernetes and the container runtime

• containerd: it is a high-level container runtime that came from Docker, and implements the CRI spec. It pulls images from registries, manages them and then hands over to a lower-level runtime, which actually creates and runs the container processes.

• CRI-O: it is another high-level container runtime which implements the Container Runtime Interface (CRI). It’s an alternative to containerd. It pulls container images from registries, manages them on disk, and launches a lower-level runtime to run container processes. It was born out of Red Hat, IBM, Intel, SUSE and others.

总结：CRI 是 K8S 调用 容器的 API 接口

3.2 OCI

Open Container Initiative (OCI), it is a group of tech companies who maintain a specification for the container image format, and how containers should be run.

• runc: it is an OCI-compatible container runtime. It implements the OCI specification and runs the container processes。runc provides all of the low-level functionality for containers, interacting with existing low-level Linux features, like namespaces and control groups. It uses these features to create and run container processes.
• crun: a container runtime written in C (by contrast, runc is written in Go.)
• kata-runtime: from the Katacontainers project, which implements the OCI specification as individual lightweight VMs (hardware virtualisation)
• gVisor: from Google, which creates containers that have their own kernel. It implements OCI in its runtime called runsc.

总结：OCI 规定容器镜像格式和容器运行的标准

3.3 Docker-shim

k8s 调用 docker：

kubelet：k8s 容器管理组件，负责对容器的创建、删除等调度行为的管理

docker-shim：kubelet和dockerd交互的中间接口。docker-shim 提供了一个标准接口，让kubelet能够专注于容器调度逻辑本身，而不用去适配 dockerd 接口变动。而其他实现了相同标准接口的容器技术也可以被kubelet集成使用，这个接口称作CRI。docker-shim 是对 CRI 接口调用 dockerd 的一种实现， docker-shim 并不是docker技术的一部分，而是k8s系统的一部分。

k8s 1.20+ 默认不再使用dockershim，并将在后续版本中删除dockershim，这意味着kubelet不再通过dockerd操作容器。在新架构中，kubelet直接与containerd交互，跳过了dockershim和dockerd这两个步骤。

cri-containerd：在k8s和containerd的适配过程中，还曾经出现过cri-containerd这个组件。在containerd1.0版本中，containerd提供了cri-containerd作为独立进程来实现CRI接口，其定位和docker-shim类似。但在containerd1.1版本中，就将这个功能改写成了插件形式直接集成到了containerd进程内部，使containerd可以直接支持CRI接口，cri-containerd也被合入了containerd，作为其一个内置插件包存在。

4. Podman

Podman主要由红帽发起和推动，原来是 CRI-O 项目的一部分，后来被分离成一个单独的项目叫 libpod。其包括如下三个模块：

• Podman：运行容器，简单粗暴直接操作 runC
• Skopeo：用于对容器镜像和镜像库执行各种操作，支持使用 OCI 镜像与原始的 Docker v2 镜像。支持不同镜像库同步等操作
• Buildah：构建OCI镜像， 它复制了Dockerfile的所有命令。可以直接使用Dockerfiles构建镜像，并且不需要任何root权限

Podman 的不足：因为没有类似 docker daemon 守护进程，所以不支持 --restart 策略，不过使用 k8s 编排就不存在这个问题。

Podman 兼容大部分 Docker 命令，可配置简单

yum install podman
podman –version

alias docker=podman

# podman 网桥
ip addr show cni-podman0

5. 补充

LXC：LinuX Containers ，它是一个加强版的Chroot。其作用是将不同的应用隔离开来，有点类似于chroot，chroot是将应用隔离到一个虚拟的私有root下，而LXC在这之上更进了一步。LXC依赖 Kernel 的3种隔离机制(isolation infrastructure)：Chroot、Cgroups、Namespaces。LXC提供一个共享kernel的OS级虚拟化方法，在执行时不用重复加载kernel，且conatiner的kernel与host共享，因此大大加快了container的启动过程，并显著减少了内存消耗。

libcontainer：docker0.9 开发了 libcontainer 模块来作为 LXC 的替代品实现容器底层特性，并在1.10版本彻底去除了LXC。在1.11版本拆分出runc后，libcontainer 也随之成为了runc的核心功能模块。

moby：docker公司发起的开源项目，其中最主要的部分就是同名组件moby，事实上这个moby就是dockerd目前使用的开源项目名称，docker项目中的engine（dockerd）仓库现在就是从moby仓库fork而来的。

docker-ce：docker的开源版本，CE指Community Edition。docker-ce中的组件来自于moby、containerd等其他项目。

docker-ee：docker的收费版本，EE指Enterprise Edition。

rkt与rktlet：CoreOS公司主导的容器技术，在早期得到了k8s的支持成为k8s集成的两种容器技术之一。随着CRI接口的提出，k8s团队也为rkt提供了rktlet模块用于与rkt交互，rktlet和dockersim的意义基本相同。随着CoreOS被Redhat收购，rkt已经停止了研发，rktlet已停止维护了。

CRI-O：Redhat公司推出的容器技术。从名字就能看出CRI-O的出发点就是一种原生支持CRI接口规范的容器技术。CRI-O同时兼容OCI接口和docker镜像格式。CRI-O的设计目标和特点在于它是一项轻量级的技术，k8s可以通过使用CRI-O来调用不同的底层容器运行时模块，例如runc。