docker容器cpu高问题排查_【docker-ce】k8s集群docker容器异常重启问题分析

最新推荐文章于 2023-05-26 16:32:19 发布
最新推荐文章于 2023-05-26 16:32:19 发布
阅读量505 收藏 2
点赞数
文章标签： docker容器cpu高问题排查
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_36443680/article/details/112484985
版权

3f0eb29142a9b328b37419d63606f78c.png

背景

  • 目前机器学习平台后端采用k8s架构进行GPU和CPU资源的调度和容器编排。k8s的核心能力是容器编排，容器服务的稳定运行直接关系到整体平台的稳定性。
  • 春节值班期间，机器学习平台实验环境-隔离环境 vgpu资源出现比较多的用户容器异常退出问题。此问题导致Pod中的用户容器发生重建，一些用户在容器运行时环境的数据会丢失，由于平台具有暂存用户异常容器现场的能力，值班同学可以通过恢复用户异常容器现场来恢复用户的数据。
  • 用户容器异常退出，虽然可以通过运维工具来恢复用户的数据进行问题降级处理，但是频繁无故的用户容器异常退出，环境重启问题，极大的影响了用户使用 机器学习平台实验环境-隔离环境 vgpu资源的体验和值班同学处理类似问题的时效性。

问题记录-之看现象

  • 【看现场】
    • 版本信息
root@gpu-ser-xyz:~$ kubelet --version
Kubernetes v1.14-mlpe-20200225
root@gpu-ser-xyz:~$ docker version
Client:
Version:           18.09.2
API version:       1.39
Go version:        go1.10.6
Git commit:        6247962
Built:             Sun Feb 10 04:13:27 2019
OS/Arch:           linux/amd64
Experimental:      false
Server: Docker Engine - Community
Engine:
Version:          18.09.2
API version:      1.39 (minimum version 1.12)
Go version:       go1.10.6
Git commit:       6247962
Built:            Sun Feb 10 03:47:25 2019
OS/Arch:          linux/amd64
Experimental:     false
root@gpu-ser-xyz:~$ ctr --address /var/run/docker/containerd/containerd.sock version
Client:
Version:  1.2.2
Revision: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
Server:
Version:  1.2.2
Revision: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
root@gpu-ser-xyz:~$ containerd -v
containerd github.com/containerd/containerd 1.2.2 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
root@gpu-ser-xyz:~$ runc -v
runc version 1.0.0-rc6+dev
commit: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
spec: 1.0.1-dev
root@gpu-ser-xyz:~$ nvidia-container-runtime -v
runc version 1.0.0-rc6+dev
commit: 6635b4f0c6af3810594d2770f662f34ddc15b40d-dirty
spec: 1.0.1-dev
    • 表格中记录了2020-01-14到2020-02-04期间一部分用户容器的kvm环境、docker、containerd、容器错误码的信息。

3e50e9eedb2f6d24b379149e67168fe7.png
  • 开始部分同学是怀疑cuda版本兼容性问题，导致用户容器异常退出，想通过升级cuda版本查看此问题是否收敛，但是cuda-10.0上也有类似现场，此怀疑不攻自破。
  • 是否是由于用户容器OOM，导致异常退出，通过dmesg也没有查到任何异常日志。OOM论也被否定了。
  • 相同版本的kernel、docker版本，物理GPU节点为出现用户容器重启，只有在kvm vgpu上出现，也让人摸不着头脑。
  • 查看docker的日志，当用户容器异常退出时，就只有正常容器退出 clean up的信息，无其他异常日志。PS:其实此处才是澄清137问题的关键。
Feb 19 16:00:07 gpu-ser-xyz dockerd: time="2020-02-19T16:00:07.204930762+08:00" level=info msg="shim reaped" id=18b2fe723696358fb06317c427ab72777f430f074c8473612fad0fc99cbcb226
Feb 19 16:00:07 gpu-ser-xyz dockerd: time="2020-02-19T16:00:07.205071630+08:00" level=warning msg="cleaning up after killed shim" id=18b2fe723696358fb06317c427ab72777f430f074c8473612fad0fc99cbcb226 namespace=moby
Feb 19 16:00:08 gpu-ser-xyz dockerd: time="2020-02-19T16:00:08.305641212+08:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"
  • 【找同盟】
    • 为何出现exitCode=137？
      • Container exits with non-zero exit code 137 介绍了kill -9 (128 + 9) 触发的exitCode=137原因是容器stop时没有处理SIGTERM信号，进行容器优雅的退出。但是其本质还是用户容器异常退出了，不是正常stop操作。容器没有OOM，cpu、memory的监控利用率都没有超标，dmesg和messages日志中都没有异常信息，一度开始怀疑人生。
    • 类似社区137问题
      • Random task failures with "non-zero exit (137)" since 18.09.1 这个issue中作者从docker 18.09.0 升级到 18.09.1 (或者18.09.2)版本都会遇到137问题，也怀疑是OOM问题，但是实际应用没有出现OOM相关的日志现场。其中lwimmer把docker升级到18.09.3后未出现137问题，Ghostbaby用户把contianerd升级到1.2.5后也未出现137问题。Maintainer thaJeztah提了containerd 和runc 在18.09.2和18.09.3版本中差异。containerd/containerd@9754871...e6b3f56 opencontainers/runc@09c8266...6635b4f 结果就是升级没有出现137的问题了。

问题排查-之得细品

  • 【升级否】
    • 组内讨论了一波是否直接升级到docker 18.09.2之后的版本来解决137容器重启的问题。但是社区用户的环境毕竟和机器学习平台还是有差异，存在一些不确定性，在没有详细版本测试情况下，全量升级docker的版本，势必对用户环境稳定性有影响。而且物理GPU节点上部署同样的docker版本，并未出现此问题。保守起见，灰度了一部分节点，升级docker版本，确认是否会出现137问题。
    • 事实升级了docker版本还是会出现137问题。同时并行着再灰度一些containerd的版本。PS:升级了contianerd版本的节点未出现容器137问题。

50f84e343d8752afabef22f79bb3a85e.png
  • 【抓现场】
    • 从 Random task failures with "non-zero exit (137)" since 18.09.1 issue中发现了auditctl这个信号抓取的工具，可以澄清到底是哪个进程给容器发送了kill -9 信号。
# 配置捕获SIGKILL
auditctl -a always,exit -F arch=b64 -S kill,tkill,tgkill -F a1=0x9 -F key=trace_kill_9
  • 发现抓取到的现场确实是/usr/bin/nvidia-container-runtime把用户容器systemd进程kill了。因为GPU节点docker runtime都是使用nvidia-container-runtime。但是还是无法确认为什么被kill -9了。
time->Wed Feb 19 16:00:07 2020
type=PROCTITLE msg=audit(1582099207.232:3369619): proctitle=6E76696469612D636F6E7461696E65722D72756E74696D65002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D6E76696469612F6D6F6279002D2D6C6F672D666F726D6174006A736F6E0064656C657465002D2D666F72636500313862326665373233363936333538666230363331376334323761
type=OBJ_PID msg=audit(1582099207.232:3369619): opid=18848 oauid=-1 ouid=0 oses=-1 ocomm="systemd"
type=SYSCALL msg=audit(1582099207.232:3369619): arch=c000003e syscall=62 success=yes exit=0 a0=49a0 a1=9 a2=0 a3=0 items=0 ppid=14134 pid=23413 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nvidia-containe" exe="/usr/bin/nvidia-container-runtime" key="trace_kill_9"
  • 一方面为了抓取更多的docker日志，灰度一部分节点，打开docker debug日志开关。
  • 一方面为了确认是否有进程coredump的问题，把一些节点的coredump配置也打开，抓取问题现场。
  • 同时review docker的代码，发现容器创建运行的一个简单基本流程是dockerd -> containerd -> containerd-shim -> nvidia-container-runtime -> entrypoint。containerd-shim托管了容器的运行时状态，当contianerd-shim 异常退出时，会调用exitHandler 中进行cleanupAfterDeadShim操作触发kill -9。
  • 为了确认containerd-shim进程是异常退出，增加kill -15信号捕获。
# 配置捕获SIGTERM
auditctl -a always,exit -F arch=b64 -S kill,tkill,tgkill -F a1=0xF -F key=trace_kill_15

抓取到trace信号 -9 和-15，证明containerd-shim进程确实异常退出，具体还是需要确认是什么原因导致。

time->Thu Feb 20 22:47:19 2020
type=PROCTITLE msg=audit(1582210039.403:2649702): proctitle=6E76696469612D636F6E7461696E65722D72756E74696D65002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D6E76696469612F6D6F6279002D2D6C6F672D666F726D6174006A736F6E0064656C657465002D2D666F72636500666631613337626130303962396262396562303466633861643763
type=OBJ_PID msg=audit(1582210039.403:2649702): opid=2858 oauid=-1 ouid=0 oses=-1 ocomm="systemd"
type=SYSCALL msg=audit(1582210039.403:2649702): arch=c000003e syscall=62 success=yes exit=0 a0=b2a a1=9 a2=0 a3=0 items=0 ppid=24502 pid=6558 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nvidia-containe" exe="/usr/bin/nvidia-container-runtime" key="trace_kill_9"

time->Thu Feb 20 22:47:26 2020
type=PROCTITLE msg=audit(1582210046.181:2649752): proctitle="/usr/lib/systemd/systemd-udevd"
type=OBJ_PID msg=audit(1582210046.181:2649752): opid=6686 oauid=-1 ouid=0 oses=-1 ocomm="systemd-udevd"
type=SYSCALL msg=audit(1582210046.181:2649752): arch=c000003e syscall=62 success=yes exit=0 a0=1a1e a1=f a2=8 a3=bb8 items=0 ppid=1 pid=16425 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-udevd" exe="/usr/lib/systemd/systemd-udevd" key="trace_kill_15"

time->Thu Feb 20 22:47:42 2020
type=PROCTITLE msg=audit(1582210062.620:2649753): proctitle="/usr/sbin/init"
type=OBJ_PID msg=audit(1582210062.620:2649753): opid=7283 oauid=-1 ouid=0 oses=-1 ocomm="sshd"
type=SYSCALL msg=audit(1582210062.620:2649753): arch=c000003e syscall=62 success=yes exit=0 a0=bf a1=f a2=0 a3=ffffffc0 items=0 ppid=6661 pid=6683 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" key="trace_kill_15"

【起死回生】

  • containerd-shim 异常退出现场，看到在执行docker exec命令时，发生了panic: runtime error: invalid memory address or nil pointer dereference，显示代码访问空指针，contaienrd-shim进程异常退出，触发cleanupAfterDeadShim，导致用户容器异常退出。
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.374422177+08:00" level=debug msg="Calling POST /v1.39/containers/de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517/exec"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.374608247+08:00" level=debug msg="form data: {"AttachStderr":true,"AttachStdin":true,"AttachStdout":true,"Cmd":["ip","a"],"Detach":false,"DetachKeys":"","Env":null,"Privileged":false,"Tty":false,"User":"","WorkingDir":""}"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376137747+08:00" level=debug msg="Calling POST /v1.39/exec/0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef/start"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376236749+08:00" level=debug msg="form data: {"Detach":false,"Tty":false}"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376409211+08:00" level=debug msg="starting exec command 0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef in container de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377794937+08:00" level=debug msg="attach: stdin: begin"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377888031+08:00" level=debug msg="attach: stdout: begin"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377945302+08:00" level=debug msg="attach: stderr: begin"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.378383214+08:00" level=debug msg="Closing buffered stdin pipe"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.378459556+08:00" level=debug msg="attach: stdin: end"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.521401882+08:00" level=debug msg="event published" ns=moby topic="/tasks/exec-started" type=containerd.events.TaskExecStarted
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.522615348+08:00" level=debug msg=event module=libcontainerd namespace=moby topic=/tasks/exec-started
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.742957161+08:00" level=debug msg="event published" ns=moby topic="/tasks/exit" type=containerd.events.TaskExit
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.744535201+08:00" level=debug msg=event module=libcontainerd namespace=moby topic=/tasks/exit
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745009232+08:00" level=debug msg="attach: stderr: end"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745069071+08:00" level=debug msg="attach: stdout: end"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745086517+08:00" level=debug msg="attach done"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.749102092+08:00" level=debug msg="Calling GET /v1.39/exec/0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef/json"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.793241263+08:00" level=debug msg="Calling GET /v1.38/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0"
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.803366670+08:00" level=debug msg="Calling GET /v1.38/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0"
Feb 25 22:07:13 gpu-ser-xyz systemd: Removed slice User Slice of root.
Feb 25 22:07:13 gpu-ser-xyz dockerd: panic: runtime error: invalid memory address or nil pointer dereference
Feb 25 22:07:13 gpu-ser-xyz dockerd: [signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]
Feb 25 22:07:13 gpu-ser-xyz dockerd: goroutine 5 [running]:
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).pidv(...)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:76
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execStoppedState).Pid(0x8d8cf0, 0xffffffffffffffff)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec_state.go:175 +0x8
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).Pid(0xc4201e0000, 0x55ec)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:72 +0x34
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/shim.(*Service).checkProcesses(0xc42000e0c0, 0xbf8d68647291f929, 0xbec8633ef91e, 0x8bc720, 0x4308, 0x0)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:514 +0xde
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/shim.(*Service).processExits(0xc42000e0c0)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:492 +0xd0
Feb 25 22:07:13 gpu-ser-xyz dockerd: created by github.com/containerd/containerd/runtime/v1/shim.NewService
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:91 +0x3e9
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.874199295+08:00" level=info msg="shim reaped" id=de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517
Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.874266470+08:00" level=warning msg="cleaning up after killed shim" id=de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517 namespace=moby

问题分析-之论本质

  • 【从代码中来到代码中去】
    • 为什么在打开docker debug日志节点能抓到现场，线上其他vgpu上为什么没有出现SIGSEGV这个panic的问题。
      • containerd-shim出现panic时，因为containerd启动containerd-shim进程时，stdout/stderr都没有重定向到os的stdout/stderr上，所以在messages中没有找到任何panic信息。只有debug日志打开时，containerd-shim设置了重定向，才会有panic的日志输出。
if debug {
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
}
  • 为什么containerd-shim出现panic时，dmesg和/var/log/message中都没有相关segment fault的日志。
    • c/c++程序遇到segment fault都会在messages有类似的日志。
      segfault at 0 ip 00000000004005c7 sp 00007ffce36494f0 error 6 in main。因为containerd-shim是go程序，go的runtime catch到了SIGSEGV。当containerd-shim SIGSEGV 触发panic时，go runtime会调用runtime.crash，dieFromSignal(_SIGABRT) 实际 raise的是SIGABRT信号，所以dmesg和/var/log/message同时由于docker启动的时候，没有配置GOTRACEBACK=crash环境变量，默认是 GOTRACEBACK=single，ulimited -c 是0，也不会生成coredump文件。
  • 为什么容器中会有频繁的exec操作
    • 平台kubelet使用内网sdn接口获取ip，没有使用cni插件的方式，当每秒执行PLEG，检查Pod状态，通过docker exec -i ip a 获取Pod IP。
    • 频繁的exec操作，增加了containerd-shim触发exec bug概率。
  • 问题本质是exec.go代码 访问了空指针。
Feb 25 22:07:13 gpu-ser-xyz dockerd: panic: runtime error: invalid memory address or nil pointer dereference
Feb 25 22:07:13 gpu-ser-xyz dockerd: [signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]
Feb 25 22:07:13 gpu-ser-xyz dockerd: goroutine 5 [running]:
Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).pidv(...)
Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:76
  • 【从社区来到社区去】
    • containerd社区相关的issue，在1.2.2版本上抓到了和我们类似的现场，pid原来是int类型修改成safePid，加锁线程安全了。[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]
    • Fix exec race condition pr中已经解决2969此问题，1.2.3版本上合入了这个commit：5730c5003980f2b8c6d18188b56188230353ba81
    • 同时也能解释通升级到containerd 1.2.3之后的版本，容器未出现137问题

解决方案

  • 【降运维】
    • 在137问题根本原因未澄清前，为了减少用户容器异常退出带来的运维工作量。修改了kubelet 容器异常重启的策略，通过用户容器的标签信息，将平台实验环境vgpu的容器发生异常退出时，不在是容器重建，修改成容器重启。
    • 修改平台Daemonset hostNetwork=true的方式，不在使用sdn网络，减少exec操作。
  • 【开处方】
    • 问题本质原因是containerd execde bug，后续增量环境containerd升级至1.2.4版本。
    • 去除kubelet sdn网络exec获取容器IP的方式。
    • 使用平台自研的sdn cni网络插件，目前正在研发中。

参考文档

  • Container exits with non-zero exit code 137
  • STOPSIGNAL--与信号转发
  • Random task failures with "non-zero exit (137)" since 18.09.1
  • [signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]

作者：童超【滴滴出行资深软件开发工程师】

  • 现在注册滴滴云，得8888元立减红包
  • 7月特惠，1C2G1M云服务器 9.9元/月限时抢
  • 滴滴云使者专属特惠，云服务器低至68元/年
  • 输入大师码【7886】，GPU全线产品9折优惠
滴滴云-为开发者而生​www.didiyun.com
7d6cddd94809baef26654e8cc660ad79.png
滴滴云使者​www.didiyun.com
7d6cddd94809baef26654e8cc660ad79.png
Julia0505
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
项目线上在K8S 重启的问题排查
weixin_38872524的博客
10-16 904
项目线上在K8S重启的问题排查
docker中的hassio升级_【docker-ce】k8s集群docker容器异常重启问题分析
weixin_39720865的博客
11-29 354
背景目前机器学习平台后端采用k8s架构进行GPU和CPU资源的调度和容器编排。k8s的核心能力是容器编排，容器服务的稳定运行直接关系到整体平台的稳定性。春节值班期间，机器学习平台实验环境-隔离环境 vgpu资源出现比较多的用户容器异常退出问题。此问题导致Pod中的用户容器发生重建，一些用户在容器运行时环境的数据会丢失，由于平台具有暂存用户异常容器现场的能力，值班同学可以通过恢复用户异常容器现场来恢...
docker 导致宿主机重启的解决方法
vah101的专栏
12-20 1万+
宿主机操作系统为centos 7.4 在k8s运行一段时间报错： containerd: time="2019-12-19T21:50:49.070815105Z" level=info msg="shim reaped" id=6bdd3fe50ae41e731e7483e939612792d6c752ca0437525dc89103abacf22a8d dockerd: time="20...
Kubernetes故障排查指南-分析容器退出状态码
qq_24794401的博客
06-23 1万+
问题大家在使用 Kubernetes 时，会遇到创建Pod失败，这时会分析什么原因导致创建Pod失败？Pod status 状态解释 [1]CrashLoopBackOff：容器退出，k...
k8s 使用bash -c报错
weixin_45642669的博客
05-26 398
使用管道传参替代 bash -c 故障原因不是很清楚
03｜理解进程（2）：为什么我的容器里有这么多僵尸进程？
草办的学习记录
05-30 544
本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。 一、问题再现 例子：https://github.com/chengyli/training/tree/master/init_proc/zombie_proc 目的：在容器中弄出来很多个僵尸进程（Zombie Process）。 # docker run --name zombie-proc -d registry/zombie-proc:v1 02dec161a9e8b18922bd3599b922dbd087a2ad60c9b34afc.
Kubernetes(K8S)集群管理Docker容器（部署篇）
02-25
环境说明：操作系统：Ubuntu16.04orCentOS7Kubernetes版本：v1.8.3Docker版本：v17.09-ce均采用当前最新稳定版本。关闭selinux。打开下面网址，下载下面两个红色框框的包。...kubernetes-node-linux-amd64.tar.gz上传到...
docker-ce_18.06.3.ce-1_mips64el
04-01
对应文章：https://blog.csdn.net/SoaringLee_fighting/article/details/120777014 mips平台docker安装包！
docker-ce_18.06.3_ce_3-0_ubuntu_amd64.deb
08-15
docker-ce_18.06.3_ce_3-0_ubuntu_amd64的离线安装包。deb版本的。unubtu14.04的docker-ce离线包
docker容器化+k8s集群部署教程以及springboot+vue部署示例
04-11
本文介绍VMware虚拟机下centos7操作系统中如何安装云原生 Kubernetes（k8s）集群、k8s可视化界面kuboard，以及如何利用docker容器化将springboot+vue项目在k8s集群中部署运行。
k8s服务突然中断重启原因排查-eviction manager: must evict pod(s) to reclaim memory
d495435207的博客
05-13 2673
k8s服务突然中断重启,linux系统报错eviction manager: must evict pod(s) to reclaim memory
【Docker】Docker常用命令
kuangd_1992的博客
04-05 675
docker的常用命令
rpm查看安装软件的路径、日志
CN_Eden
03-01 1479
例如查看docker软件的安装列表 1.安装docker软件 [root@k8s-node1 ~]# yum install docker-ce-19.03.9-3.el7 -y 2.查看具体安装包名称 [root@k8s-node1 ~]# rpm -qa|grep docker docker-ce-19.03.9-3.el7.x86_64 docker-ce-cli-20.10.4-3.el7.x86_64 3.查看安装路径 [root@k8s-node1 ~]# rpm -ql docker-c
docker容器cpu或内存使用率超过指定值就重启的脚本
万物皆可学
07-05 1197
docker ps 查看所有容器 查看网关容器cpu、内存使用详情 我这里在home目录下新建了个.sh后缀结尾的脚本文件 命令如下 最后配置定时任务，每30s执行一次cpu40.sh脚本 由于每30秒查一次频率太高了，cpu和内存都正常情况下就不记录日志了，只记录超过使用率重启日志......
Container exited with a non-zero exit code 127
TURING.DT
04-13 9352
最近帮助一个朋友查看hadoop2.6.0部署的问题，群集可以正常启动， 但运行mapreduce wordcount时候，报错误 error: Container exited with a non-zero exit code 127 找了一天的原因，才发现core-site.xml中         hadoop.tmp.dir        /usr/hadoo
buffer/cach内存占用过高及k8s java后端pod容器超出内存限制被kill重启
热门推荐
Kainx
11-15 1万+
现象 之前某个后端服务pod在不停的重启导致线上环境很不稳定,于是开始分析问题的原因
journalctl 工具使用
weixin_30622181的博客
04-22 583
在Systemd出现之前，Linux系统及各应用的日志都是分别管理的，Systemd开始统一管理了所有Unit的启动日志，这样带来的好处就是可以只用一个 journalctl命令，查看所有内核和应用的日志。 journalctl 常用命令介绍 [root@node01 ~]# journalctl --help journalctl [OPTIONS...] [MATCHES...] ...
docker基础手册
河静
08-20 2411
docker常用命令 1.查看当前镜像 [root@centos7-docker ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest 08b152afcfae 3 weeks ago 133MB hello-world latest d1165f221234 5 months ago 13.3kB centos lat
docker容器cpu占用高排查
最新发布
05-31
当Docker容器的CPU占用率较高时，可以尝试以下步骤进行排查： 1. 查看容器的CPU占用情况： ``` docker stats <container-id> ``` 这个命令可以实时查看容器的CPU、内存、网络和磁盘等资源的使用情况。 2. 进入容器内部，查看具体的进程： ``` docker exec -it <container-id> bash top ``` 这个命令可以进入容器的bash终端，并查看容器内部的进程情况，从而确定哪些进程或应用程序在占用CPU资源。 3. 使用工具进行分析： - `htop`：可以在终端中以交互式方式查看系统进程和资源使用情况。 - `perf`：可以对进程进行性能分析，查看进程的CPU使用情况、函数调用等信息。 - `sysdig`：可以对系统进行全方位的监控和诊断，包括容器内部的进程和资源使用情况。 4. 修改容器配置： 如果发现某个应用程序在占用大量的CPU资源，可以考虑修改容器的配置，例如增加CPU核心数、限制CPU使用率等。 以上是针对Docker容器CPU占用高的一些排查方法，可以根据具体情况进行选择和调整。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值