兴化住房和城乡建设局网站,北京朝阳不限购小户型,网站建设的税收分类编码,个人网页制作成品图作者 | 张晋涛编辑 | 胡巍巍来源 | GitChat#xff08;ID#xff1a;GitChat#xff09;Docker 上手很容易#xff0c;但如果将其应用于生产环境#xff0c;则需要对它有更深入的理解。只有这样#xff0c;才能确保应用符合我们的预期#xff0c;或在遇到问题时可及时解… 作者 | 张晋涛编辑 | 胡巍巍来源 | GitChatIDGitChatDocker 上手很容易但如果将其应用于生产环境则需要对它有更深入的理解。只有这样才能确保应用符合我们的预期或在遇到问题时可及时解决。所以要想真正掌握 Docker 的核心知识只靠网络上零散的信息往往是不够的必须系统性地学习。容器作为 Docker 的核心特性之一是 Docker 使用者们无法回避的重要知识点。要想了解容器的核心原理甚至自己动手写容器不深入了解容器资源管理的相关的内容是绝对不行的。本文将以容器资源管理为主题解决以下三个问题哪些分配给容器的资源可被我们管理容器实际使用了多少资源如何对容器使用的资源进行管理资源类型对于第一个问题当我们启动一个容器的时候它可以使用一些系统资源这与我们在物理机上启动程序基本是一致的。比如主要的几类CPU内存网络I/OGPU这些系统资源是在我们启动容器时需要考虑和可被我们管理的。比如我们可以执行 docker run --help 查看 docker run 命令所支持的全部参数。现在 docker run 命令所支持的参数已超过 90 项这里就不一一列出了。查看容器占用资源docker statsDocker 提供了一个很方便的命令 docker stats可供我们查看和统计容器所占用的资源情况。我们仍然启动一个 Redis 容器作为示例。# 启动一个容器
(MoeLove) ➜ ~ docker run -d redis
c98c9831ee73e9b71719b404f5ecf3b408de0b69aec0f781e42d815575d28ada
# 查看其所占用资源的情况
(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
c98c9831ee73 amazing_torvalds 0.08% 2.613MiB / 15.56GiB 0.02% 3.66kB / 0B 0B / 0B 4这里传递了一个 --no-stream 的参数是因为 docker stats 命令默认是一个持续的动态流式输出每秒一次给它传递 --no-stream 参数后它就只输出一次便会退出了。接下来我为你介绍下它输出内容的含义Container ID容器的 ID也是一个容器生命周期内不会变更的信息。Name容器的名称如果没有手动使用 --name 参数指定则 Docker 会随机生成一个运行过程中也可以通过命令修改。CPU %容器正在使用的 CPU 资源的百分比这里面涉及了比较多细节下面会详细说。Mem Usage/Limit当前内存的使用及容器可用的最大内存这里我使用了一台 16G 的电脑进行测试。Mem %容器正在使用的内存资源的百分比。Net I/O容器通过其网络接口发送和接受到的数据量。Block I/O容器通过块设备读取和写入的数据量。Pids容器创建的进程或线程数。docker top除了上面提到的 docker stats 命令外Docker 也提供了另一个比较简单的命令 docker top与我们平时用的 ps 命令基本一致, 也支持 ps 命令的参数。(MoeLove) ➜ ~ docker top $(docker ps -ql)
UID PID PPID C STIME TTY TIME CMD
systemd 6275 6248 0 16:50 ? 00:00:24 redis-server *:6379
# 可以使用 ps 命令的参数
(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,stat,cmd
PID STAT CMD
6275 Ssl redis-server *:6379管理容器的 CPU 资源在我们使用容器的时候CPU 和内存是我们尤为关注的资源。不过对于 CPU 资源的管理涉及的内容会比较偏底层一些有些涉及到了内核的 CPU 调度器比如 CFSCompletely Fair Scheduler等。我们可以先来查看下 Docker 提供了哪些控制 CPU 资源相关的参数。使用 docker run --help |grep CPU 即可查看。(MoeLove) ➜ ~ docker run --help |grep CPU--cpu-period int Limit CPU CFS (Completely Fair Scheduler) period--cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota--cpu-rt-period int Limit CPU real-time period in microseconds--cpu-rt-runtime int Limit CPU real-time runtime in microseconds-c, --cpu-shares int CPU shares (relative weight)--cpus decimal Number of CPUs--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)这里暂时先不对参数的具体含义进行深入展开我们直接以几个示例来分别进行说明帮助大家理解。默认无限制备注我这里以一个 4 核 CPU 的电脑进行演示。现在我们启动一个容器我们以体积很小的 Alpine Linux 为例好了。(MoeLove) ➜ ~ docker run --rm -it alpine
/ #在另一个窗口执行上面介绍的查看容器资源的命令(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
106a24399bc9 friendly_varahamihira 0.00% 1.047MiB / 15.56GiB 0.01% 5.01kB / 0B 1.67MB / 0B 1可以看到当前容器内没有过多的 CPU 消耗且 PIDS 为 1表示当前只有一个进程。现在我们回到刚才启动的容器执行以下命令sha256sum /dev/zero
sha256sum 是一个用于计算和检查 SHA256 信息的命令行工具/dev/zero 是 Linux 系统上一个特殊的设备在读它时它可以提供无限的空字符串NULL 或者 0x00 之类的。所以上面的命令会**让 sha256sum 持续地读 /dev/zero 产生的空串并进行计算。**这将迅速地消耗 CPU 资源。我们来看看此时容器的资源使用情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
106a24399bc9 friendly_varahamihira 100.59% 1.5MiB / 15.56GiB 0.01% 14.4kB / 0B 1.99MB / 0B 2
(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
965 99 sha256sum /dev/zero可以看到当前的 CPU 使用率已经在 100% 左右了。我们再新打开一个窗口进入容器内执行相同的命令(MoeLove) ➜ ~ docker exec -it $(docker ps -ql) sh
/ # sha256sum /dev/zero查看容器使用资源的情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
f359d4ff6fc6 nice_zhukovsky 200.79% 1.793MiB / 15.56GiB 0.01% 4.58kB / 0B 0B / 0B 4
(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
965 99 sha256sum /dev/zero
1236 0 sh
1297 99 sha256sum /dev/zero可以看到现在两个进程已经让两个 CPU 满负载运行了。这里需要额外说明的是选择 sha256sum 作为示例是因为它是单线程程序每次启动一个 sha256sum 并不会消耗其他 CPU 核的资源。由此可以得出的结论是如果不对容器内程序进行 CPU 资源限制其可能会消耗掉大量 CPU 资源进而影响其他程序或者影响系统的稳定。分配 0.5 CPU那接下来我们对这个容器进行 CPU 资源的限制比如限制它只可以使用 0.5 CPU。(MoeLove) ➜ ~ docker update --cpus 0.5 $(docker ps -ql)
f359d4ff6fc6我们可以重新启动一个容器在 docker run 时为它添加资源限制。但我来给你介绍一种动态更改资源限制的办法使用 docker update 命令。例如在此例子中我们使用如下命令限制该容器只能使用 0.5 CPU。为了方便我们直接关闭刚才的 sha256sum 进程按 Ctrlc 终止进程。然后重新运行该命令# 终止进程
/ # sha256sum /dev/zero
^C
# 启动程序
/ # sha256sum /dev/zero查看资源占用情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
f359d4ff6fc6 nice_zhukovsky 49.87% 1.777MiB / 15.56GiB 0.01% 112kB / 0B 1.59MB / 0B 3(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
1236 0 sh
7662 49 sha256sum /dev/zero可以看到该进程使用了 50% 左右的 CPU。我们接下来再启动另一个 sha256sum 的进程/ # sha256sum /dev/zero查看资源使用情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
f359d4ff6fc6 nice_zhukovsky 50.92% 1.891MiB / 15.56GiB 0.01% 113kB / 0B 1.59MB / 0B 4(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
1236 0 sh可以看到该容器整体占用了 50% 的 CPU而其中的两个 sha256sum 进程则各占了 25%。我们已经成功的按预期为它分配了 0.5 CPU。分配 1.5 CPU接下来重复上述步骤但是为它分配 1.5 CPU来看看它的实际情况如何。# 更新配置使用 1.5 CPU
(MoeLove) ➜ ~ docker update --cpus 1.5 $(docker ps -ql)
f359d4ff6fc6分别使用之前的两个窗口执行 sha256sum /dev/zero 进行测试/ # sha256sum /dev/zero查看资源使用情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
f359d4ff6fc6 nice_zhukovsky 151.23% 2MiB / 15.56GiB 0.01% 122kB / 0B 1.59MB / 0B 4(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
1236 0 sh
25167 77 sha256sum /dev/zero
25211 74 sha256sum /dev/zero可以看到结果与我们的预期基本相符150% 左右的 CPU而两个测试进程也差不多是平分了 CPU 资源。指定可使用 CPU 核可以使用 --cpuset-cpus 来指定分配可使用的 CPU 核这里我指定为 0表示使用第一个 CPU 核。(MoeLove) ➜ ~ docker update --cpus 1.5 --cpuset-cpus 0 $(docker ps -ql)
f359d4ff6fc6分别使用之前的两个窗口执行 sha256sum /dev/zero 进行测试/ # sha256sum /dev/zero查看资源情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
f359d4ff6fc6 nice_zhukovsky 99.18% 1.988MiB / 15.56GiB 0.01% 221kB / 0B 1.59MB / 0B 4
(MoeLove) ➜ ~ docker top $(docker ps -ql) -o pid,c,cmd
PID C CMD
825 0 /bin/sh
1236 0 sh
25119 50 sha256sum /dev/zero
25164 48 sha256sum /dev/zero可以看到虽然我们仍然使用 --cpus 指定了 1.5 CPU但由于使用 --cpuset-cpus 限制只允许它跑在第一个 CPU 上所以这两个测试进程也就只能评分该 CPU 了。本文节选自专栏。小结通过上述的示例我介绍了如何通过 --cpus 参数限制容器可使用的 CPU 资源通过 --cpuset-cpus 参数可指定容器内进程运行所用的 CPU 核心通过 docker update 可直接更新一个正在运行的容器的相关配置。现在我们回到前面使用 docker run --help | grep CPU查看 Docker 支持的对容器 CPU 相关参数的选项(MoeLove) ➜ ~ docker run --help |grep CPU--cpu-period int Limit CPU CFS (Completely Fair Scheduler) period--cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota--cpu-rt-period int Limit CPU real-time period in microseconds--cpu-rt-runtime int Limit CPU real-time runtime in microseconds-c, --cpu-shares int CPU shares (relative weight)--cpus decimal Number of CPUs--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)--cpus 是在 Docker 1.13 时新增的可用于替代原先的 --cpu-period 和 --cpu-quota。这三个参数通过 cgroups 最终会实际影响 Linux 内核的 CPU 调度器 CFSCompletely Fair Scheduler, 完全公平调度算法对进程的调度结果。一般情况下推荐直接使用 --cpus而无需单独设置 --cpu-period 和 --cpu-quota除非你已经对 CPU 调度器 CFS 有了足够多的了解提供 --cpus 参数也是 Docker 团队为了可以简化用户的使用成本增加的它足够满足我们大多数的需求。而 --cpu-shares 选项它虽然有一些实际意义但却不如 --cpus 来的直观并且它会受到当前系统上运行状态的影响为了不因为它给大家带来困扰此处就不再进行介绍了。--cpu-rt-period 和 --cpu-rt-runtime 两个参数会影响 CPU 的实时调度器。但实时调度器需要内核的参数的支持并且配置实时调度器也是个高级或者说是危险的操作有可能会导致各种奇怪的问题此处也不再进行展开。管理容器的内存资源前面已经介绍了如何管理容器的 CPU 资源接下来我们看看如何管理容器的内存资源。相比 CPU 资源来说内存资源的管理就简单很多了。同样的我们先看看有哪些参数可供我们配置对于其含义我会稍后进行介绍(MoeLove) ➜ ~ docker run --help |egrep memory|oom--kernel-memory bytes Kernel memory limit-m, --memory bytes Memory limit--memory-reservation bytes Memory soft limit--memory-swap bytes Swap limit equal to memory plus swap: -1 to enable unlimited swap--memory-swappiness int Tune container memory swappiness (0 to 100) (default -1)--oom-kill-disable Disable OOM Killer--oom-score-adj int Tune hosts OOM preferences (-1000 to 1000)OOM在开始进行容器内存管理的内容前我们不妨先聊一个很常见又不得不面对的问题OOMOut Of Memory。当内核检测到没有足够的内存来运行系统的某些功能时候就会触发 OOM 异常并且会使用 OOM Killer 来杀掉一些进程腾出空间以保障系统的正常运行。这里简单介绍下 OOM killer 的大致执行过程以便于大家理解后续内容。内核中 OOM Killer 的代码在 torvalds/linux/mm/oom_kill.c 可直接看到这里以 Linux Kernel 5.2 为例。引用其中的一段注释If we run out of memory, we have the choice between either killing a random task (bad), letting the system crash (worse).OR try to be smart about which process to kill. Note that we dont have to be perfect here, we just have to be good.翻译过来就是当我们处于 OOM 时我们可以有几种选择随机地杀死任意的任务不好让系统崩溃更糟糕或者尝试去了解可以杀死哪个进程。注意这里我们不需要追求完美我们只需要变好be good就行了。事实上确实如此无论随机地杀掉任意进程或是让系统崩溃那都不是我们想要的。回到内核代码中当系统内存不足时out_of_memory() 被触发之后会调用 select_bad_process() 函数选择一个 bad 进程来杀掉。那什么样的进程是 bad 进程呢总是有些条件的。select_bad_process() 是一个简单的循环其调用了 oom_evaluate_task() 来对进程进行条件计算最核心的判断逻辑是其中的 oom_badness()。unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,const nodemask_t *nodemask, unsigned long totalpages)
{long points;long adj;if (oom_unkillable_task(p, memcg, nodemask))return 0;p find_lock_task_mm(p);if (!p)return 0;/** Do not even consider tasks which are explicitly marked oom* unkillable or have been already oom reaped or the are in* the middle of vfork*/adj (long)p-signal-oom_score_adj;if (adj OOM_SCORE_ADJ_MIN ||test_bit(MMF_OOM_SKIP, p-mm-flags) ||in_vfork(p)) {task_unlock(p);return 0;}/** The baseline for the badness score is the proportion of RAM that each* tasks rss, pagetable and swap space use.*/points get_mm_rss(p-mm) get_mm_counter(p-mm, MM_SWAPENTS) mm_pgtables_bytes(p-mm) / PAGE_SIZE;task_unlock(p);/* Normalize to oom_score_adj units */adj * totalpages / 1000;points adj;/** Never return 0 for an eligible task regardless of the root bonus and* oom_score_adj (oom_score_adj cant be OOM_SCORE_ADJ_MIN here).*/return points 0 ? points : 1;
}而为了能够最快地进行选择这里的逻辑也是尽可能的简单除了明确标记不可杀掉的进程外直接选择内存占用最多的进程。当然还有一个额外的 oom_score_adj 可用于控制权重这种选择的最主要的两个好处是可以回收很多内存可以避免缓解 OOM 后该进程后续对内存的抢占引发后续再次的 OOM。我们将注意力再回到 Docker 自身在生产环境中我们通常会用 Docker 启动多个容器运行服务。当遇到 OOM 时如果 Docker 进程被杀掉那对我们的服务也会带来很大的影响。所以 Docker 在启动的时候默认设置了一个 -500 的 oom_score_adj 以尽可能地避免 Docker 进程本身被 OOM Killer 给杀掉。如果我们想让某个容器尽可能地不要被 OOM Killer 杀掉那我们可以给它传递 --oom-score-adj 配置一个比较低的数值。但是注意不要通过 --oom-kill-disable 禁用掉 OOM Killer或者给容器设置低于 dockerd 进程的 oom_score_adj 值这可能会导致某些情况下系统的不稳定。除非你明确知道自己的操作将会带来的影响。管理容器的内存资源介绍完了 OOM相比你已经知道了内存耗尽所带来的危害我们来继续介绍如何管理容器的内存资源。(MoeLove) ➜ ~ docker run --help |grep memory --kernel-memory bytes Kernel memory limit-m, --memory bytes Memory limit--memory-reservation bytes Memory soft limit--memory-swap bytes Swap limit equal to memory plus swap: -1 to enable unlimited swap--memory-swappiness int Tune container memory swappiness (0 to 100) (default -1)可用的配置参数有上述几个我们通常直接使用 --memory 参数来限制容器可用的内存大小。我们同样使用几个示例进行介绍启动一个容器并传递参数 --memory 10m 限制其可使用的内存为 10 m。(MoeLove) ➜ ~ docker run --rm -it --memory 10m alpine
/ #那我们如何验证它的可用内存大小是多少呢在物理机上我们通常使用 free 工具进行查看。但在容器环境内它还是否生效呢/ # free -mtotal used free shared buffers cached
Mem: 15932 14491 1441 1814 564 3632
-/ buffers/cache: 10294 5637
Swap: 8471 693 7778很明显使用 free 得到的结果是宿主机上的信息。当然我们前面已经介绍了 docker stats 命令我们使用它来查看当前的资源使用情况(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
e260e91874d8 busy_napier 0.00% 1.172MiB / 10MiB 11.72% 16.1kB / 0B 0B / 0B 1可以看到 MEM USAGE / LIMIT 那一列中的信息已经生效是我们预期的样子。那我们是否还有其他方式查看此信息呢当然有# 在容器内执行
/ # cat /sys/fs/cgroup/memory/memory.limit_in_bytes
10485760或者可以在宿主机上执行以下命令(MoeLove) ➜ ~ cat /sys/fs/cgroup/memory/system.slice/docker-$(docker inspect --format {{ .Id}} $(docker ps -ql)).scope/memory.limit_in_bytes
10485760注意以上命令在 Linux 5.2 内核下测试通过不同版本之间目录结构略有差异。更新容器内存资源限制当容器运行一段时间其中的进程使用的内存变多了我们想允许容器使用更多内存资源那要如何操作呢我们仍然可以用前面介绍的 docker update 命令完成。比如使用如下命令将可用内存扩大至 20m(MoeLove) ➜ ~ docker update --memory 20m $(docker ps -ql)
e260e91874d8
# 验证是否生效
(MoeLove) ➜ ~ docker stats --no-stream $(docker ps -ql)
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
e260e91874d8 busy_napier 0.00% 1.434MiB / 20MiB 7.17% 35.3kB / 0B 0B / 0B 1如果还不够需要扩大至 100m 呢(MoeLove) ➜ ~ docker update --memory 100m $(docker ps -ql)
Error response from daemon: Cannot update container e260e91874d8181b6d0078c853487613907cd9ada2af35d630a7bef204654982: Memory limit should be smaller than already set memoryswap limit, update the memoryswap at the same time会发现这里有个报错信息。大意是 memory limit 应该比已经配置的 memoryswap limit 小需要同时更新 memoryswap。你可能会困惑之前我们只是限制了内存为 10m并且扩大至 20m 的时候是成功了的。为什么到 100m 的时候就会出错这就涉及到了这些参数的特定行为了我来为你一一介绍。内存限制参数的特定行为这里的特定参数行为主要是指我们前面使用的 --memory 和未介绍过的 --memory-swap 这两个参数。1. --memory 用于限制内存使用量而 --memory-swap 则表示内存和 Swap 的总和。这解释了上面“Memory limit should be smaller than already set memoryswap limit”因为 --memory-swap 始终应该大于等于 --memory 毕竟 Swap 最小也只能是 0 。2. 如果只指定了 --memory 则最终 --memory-swap 将会设置为 --memory 的两倍。也就是说在只传递 --memory 的情况下容器只能使用与 --memory 相同大小的 Swap。这也解释了上面“直接扩大至 20m 的时候能成功而扩大到 100m 的时候会出错”在上述场景中只指定了 --memory 为 10m所以 --memory-swap 就默认被设置成了 20m。3. 如果 --memory-swap 和 --memory 设置了相同值则表示不使用 Swap。4. 如果 --memory-swap 设置为 -1 则表示不对容器使用的 Swap 进行限制。5. 如果设置了 --memory-swap 参数则必须设置 --memory 参数。至此我介绍了容器资源管理的核心内容包括管理容器的 CPU 资源和内存资源。为容器进行合理的资源控制有利于提高整体环境的稳定性避免资源抢占或大量内存占用导致 OOM进程被杀掉等情况。对 CPU 进行管理时建议使用 --cpus语义方面会比较清晰。如果是对 Linux 的 CPU 调度器 CFS 很熟悉并且有强烈的定制化需求这种情况下再使用 --cpu-period 和 --cpu-quota 比较合适。对内存进行管理时有个 --memory-swappiness 参数也需要注意下它可设置为 0~100 的百分比与我们平时见到的 swappiness 行为基本一致设置为 0 表示不使用匿名页面交换设置为 100 则表示匿名页面都可被交换。如果不指定的话它默认会从主机上继承。在本文中关于在宿主机上查看容器的内存限制我给出了一个命令(MoeLove) ➜ ~ cat /sys/fs/cgroup/memory/system.slice/docker-$(docker inspect --format {{ .Id}} $(docker ps -ql)).scope/memory.limit_in_bytes
10485760本文节选自GitChat专栏戳链接查看详情https://gitbook.cn/m/mazi/comp/column?columnId5d70cfdc4dc213091bfca46f【END】热 文 推 荐 ☞疫情之下「在家办公模式」开启你该选择哪些远程协同工具☞疫情肆虐下程序员们都在哪里☞云计算的 2020云原生崛起重新定义软件☞数十名工程师作战5天阿里达摩院连夜研发智能疫情机器人☞区块链如何击败 AI、云计算成为最受欢迎技能用开发者的方式共克时艰
