一次docker错误的耗时排查过程记录

1480144907 发布于2022-10-25 17:50 / 858人阅读

docker环境信息:

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 18.09.3
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc version: 6635b4f0c6af3810594d2770f662f34ddc15b40d
init version: fec3683
Security Options:
 seccomp
 Profile: default
Kernel Version: 3.10.0
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 20
Total Memory: 125.3GiB
Name: eds-1f21a854
ID: VZLV:26PU:ZUN6:QQEJ:GW3I:YETT:HMEU:CK6J:SIPL:CHKV:6ASN:5NDF
Docker Root Dir: /data/kube/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 reg.wps.lan:5000
 treg.yun.wps.cn
 127.0.0.0/8
Registry Mirrors:
 https://registry.docker-cn.com/
 https://docker.mirrors.ustc.edu.cn/
Live Restore Enabled: false
Product License: Community Engine

系统的信息

$ uname -a
Linux eds-1f21a854 3.10.0 #1 SMP Mon Sep 28 12:00:30 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

服务器的信息

$ cat product_name
SUGON-60G16
$ cat sys_vendor
SANGFOR
$ cat product_version
1.2

排查的过程

安装docker的时候服务器挂了，开机后看不到信息，只能恢复快照才能进去，客户无法查看

　　然后通过向日葵远程连接，发现是基于 centos 改过的，没找到/var/log/message，不是常规的操作系统，然后手动执行docker 安装脚本。

bash -x install-docker.sh

　　看了下服务器是”正常开机”的，但还是连不上，问我们的操作是否是改了路由，现场 systemctl 看了下 docker 是起来的。还是 ping 不通网关。发现没挂。

　　然后发现是 iptables 的问题， docker启动的时候规则刷没了。然后改了下可以了。所以实际上是iptables的影响导致网络断开，机器没重启。

　　启动容器挂掉

　　然后他们说启动的时候出现上面的问题，我就手动执行下部署，结果报错。

手动执行：

$ docker load -i ./kube/images/deploy.tar
error during connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

另开一个终端执行 load 镜像操作:

$ docker load -i ./kube/images/deploy.tar
ab6425526dab: Loading layer [==================================================>] 126.3MB/126.3MB
c7fe3ea715ef: Loading layer [==================================================>] 340.3MB/340.3MB
7f7eae7934f7: Loading layer [==================================================>] 3.584kB/3.584kB
e99a66706b50: Loading layer [==================================================>] 2.105MB/2.105MB
245b79de6bb7: Loading layer [==================================================>] 283.5MB/283.5MB
2a56a4432cef: Loading layer [==================================================>] 93.18kB/93.18kB
0c2ea71066ab: Loading layer [==================================================>] 276.5kB/276.5kB
bb3f6df0f87c: Loading layer [==================================================>] 82.94kB/82.94kB
6f34ead3cef7: Loading layer [==================================================>] 946.7kB/946.7kB
c21422dd15f6: Loading layer [==================================================>] 1.97MB/1.97MB
940288517f4c: Loading layer [==================================================>] 458.2kB/458.2kB
0c52f1af61f4: Loading layer [==================================================>] 5.12kB/5.12kB
049e7edd48bc: Loading layer [==================================================>] 1.57MB/1.57MB
73307245d702: Loading layer [==================================================>] 5.632kB/5.632kB
f109309d8ffc: Loading layer [==================================================>] 2.175MB/2.175MB
Loaded image: xxxxxxxxxxxx.cn/platform/deploy-amd64:ubuntu.16.04
$ docker images
REPOSITORY    TAG   IMAGE ID  CREATED  SIZE
xxxxxxxxxxxx.cn/platform/deploy-amd64 ubuntu.16.04 3ad94a76af5d 3 months ago 734MB

前台日志输出正常

...
DEBU[2020-10-30T14:48:39.955963986+08:00] Applied tar sha256:049e7edd48bc46e3dd5edf89c9caa8f0f7efbb41af403c5a54dd4f1008f604a7 to d58edd0d97bb672ef40e82e45c1603ca3ceaad847d9b9fc7c9b0588087019649, size: 1518278
DEBU[2020-10-30T14:48:39.960091040+08:00] Applying tar in /data/kube/docker/overlay2/b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18/diff storage-driver=overlay2
DEBU[2020-10-30T14:48:40.059510528+08:00] Applied tar sha256:73307245d7021f9627ca0b2cbfeab3aac0b65abfd476f6ec26bb92c75892d7e2 to b044bd592ae800ed071208c6b2f650c5cbdc7452702f56a23b9b4ffe4236ac18, size: 3284
DEBU[2020-10-30T14:48:40.063040538+08:00] Applying tar in /data/kube/docker/overlay2/03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f/diff storage-driver=overlay2
DEBU[2020-10-30T14:48:40.148209852+08:00] Applied tar sha256:f109309d8ffcb76589ad6389e80335d986b411c80122d990ab00a02a3a916e3e to 03918b1d275aa284532b8b9c59ca158409416f904e13cc7084c598ed343e844f, size: 2072803
^CINFO[2020-10-30T14:48:55.593523177+08:00] Processing signal 'interrupt'
DEBU[2020-10-30T14:48:55.593617229+08:00] daemon configured with a 15 seconds minimum shutdown timeout
DEBU[2020-10-30T14:48:55.593638628+08:00] start clean shutdown of all containers with a 15 seconds timeout...
DEBU[2020-10-30T14:48:55.594074457+08:00] Unix socket /run/docker/libnetwork/ebd15186e86385c48c4c5508d5f30eb83d5d74e56f09af5c82b6d6d9d63ec8b8.sock doesn't exist. cannot accept client connections
DEBU[2020-10-30T14:48:55.594106623+08:00] Cleaning up old mountid : start.
INFO[2020-10-30T14:48:55.594157536+08:00] stopping event stream following graceful shutdown error="<nil>" module=libcontainerd namespace=moby
DEBU[2020-10-30T14:48:55.594343122+08:00] Cleaning up old mountid : done.
DEBU[2020-10-30T14:48:55.594501828+08:00] Clean shutdown succeeded
INFO[2020-10-30T14:48:55.594520918+08:00] stopping healthcheck following graceful shutdown module=libcontainerd
INFO[2020-10-30T14:48:55.594531978+08:00] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=plugins.moby
DEBU[2020-10-30T14:48:55.594603119+08:00] received signal    signal=terminated
INFO[2020-10-30T14:48:55.594739890+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0, TRANSIENT_FAILURE module=grpc
INFO[2020-10-30T14:48:55.594751465+08:00] pickfirstBalancer: HandleSubConnStateChange: 0xc4201a61b0, CONNECTING module=grpc

试了一下 load 其他镜像，结果可以。

$ docker load -i kube/images/pause_3.1.tar
e17133b79956: Loading layer [==================================================>] 744.4kB/744.4kB
Loaded image: mirrorgooglecontainers/pause-amd64:3.1
$ docker load -i kube/images/tiller_v2.16.1.tar
77cae8ab23bf: Loading layer [==================================================>] 5.815MB/5.815MB
679105aa33fb: Loading layer [==================================================>] 6.184MB/6.184MB
639eab5d05b1: Loading layer [==================================================>] 40.46MB/40.46MB
87e5687e03f2: Loading layer [==================================================>] 41.13MB/41.13MB
Loaded image: gcr.io/kubernetes-helm/tiller:v2.16.1
$ docker load -i kube/images/calico_v3.1.3.tar
cd7100a72410: Loading layer [==================================================>] 4.403MB/4.403MB
ddc4cb8dae60: Loading layer [==================================================>] 7.84MB/7.84MB
77087b8943a2: Loading layer [==================================================>] 249.3kB/249.3kB
c7227c83afaf: Loading layer [==================================================>] 4.801MB/4.801MB
2e0e333a66b6: Loading layer [==================================================>] 231.8MB/231.8MB
Loaded image: calico/node:v3.1.3
2580685bfb60: Loading layer [==================================================>] 50.84MB/50.84MB
Loaded image: calico/kube-controllers:v3.1.3
0314be9edf00: Loading layer [==================================================>] 1.36MB/1.36MB
15db169413e5: Loading layer [==================================================>] 28.05MB/28.05MB
4252efcc5013: Loading layer [==================================================>] 2.818MB/2.818MB
76cf2496cf36: Loading layer [==================================================>] 3.03MB/3.03MB
91d3d3a16862: Loading layer [==================================================>] 2.995MB/2.995MB
18a58488ba3b: Loading layer [==================================================>] 3.474MB/3.474MB
8d8197f49da2: Loading layer [==================================================>] 27.34MB/27.34MB
7520364e0845: Loading layer [==================================================>] 9.216kB/9.216kB
b9d064622bd6: Loading layer [==================================================>] 2.56kB/2.56kB
Loaded image: calico/cni:v3.1.3

发现导入这个的时候会报错

$ docker load -i kube/images/deploy.tar
error during connect: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/images/load?quiet=0: read unix @->/var/run/docker.sock: read: connection reset by peer

云服务器混合云 php 错误排查 php存储过程记录集记录错误最近一次的登录时间

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/128207.html

记一次网络问题的排查

摘要：昨天遇到了一个端口转发导致失效的问题，今天记录下当时的排查思路。问题原因是删除容器后没有把转发规则删除。这次排查，用到了几个工具，都是之前的积累，所以排查显得顺畅多了。昨天遇到了一个端口转发导致VIP失效的问题，今天记录下当时的排查思路。因为要做升级，所以我删除了dokcer老容器，并启动新容器。之后访问VIP, 也就是LVS中的VIP，发现原先可以访问的站点不能访问了。以上是故...

springDevBird 2019-06-24 17:13 评论0 收藏0
记一次网络问题的排查

摘要：昨天遇到了一个端口转发导致失效的问题，今天记录下当时的排查思路。问题原因是删除容器后没有把转发规则删除。这次排查，用到了几个工具，都是之前的积累，所以排查显得顺畅多了。昨天遇到了一个端口转发导致VIP失效的问题，今天记录下当时的排查思路。因为要做升级，所以我删除了dokcer老容器，并启动新容器。之后访问VIP, 也就是LVS中的VIP，发现原先可以访问的站点不能访问了。以上是故...

AprilJ 2019-06-28 15:18 评论0 收藏0
【译】深入理解G1的GC日志（一）

摘要：表示允许垃圾收集线程处理本次垃圾收集开始前没有处理好的日志缓冲区，这可以确保当前分区的是最新的。垃圾收集线程在完成其他任务的时间展示每个垃圾收集线程的最小最大平均差值和总共时间。本文翻译自：https://www.redhat.com/en/blog/collecting-and-reading-g1-garbage-collector-logs-part-2?source=auth...

spacewander 2019-08-16 18:39 评论0 收藏0
在生产环境中使用LogRocket记录Redux日志--sitepoint

摘要：在生产环境，记录和，使得理解和用户上报的变得容易了在这篇文章中，我将会向你展示如何使用来记录日志。在生产环境记录数据非常有用，因为和用户上报的问题，可以通过查看状态网络请求和来进行调试排查。原文链接在web应用中排查问题很难。那些难解的js错误，用户上报的bug，还有QA系统里的issue，解决这些影响用户的问题是永恒不变的斗争。这些还只是那些明显的问题，事实是大部分的bug从来都...

cppowboy 2019-08-20 18:13 评论0 收藏0
前端错误监控与收集探究

摘要：这样很容易造成大的损失，提前做好错误收集和处理，可以减少损失。编写代码只是做好项目的一小部分，写代码难免会碰到错误。因此，在项目上线后，我们还需要主动对项目的错误进行收集，不能等用户发现错误，再联系我们，我们再去处理。这样很容易造成大的损失，提前做好错误收集和处理，可以减少损失。本人并没有做过相关的工作，下面的文章只是我在学习中的一点思考和总结，可能有比较多不足和错误的地方，希望大...

ZoomQuiet 2019-08-22 16:02 评论0 收藏0