一. 容器与虚拟机的区别
- 和虚拟机相比，容器更加
轻量级。因为运行在相同宿主机上的容器共享一个操作系统，可以节省大量的CPU、RAM和存储等系统资源。从而能够在相同的硬件上运行更多数量的组件。 - 容器能够
更快地启动。因为它不需要像虚拟机一样开机。 - 虚拟机有更好的
隔离性。因为每个虚拟机运行在它自己的Linux内核上，而相同宿主机上容器调用同一内核。 - 容器镜像的可移植性限制。理论上，一个容器能运行在任何一个运行Docker的机器上，除非容器化的应用需要一个特定的内核版本。如果一台机器上运行了一个不匹配的Linux内核版本，或者没有相同内核模块可用，那么此应用就不能在其上运行。另外，一个特定硬件架构之上编译的容器，只能在有相同硬件架构的机器上运行（如x86和ARM不能互用）。
二. Docker隔离性
- Docker最重要的两个隔离机制是
内核命名空间（namespace）和控制组（cgroups）
命名空间
- 默认情况下，每个Linux系统最初只有一个命名空间，但我们能够创建额外的命名空间。每种命名空间用来隔离一组特定的资源，包括：
- 进程ID（pid）
- 网络（net）
- 文件系统/挂载（mnt）
- 进程间通信（IPC）
- 用户（user）
- UTS
- Docker容器本质上就是命名空间的有组织集合。例如，每个容器都由自己的pid, met, mnt, ipc, uts（uts命名空间决定运行在命名空间里的进程能看见哪些主机名和域名）构成。这些命名空间的有机组合就是所谓的容器。
Control group
- cgroup是一个Linux内核功能，运行用户设置限制，使一个容器的资源（CPU、RAM、硬盘IO、网络带宽等）使用量不能超出被分配的量。
三、Docker 镜像
- Docker
镜像（Image）就像停止运行的容器。它包含了打包好的应用程序及其所依赖的环境，应用程序可用的文件系统和其它元数据。
镜像分层
- 镜像由一些松耦合的
只读镜像层组成。Docker通过存储引擎（新版本采用快照机制）的方式来实现镜像层堆栈，并保证对外展示为统一的文件系统。Linux上可用的存储引擎包括aufs, overlay2, device mapper, btrfs, zfs等。 - 所有的Docker镜像都起始于一个基础镜像层，当进行修改或添加新内容时，就会在当前镜像层之上创建新的镜像层。
- 当上层镜像和下层镜像出现相同文件时，上层镜像中的文件会覆盖底层中的文件。
- 多个镜像之间会共享镜像层。这样可以有效节省空间并提升性能。即Docker在拉取镜像时，能够判断出哪几层在本地已经存在，从而跳过该层。
- 镜像层的共享采用了
写时复制（CoW）。基于相同基础层的镜像被创建成两个容器时，它们能够分享该镜像层。该镜像层是只读的。容器运行时，一个新的可写层在顶层被创建。进程写的是此拷贝，从而彼此隔离。
镜像仓库
- Docker镜像存储在
镜像仓库（Image Registry）中。默认的镜像仓库是Docker Hub。也可以配置为一些非官方的公有或私有仓库。
四、Docker 引擎
- docker引擎的主要构件包括：
Docker client，Docker daemon，containerd和runc。它们一起管理着image(镜像)，container(容器)，network(网络)，data volumes(数据卷)的生命周期。
-
Docker daemon: 主要功能包括REST API，镜像管理，镜像构建，身份验证，安全，核心网络和编排等。 -
containerd：主要任务是容器生命周期管理：start, stop, pause, rm等。它也能够被赋予更多的功能，如镜像管理。但这些额外功能是模块化的，可选的。 -
runc： runc 实质上是一个轻量级的、针对 Libcontainer 进行了包装的命令行交互工具。runc 生来只有一个作用——创建容器。
容器启动过程
当使用 Docker 命令行工具执行
docker container run时，
Docker 客户端会将其转换为合适的 API 格式，并发送到正确的 API 端点。一旦 daemon 接收到创建新容器的命令，它就会向 containerd 发出调用。（Docker daemon 使用一种 CRUD 风格的 API，通过 gRPC 与 containerd 进行通信。）
containerd 将 Docker 镜像转换为 OCI bundle，并让 runc 基于此创建一个新的容器。
runc 与操作系统内核接口进行通信，基于所有必要的工具（Namespace、CGroup等）来创建容器。容器进程作为 runc 的子进程启动，启动完毕后，runc 将会退出。
模型的优势
- 容器运行时与 Docker daemon 是解耦的，有时称之为“无守护进程的容器（daemonless container）”，如此，对 Docker daemon 的维护和升级工作不会影响到运行中的容器。
-
shim：shim 是实现无 daemon 的容器不可或缺的工具。前面提到，containerd 指挥 runc 来创建新容器。事实上，每次创建容器时它都会 fork 一个新的 runc 实例。不过，一旦容器创建完毕，对应的 runc 进程就会退出。因此，即使运行上百个容器，也无须保持上百个运行中的 runc 实例。一旦容器进程的父进程 runc 退出，相关联的 containerd-shim 进程就会成为容器的父进程。作为容器的父进程，shim 的部分职责如下。
- 保持所有 STDIN 和 STDOUT 流是开启状态，从而当 daemon 重启的时候，容器不会因为管道（pipe）的关闭而终止。
- 将容器的退出状态反馈给 daemon。
五、Docker网络
Docker 网络架构
- 在顶层设计中，Docker 网络架构由 3 个主要部分构成：
CNM、Libnetwork和驱动。
- 不同的驱动可以通过插拔的方式接入 Libnetwork 来提供定制化的网络拓扑。为了实现开箱即用的效果，Docker 封装了一系列本地驱动，覆盖了大部分常见的网络需求。其中包括
单机桥接网络（Single-Host Bridge Network）、多机覆盖网络（Multi-Host Overlay），并且支持接入现有 VLAN。
CNM
-
CNM是设计标准。在 CNM 中，规定了 Docker 网络架构的基础组成要素。 - 抽象来讲，CNM 定义了 3 个基本要素：
沙盒（Sandbox）、终端（Endpoint）和网络（Network）:
- 沙盒是一个独立的网络栈。其中包括以太网接口、端口、路由表以及 DNS 配置。
- 终端就是虚拟网络接口。就像普通网络接口一样，终端主要职责是负责创建连接。在 CNM 中，终端负责将沙盒连接到网络。
- 网络是 802.1d 网桥（类似大家熟知的交换机）的软件实现。因此，网络就是需要交互的终端的集合，并且终端之间相互独立。
- 下图展示了 CNM 组件是如何与容器进行关联的——沙盒被放置在容器内部，为容器提供网络连接。
容器 A 只有一个接口（终端）并连接到了网络 A。容器 B 有两个接口（终端）并且分别接入了网络 A 和网络 B。容器 A 与 B 之间是可以相互通信的，因为都接入了网络 A。但是，如果没有三层路由器的支持，容器 B 的两个终端之间是不能进行通信的。
需要重点理解的是，终端与常见的网络适配器类似，这意味着终端只能接入某一个网络。因此，如果容器需要接入到多个网络，就需要多个终端。
虽然容器 A 和容器 B 运行在同一个主机上，但其网络堆栈在操作系统层面是互相独立的，这一点由沙盒机制保证。
Libnetwork
-
Libnetwork是 CNM 的具体实现 - Docker 核心网络架构代码都在 Libnetwork 当中。Libnetwork 实现了 CNM 中定义的全部 3 个组件。此外它还实现了本地服务发现（Service Discovery）、基于 Ingress 的容器负载均衡，以及网络控制层和管理层功能。
驱动
如果说 Libnetwork 实现了控制层和管理层功能，那么驱动就负责实现数据层。比如，网络连通性和隔离性是由驱动来处理的，驱动层实际创建网络对象也是如此，其关系如下图所示。
Docker 封装了若干内置驱动，通常被称作原生驱动或者本地驱动。
在 Linux 上包括 Bridge、Overlay 以及 Macvlan，在 Windows 上包括 NAT、Overlay、Transport 以及 L2 Bridge。
第三方也可以编写 Docker 网络驱动。这些驱动叫作远程驱动，例如 Calico、Contiv、Kuryr 以及 Weave。
每个驱动都负责其上所有网络资源的创建和管理。
为了满足复杂且不固定的环境需求，Libnetwork 支持同时激活多个网络驱动。这意味着 Docker 环境可以支持一个庞大的异构网络。
单机桥接网络
- 单机意味着该网络只能在单个 Docker 主机上运行，并且只能与所在 Docker 主机上的容器进行连接，桥接意味着这是 802.1.d 桥接的一种实现（二层交换机）。
- 每个 Docker 主机都有一个默认的单机桥接网络。在 Linux 上网络名称为 bridge，在 Windows 上叫作 nat。除非读者通过命令行创建容器时指定参数--network，否则默认情况下，新创建的容器都会连接到该网络。
- 该网络下，可用通过
端口映射（Port Mapping）来与其它主机上的容器进行通信。端口映射允许将某个容器端口映射到 Docker 主机端口上。对于配置中指定的 Docker 主机端口，任何发送到该端口的流量，都会被转发到容器。但这也意味着其它容器不能再使用该端口了。因此单机桥接网络只适合本地开发环境和很小的应用
接入现有网络
- Docker 内置的
Macvlan 驱动（Windows 上是 Transparent）通过为容器提供 MAC 和 IP 地址，让容器在物理网络上成为“一等公民”。 - Macvlan 的优点是性能优异，因为无须端口映射或者额外桥接，可以直接通过主机接口（或者子接口）访问容器接口。但是，Macvlan 的缺点是需要将主机网卡（NIC）设置为混杂模式（Promiscuous Mode），这在大部分公有云平台上是不允许的。
覆盖网络
- 它允许创建扁平的、安全的二层网络来连接多个主机，容器可以
连接到覆盖网络并直接互相通信。 - Docker 使用
VXLAN 隧道技术创建了虚拟二层覆盖网络。在 VXLAN 的设计中，允许用户基于已经存在的三层网络结构创建虚拟的二层网络。 - 一个二层覆盖网络横跨两台主机，并且每个容器在覆盖网络中都有自己的IP地址。通过跟踪路由，发现他们路由只有一跳，可知它们通过覆盖网络直连。
六、Docker Volume
- 容器数据分为
持久化与非持久化的 - 每个 Docker 容器都有自己的非持久化存储。非持久化存储自动创建，从属于容器，生命周期与容器相同。这意味着删除容器也会删除全部非持久化数据。
- 如果希望自己的容器数据保留下来（持久化），则需要将数据存储在
卷（Volume）上。卷与容器是解耦的，从而可以独立地创建并管理卷，并且卷并未与任意容器生命周期绑定。 - 卷会挂载到容器文件系统的某个目录之下，任何写到该目录下的内容都会写到卷中。即使容器被删除，卷与其上面的数据仍然存在。
- 默认情况下，Docker 创建新卷时采用内置的 local 驱动。恰如其名，本地卷只能被所在节点的容器使用。使用 -d 参数可以指定不同的驱动。
- 第三方驱动可以通过插件方式接入。这些驱动提供了高级存储特性，并为 Docker 集成了外部存储系统。
- 截止到目前为止，已经存在 25 种卷插件，涵盖了
块存储、文件存储、对象存储等:
- 块存储：相对性能更高，适用于对小块数据的随机访问负载。目前支持 Docker 卷插件的块存储例子包括 HPE 3PAR、Amazon EBS 以及 OpenStack 块存储服务（Cinder）。
- 文件存储：包括 NFS 和 SMB 协议的系统，同样在高性能场景下表现优异。支持 Docker 卷插件的文件存储系统包括 NetApp FAS、Azure 文件存储以及 Amazon EFS。
- 对象存储：适用于较大且长期存储的、很少变更的二进制数据存储。通常对象存储是根据内容寻址，并且性能较低。支持 Docker 卷驱动的例子包括 Amazon S3、Ceph 以及 Minio。
