Docker中常见的异常总结
本篇内容主要讲解“Docker中常见的异常总结”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Docker中常见的异常总结”吧!
异常一
创新互联建站一直秉承“诚信做人，踏实做事”的原则，不欺瞒客户，是我们最起码的底线！ 以服务为基础，以质量求生存，以技术求发展，成交一个客户多一个朋友！为您提供成都做网站、成都网站设计、成都网页设计、成都微信小程序、成都网站开发、成都网站制作、成都软件开发、重庆APP软件开发是成都本地专业的网站建设和网站设计公司，等你一起来见证！
docker ps 无响应， Node 节点表现为 NotReady。运行信息$ docker -v$ Docker version 17.03.2-ce, build f5ec1e2$ docker-containerd -v$ containerd version 0.2.3 commit:4ab9917febca54791c5f071a9d1f404867857fcc$ docker-runc -v$ runc version 1.0.0-rc2$ commit: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe$ spec: 1.0.0-rc2-dev启用 Docker Debug 模式
有两种方法可以启用调试。 建议的方法是在 daemon.json 文件中将 debug 设置为 true。 此方法适用于每个 Docker 平台。
1.编辑 daemon.json 文件，该文件通常位于 /etc/docker/ 中。 如果该文件尚不存在，您可能需要创建该文件。 2.增加以下设置{ "debug": true}
3.向守护程序发送 HUP 信号以使其重新加载其配置。sudo kill -SIGHUP $(pidof dockerd)
可以看到 Docker debug 级别的日志：Dec 14 20:04:45 dockerd[7926]: time="2018-12-14T20:04:45.788669544+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:45 dockerd[7926]: time="2018-12-14T20:04:45.790628950+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:46 dockerd[7926]: time="2018-12-14T20:04:46.792531056+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:46 dockerd[7926]: time="2018-12-14T20:04:46.794433693+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:47 dockerd[7926]: time="2018-12-14T20:04:47.097363259+08:00" level=debug msg="Calling GET /v1.27/containers/json?filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:47 dockerd[7926]: time="2018-12-14T20:04:47.098448324+08:00" level=debug msg="Calling GET /v1.27/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%2C%22status%22%3A%7B%22running%22%3Atrue%7D%7D&limit=0"Dec 14 20:04:47 dockerd[7926]:
dockerd一直在请求 list containers 接口，但是没有响应。打印堆栈信息$ kill -SIGUSR1 $(pidof dockerd)
生成的调试信息可以在以下目录找到：...goroutine stacks written to /var/run/docker/goroutine-stacks-2018-12-02T193336z.log...daemon datastructure dump written to /var/run/docker/daemon-data-2018-12-02T193336z.log
查看 goroutine-stacks-2018-12-02T193336z.log 文件内容，goroutine 248 [running]:github.com/docker/docker/pkg/signal.DumpStacks(0x18fe090, 0xf, 0x0, 0x0, 0x0, 0x0) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/pkg/signal/trap.go:82 +0xfcgithub.com/docker/docker/daemon.(*Daemon).setupDumpStackTrap.func1(0xc421462de0, 0x18fe090, 0xf, 0xc4203c8200) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:19 +0xcbcreated by github.com/docker/docker/daemon.(*Daemon).setupDumpStackTrap /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/daemon/debugtrap_unix.go:32 +0x10agoroutine 1 [chan receive, 91274 minutes]:main.(*DaemonCli).start(0xc42048a840, 0x0, 0x190f560, 0x17, 0xc420488400, 0xc42046c820, 0xc420257320, 0x0, 0x0) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/daemon.go:326 +0x183emain.runDaemon(0x0, 0x190f560, 0x17, 0xc420488400, 0xc42046c820, 0xc420257320, 0x10, 0x0) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:86 +0xb2main.newDaemonCommand.func1(0xc42041f200, 0xc42045df00, 0x0, 0x10, 0x0, 0x0) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:42 +0x71github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).execute(0xc42041f200, 0xc42000c130, 0x10, 0x11, 0xc42041f200, 0xc42000c130) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:646 +0x26dgithub.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42041f200, 0x16fc5e0, 0xc42046c801, 0xc420484810) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:742 +0x377github.com/docker/docker/vendor/github.com/spf13/cobra.(*Command).Execute(0xc42041f200, 0xc420484810, 0xc420084058) /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/vendor/github.com/spf13/cobra/command.go:695 +0x2bmain.main() /root/rpmbuild/BUILD/docker-ce/.gopath/src/github.com/docker/docker/cmd/dockerd/docker.go:106 +0xe2goroutine 17 [syscall, 91275 minutes, locked to thread]:...
至此，我们可以确定，containerd 无响应导致的 docker ps 无响应，在堆栈中我们也可以看到调用 containerd 无响应是因为加了lock.查看dmesg
通过 dmesg 查看系统异常信息,发现 cgroup 报 OOM 溢出错误。[7993043.926831] Memory cgroup out of memory: Kill process 20357 (runc:[2:INIT]) score 970 or sacrifice child
查看了大部分机器的 dmesg 信息，发现都有 OOM 这个错误，至此我们怀疑是由于某个容器 OOM 导致的 containerd 无响应.模拟OOM
既然怀疑是容器 OOM 异常导致的 containerd 无响应，那我们干脆自己创造现场模拟一下。
首选我们创建一个 OOM 的部署，通过 nodeSelector 让这个部署调度到指定 Node。apiVersion: extensions/v1beta1kind: Deploymentmetadata: labels: wayne-app: oomtest wayne-ns: test app: oomtest name: oomtestspec: selector: matchLabels: app: oomtest template: metadata: labels: wayne-app: oomtest wayne-ns: test app: oomtest spec: nodeSelector: kubernetes.io/hostname: test-001 containers: - resources: limits: memory: 0.2Gi cpu: '0.2' requests: memory: 0.2Gi cpu: '0.1' args: - '-m' - '10' - '--vm-bytes' - 128M - '--timeout' - 60s - '--vm-keep' image: progrium/stress name: stress
发现过了一会 test-001 这台 Node 出现了 docker ps 无响应的情况，查看 dmesg 以及 containerd 的堆栈信息，发现和之前的 Node 出现的异常一致。至此，基本可以确定是某个容器 OOM 导致的 containerd hung 住。原因分析
通过查找社区 Issues 及相关 PR，最后发现根本原因是 runc 的bug。
使用 runc start 或 runc run 启动容器时，stub process（runc [2：INIT]）打开一个 fifo 进行写入。 它的父 runc 进程 将打开相同的 fifo 阅读。 通过这种方式，它们可以同步。
如果 stub process 在错误的时间退出，那么父 runc 进程 会永远被阻塞。
当两个 runc 操作相互竞争时会发生这种情况：runc run / start 和 runc delete。 它也可能由于其他原因而发生， 例如 内核的 OOM killer 可以选择杀死 stub process。解决方案：
通过解决 exec fifo 竞争来解决这个问题。 如果 在我们打开 fifo 之前 stub process 退出，那么返回一个错误。小结
containerd 官方已经在 v1.0.2 版本合并了这个修改。因此这个问题可以通过升级 Docker 版本解决。我们目前已经将部分机器升级到 Docker 18.06。 已升级的机器暂时未发现类似问题。
相关issues： https://github.com/containerd/containerd/issues/1882 https://github.com/containerd/containerd/pull/2048 https://github.com/opencontainers/runc/pull/1698异常二
Docker 在 Centos 系统下以 direct-lvm 模式运行, 无法启动Error starting daemon: error initializing graphdriver: devicemapper: Non existing device docker-thinpoolDec 14 03:21:03 two-slave-41-135 systemd: docker.service: main process exited, code=exited, status=1/FAILUREDec 14 03:21:03 two-slave-41-135 systemd: Failed to start Docker Application Container Engine.Dec 14 03:21:03 two-slave-41-135 systemd: Dependency failed for kubernetes Kubelet.Dec 14 03:21:03 two-slave-41-135 systemd: Job kubelet.service/start failed with result 'dependency'.根本原因
这个问题发生在使用 devicemapper 存储驱动时Docker试图重用之前使用 LVM thin pool。例如，尝试更改节点上的 Docker 的数据目录时会发生此问题。由于安全措施旨在防止 Docker 因配置问题而意外使用和覆盖 LVM thin pool 中的数据，因此会发生此错误。解决方案
要解决阻止Docker启动的问题，必须删除并重新创建逻辑卷，以便Docker将它们视为新的thin pool。
警告：这些命令将清除Docker数据目录中的所有现有镜像和卷。 请在执行这些步骤之前备份所有重要数据。
1.停止 Dockersudo systemctl stop docker.service
2.删除 Dodcker 目录sudo rm -rf /var/lib/docker
3.删除已经创建的 thin pool 逻辑卷$ sudo lvremove docker/thinpoolDo you really want to remove active logical volume docker/thinpool? [y/n]: y Logical volume "thinpool" successfully removed
4.创建新的逻辑卷lvcreate -L 500g --thin docker/thinpool --poolmetadatasize 256m
根据实际磁盘大小调整 thinpool 和 metadata 大小Docker自动direct-lvm模式配置
如果您想要让Docker自动为您配置direct-lvm模式，请继续执行以下步骤。
1.编辑/etc/docker/daemon.json文件以将dm.directlvm_device_force = value从false更改为true。 例如：{ "storage-driver": "devicemapper", "storage-opts": [ "dm.directlvm_device_force=true" ]}
2.除了删除逻辑卷之外，还要删除docker卷组：$ sudo vgremove docker
3.启动Dokcersudo systemctl start docker.service总结
Docker 虽然是目前最常用的容器解决方案，但它仍旧有很多不足。
Docker 的隔离性比较弱，混布容易导致业务互相影响，可能因为一个服务有问题就会影响其他服务甚至影响整个集群。
Docker 自己存在一些 bug， 由于历史原因，很多 bug 无法完全归因于内核或者 Docker，需要 Docker 和内核配合修复。
当前名称：Docker中常见的异常总结
文章网址：http://scyanting.com/article/ehicic.html
