本篇内容主要讲解“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中常见的异常总结
文章地址:/article2/ehicic.html
成都网站建设公司_创新互联,为您提供服务器托管、微信公众号、外贸网站建设、品牌网站设计、动态网站、定制网站
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联