docker 部署微服务：一台宿主机一个 docker 容器开着吗？那么性能会不会有限制？类似 vm 那种？

今天在听架构课程时候，听到了多台机器，我们使用 docker 来进行部署服务，使用 K8S 集群管理。

那么本人就突然有疑问，多台主机，一个主机一个 docker 吗？性能如何分配？比如 cpu 内存 磁盘空间等。

答案是：一台电脑，一个 docker 执行。
具体参考如下。
如果你对我的观点有疑问，可以联系我。

docker 注意点#

大家需要注意，Docker 本身并不是容器，它是创建容器的工具，是应用容器引擎。

想要搞懂 Docker，其实看它的两句口号就行。

第一句，是 “Build, Ship and Run”。

k8s 注意点#

就在 Docker 容器技术被炒得热火朝天之时，大家发现，如果想要将 Docker 应用于具体的业务实现，是存在困难的 —— 编排、管理和调度等各个方面，都不容易。于是，人们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵活的管理。

就在这个时候，K8S 出现了。

K8S，就是基于容器的集群管理平台，它的全称，是 kubernetes。
Kubernetes 这个单词来自于希腊语，含义是舵手或领航员。K8S 是它的缩写，用 “8” 字替代了 “ubernete” 这 8 个字符。

Docker 容器 CPU、memory 资源限制#

背景#

在使用 docker 运行容器时，默认的情况下，docker 没有对容器进行硬件资源的限制，当一台主机上运行几百个容器，这些容器虽然互相隔离，但是底层却使用着相同的 CPU、内存和磁盘资源。如果不对容器使用的资源进行限制，那么容器之间会互相影响，小的来说会导致容器资源使用不公平；大的来说，可能会导致主机和集群资源耗尽，服务完全不可用。

docker 作为容器的管理者，自然提供了控制容器资源的功能。正如使用内核的 namespace 来做容器之间的隔离，docker 也是通过内核的 cgroups 来做容器的资源限制；包括 CPU、内存、磁盘三大方面，基本覆盖了常见的资源配额和使用量控制。

Docker 内存控制 OOME 在 linxu 系统上，如果内核探测到当前宿主机已经没有可用内存使用，那么会抛出一个 OOME (Out Of Memory Exception: 内存异常)，并且会开启 killing 去杀掉一些进程。

一旦发生 OOME，任何进程都有可能被杀死，包括 docker daemon 在内，为此，docker 特地调整了 docker daemon 的 OOM_Odj 优先级，以免他被杀掉，但容器的优先级并未被调整。经过系统内部复制的计算后，每个系统进程都会有一个 OOM_Score 得分，OOM_Odj 越高，得分越高，（在 docker run 的时候可以调整 OOM_Odj）得分最高的优先被 kill 掉，当然，也可以指定一些特定的重要的容器禁止被 OMM 杀掉，在启动容器时使用 –oom-kill-disable=true 指定。

cgroup 简介#

cgroup 是 Control Groups 的缩写，是 Linux 内核提供的一种可以限制、记录、隔离进程组所使用的物理资源 (如 cpu、memory、磁盘 IO 等等) 的机制，被 LXC、docker 等很多项目用于实现进程资源控制。cgroup 将任意进程进行分组化管理的 Linux 内核功能。cgroup 本身是提供将进程进行分组化管理的功能和接口的基础结构，I/O 或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。这些具体的资源管理功能称为 cgroup 子系统，有以下几大子系统实现：

1. blkio：设置限制每个块设备的输入输出控制。例如：磁盘，光盘以及 usb 等等。
2. cpu：使用调度程序为 cgroup 任务提供 cpu 的访问。 cpuacct：产生 cgroup 任务的 cpu 资源报告。
3. cpuset：如果是多核心的 cpu，这个子系统会为 cgroup 任务分配单独的 cpu 和内存。
4. devices：允许或拒绝 cgroup 任务对设备的访问。
5. freezer：暂停和恢复 cgroup 任务。
6. memory：设置每个 cgroup 的内存限制以及产生内存资源报告。
7. net_cls：标记每个网络包以供 cgroup 方便使用。
8. ns：命名空间子系统。
9. perf_event：增加了对每 group 的监测跟踪的能力，即可以监测属于某个特定的 group 的所有线程以及运行在特定 CPU 上的线程。

目前 docker 只是用了其中一部分子系统，实现对资源配额和使用的控制。

内存限制#

Docker 提供的内存限制功能有以下几点：

容器能使用的内存和交换分区大小。
容器的核心内存大小。
容器虚拟内存的交换行为。
容器内存的软性限制。
是否杀死占用过多内存的容器。
容器被杀死的优先级
一般情况下，达到内存限制的容器过段时间后就会被系统杀死。

详细的省略了

CPU 限制#

概述
Docker 的资源限制和隔离完全基于 Linux cgroups。对 CPU 资源的限制方式也和 cgroups 相同。Docker 提供的 CPU 资源限制选项可以在多核系统上限制容器能利用哪些 vCPU。而对容器最多能使用的 CPU 时间有两种限制方式：一是有多个 CPU 密集型的容器竞争 CPU 时，设置各个容器能使用的 CPU 时间相对比例。二是以绝对的方式设置容器在每个调度周期内最多能使用的 CPU 时间。

磁盘 IO 配额控制#

相对于 CPU 和内存的配额控制，docker 对磁盘 IO 的控制相对不成熟，大多数都必须在有宿主机设备的情况下使用。主要包括以下参数：

1. –device-read-bps：限制此设备上的读速度（bytes per second），单位可以是 kb、mb 或者 gb。
2. –device-read-iops：通过每秒读 IO 次数来限制指定设备的读速度。
3. –device-write-bps ：限制此设备上的写速度（bytes per second），单位可以是 kb、mb 或者 gb。
4. –device-write-iops：通过每秒写 IO 次数来限制指定设备的写速度。
5. –blkio-weight：容器默认磁盘 IO 的加权值，有效值范围为 10-100。
6. –blkio-weight-device： 针对特定设备的 IO 加权控制。其格式为 DEVICE_NAME:WEIGHT

存储配额控制的相关参数，可以参考 Red Hat 文档中 blkio 这一章，了解它们的详细作用。

容器空间大小限制#

在 docker 使用 devicemapper 作为存储驱动时，默认每个容器和镜像的最大大小为 10G。如果需要调整，可以在 daemon 启动参数中，使用 dm.basesize 来指定，但需要注意的是，修改这个值，不仅仅需要重启 docker daemon 服务，还会导致宿主机上的所有本地镜像和容器都被清理掉。

使用 aufs 或者 overlay 等其他存储驱动时，没有这个限制。

本作品采用《CC 协议》，转载必须注明作者和本文链接