- 本文转自 @TWT 社区。
【前言】至多，以 Docker 和 kubernetes 为代表的容器技术突飞猛进，但咱们在容器的应用过程中，也会碰到各种损坏和难题。出有针对性的阐明和解决方案，心愿能够帮忙到大家去疾速定位和解决相似问题故障。
具备超过十年的互联网运维及五年以上团队治理教训，多年容器云的运维，尤其是在 Docker 和 kubernetes 畛域十分精通。
Docker 是一种绝对应用较简略的容器，咱们能够通过以下几种形式获取信息：
1，通过 docker run 执行命令，或者返回信息
2，通过 docker logs 去获取日志，做有针对性的筛选
3，通过 systemctl status docker 查看 docker 服务状态
4，通过 journalctl -u docker.service 查看日志
以下是整顿的 docker 容器类问题故障，分为 9 个类
一，启动类故障
1，
docker：无奈通过 unix：///var/run/docker.sock 连贯到 Docker 守护程序。泊坞窗守护程序正在运行吗？
起因：Docker 未失常启动
解决形式：
systemctl 启动 docker
2，
无奈创立 Unix 套接字 /var/run/docker.sock：是目录
起因：docker.sock 不能创立
解决形式：
rm -rf /var/run/docker.sock
而后重新启动 docker
3，
docker.service 的作业失败。无奈启动 Docker 应用程序
起因：Selinux 引起
解决形式：
/ etc / sysconfig / selinux，将 selinux 值替换为禁用
重启 docker 解决
4，
泊坞窗：来自守护程序的谬误响应：
/ var / lib / docker / overlay / XXXXXXXXXXXXXXXXXXXXXXXXXX：无此类文件或目录。
起因：docker 没有指定目录或文件
解决形式：
systemctl 进行 docker
rm -rf / var / lib / docker / *
systemctl 启动 docker
重启 run 重新启动容器
5，
泊坞窗：来自守护程序的谬误响应：抵触。容器名称“XXX”已被容器“XXX”应用。您必须删除（或重命名）该容器能力重用该名称。
起因：码头工人名字重名
解决形式：
改名容器或者删除重建容器
6，
谬误：连贯激活失败：找不到适宜此连贯的设施
起因：网卡配置问题
解决形式：
重启网卡
7，
零碎重启后 docker 无奈启动
报错为：docker0：iptables：该名称没有链 / 指标 / 匹配
起因：docker 服务 iptables 问题
解决形式：
重启 docker 服务零碎重启 docker
8，
启动守护程序时出错：初始化 graphdriver 时出错：不反对驱动程序
应用 overlay2 存储驱动启动 docker daemon 报错
起因：daemon 经济配置
解决形式：
增加配置：
/etc/docker/daemon.json
{“存储驱动器”：“overlay2”，
“存储选项”：[“overlay2.override_kernel_check = true”]}
9，
无奈启动 docker.service：单位 docker.service 被屏蔽。
未知起因：docker 被遮罩
解决形式：
systemctl 勾销屏蔽 docker.service
systemctl 勾销屏蔽 docker.socket
systemctl 启动 docker.service
10，
无奈启动 docker.service：单元未正确加载：参数有效。
未知起因：docker 服务无奈失常加载
解决形式：
卸载 docker，删除 docker.service
重新安装 docker
11，
docker-compose 启动容器时报错：
/usr/lib/python2.7/site-packages/requests/init.py:80：RequestsDependencyWarning：urllib3（1.22）或 chardet（2.2.1）与反对的版本不匹配！RequestsDependencyWarning）
未知起因：pip 相应组件版本不反对
解决形式：
pip 卸载 urllib3
pip 卸载 chardet
点装置申请
12，docker 容器重启故障
强杀 docker 过程后，重启 docker。docker 中的容器无奈启动并报错
docker restart XXXXXXX 来自守护程序的谬误响应：无奈重新启动容器 XXXXXXX：容器“XXXXXXXXXXXXXXXX”：已存在
起因：旧容器未平安退出
解决形式：
docker-containerd-ctr –address /run/docker/containerd/docker-containerd.sock –namespace c rm < 容器 hash_id>
码头工人开始容器
13，
docker 重启谬误 - 重启命令始终卡住
systemctl 重新启动 docker 卡住
未知起因：可能是启动的容器数量过多，或者磁盘 IO 问题
解决形式：
systemctl 启动 docker-cleanup.service
systemctl 启动 docker
二，权限问题报错
14，
尝试连贯到 unix：///var/run/docker.sock 的 Docker 守护程序套接字时取得的权限被回绝
解决形式：
查看 /var/run/docker.sock 其中用户组
将用户重新加入 docker 组中，usermod -aG docker $ {USER}
15，
在步骤 GROUP 中应用 chown socket：没有此类过程
起因：docker 无奈找到 Group 组信息，docker 组有可能被误删除，
解决形式：
groupadd 泊坞窗
16，
公布 http：///var/run/docker.sock/v1.XXX / auth：拨打 unix /var/run/docker.sock：权限被回绝。您是否要连贯到没有 TLS 的启用 TLS 的守护程序？
起因：非 Root 用户治理 Docker 时，权限有余
解决形式：
groupadd 泊坞窗
usermod -a -G docker 用户
17，
码头工人犯错误
解决 tar 文件时出错（退出状态 1）：意外的 EOF
起因：可能是权限问题引起
解决形式：
chmod + x 加一个执行权限
三，总体和仓库问题报错
18，
获取 https://registry-1.docker.io/…
起因：Docker 仓库无法访问
解决形式：
批改 Docker 仓库源为国内或者自建的仓库源
批改 /etc/docker/daemon.json
19，推出本地可行性报错
推送指向存储库 [XXXX] 获取 https：// xxx / v1 / _ping：http：服务器向 HTTPS 客户端提供了 HTTP 响应
起因：docker Registry 未采纳 https 服务所致
解决形式：
/etc/docker/daemon.json 文件写入：
{“不平安的注册表”：[“”]}
20，
/ usr / bin / docker-current：来自守护程序的谬误响应：oci 运行时谬误：container_linux.go：启动容器过程导致“exec：\”/ bin / bash \”：在 $ PATH 中找不到可执行文件”。
起因：Docker 自身的固有问题或 Docker 引擎版本比拟低导致
解决形式：
能够降级 Docker 版本服务
21，精心设计，执行 chown - R 十分慢
起因：Docker 应用写时复制策略，所以 chown 命令执行时，将下层正本文件全副复制到以后层，而后再批改权限，再写入文件系统。
解决形式：
不应该应用 chown - R 类别大批量批改文件的命令
22，docker build 造就的的时候报错：
来自 syslogd 内核的音讯：unregister_netdevice：期待 lo 开释。应用次数 = 1
起因：docker engine 版本过高
解决形式：
docker 引擎版本须要和 docker 外部附加的内核版本匹配
23，
泊坞窗：来自守护程序的谬误响应：容器：容器未在指定的超时之前启动。ERRO[0133]从守护程序获取事件的谬误：上下文已勾销
起因：批改完 docker root dir，重启后，下载多个报错
解决形式：
重启 docker 服务
或者重启服务器
四，资源问题报错
25，
Docker 设施上没有残余空间
起因：空间有余
解决形式：清理空间，删除删除应用的容器，额定等资源
码头工人零碎修剪 -a
26，
/ var / lib / docker / containers 占用过大
起因：日志文件占用过大
解决形式：
cat / dev / null> * -json.log
或者
减少 dockerd 启动参数，/ etc / docker / daemon.json
{“log-driver”：“json-file”，
“log-opts”：{“max-size”：“2G”，“max-file”：“10”}
27，
最大虚拟内存区域 vm.max_map_count [65530]太低，至多减少到 [262144]
起因：零碎参数预设配置过小
解决形式：
批改 /etc/sysctl.conf 外面的 vm.max_map_count 调大
28，
无奈启动容器过程导致“process_linux.go：301：
正在运行的 exec setns 过程进行初始化，导致 \“退出状态 40 \”“：未知。
时
起因：可能是缓存问题引起
解决形式：
回声 1 > / proc / sys / vm / drop_caches
29，
docker 本机启动多台容器导致呈现后续容器启动失败
起因：查看硬盘空间是否满，如果不是硬盘空间问题引起
解决形式：
vim /etc/sysctl.conf
增加参数 fs.aio-max-nr = 1048576
sysctl -p
30，Docker 启动异样，状态重复重启
Docker 日志容器名，查看异样日志
查看 / var / log / 音讯
起因：内存跑满，引起 OOM
解决形式：
开释内存后，再启动容器
五，版本不兼容报错
31，
overlayfs：即便在 ext4 上，也无奈删除从根本层移至新创建的目录的文件
起因：Centos 提供的文件系统 XFS 和 Overlay 兼容问题导致，
解决形式：
这个问题的修复在内核 4.4.6 以上
32，
泊坞窗：来自守护程序的谬误响应：OCI 运行时创立失败：container_linux.go：344：启动容器过程导致“process_linux.go：297：从管道获取最终子过程的 pid 导致 \“读取 init-p：连贯被同级重置 \””：未知。
起因：Docker 版本和操作系统版本不匹配
解决形式：
重新安装和操作系统内核反对的 docker 版本
六，网络或端口问题报错
33，
正告：IPv4 转发已禁用。网络将无奈失常工作。
起因：ipv4 网络无奈转发
解决形式：
/usr/lib/sysctl.d/00-system.conf
在最初一行增加 net.ipv4.ip_forward = 1
重启网络服务。删除谬误的容器，再次创立新容器
34，
应用默认驱动程序创立网络“xxxxxxx”
起因：docker 网关抵触
启动容器，docker-compose 启动容器后，断网问题
解决形式：
配置 docker-compose.yml 内给启动器的容器配置参数 network_mode：“bridge”
35，
找不到满足以下条件的节点 [端口 xxxx]
起因：当容器应用端口映射（docker run -p xxxx：xxxx 或 compose 模板中的
ports）之后零碎会在主机上创立一个端口，通过 NAT 来拜访容器的指定端口。如果主机上的端口被容器或零碎过程占用，则会导致端口调配失败。
解决形式：
革除占用端口的容器或者过程，或调整容器端口映射的主机机端口防止抵触
36，
来自守护程序的谬误响应：名称为 xxx 的服务端点曾经
起因：端口曾经被占用
解决形式：
重启 docker 容器
37，
泊坞窗：来自守护程序的谬误响应：驱动程序无奈对端点 XXXXX 上的内部连贯进行编程：绑定 0.0.0.0:80 失败：端口已调配
起因：容器端口抵触
解决形式：
更换主机机绑定端口
七，Docker 装置报错
38，装置 docker 报要求：container-selinux> = 2.9
起因：container-selinux 版本低或者是没装置的起因
解决形式：
wget -O /etc/yum.repos.d/CentOS-Base.repo
http://mirrors.aliyun.com/rep…
百胜装置 epel-release
yum makecache
yum install container-selinux
39，装置 docker-compose 时报错
“ImportError：’ 模块 ’ 对象没有属性 ’check_specifier’”
起因：setuptools 版本问题
解决形式：
降级 setuptools 到 30.1.0 版本以上版本
pip install –upgrade setuptools
40，装置 docker-compose 时报错
申明：Python 2.7 将于 2020 年 1 月 1 日到期，请降级您的 Python，因为在该日期之后将不再保护 Python 2.7。pip 的将来版本将放弃对 Python 2.7 的反对。
起因：python2.7 提醒降级
解决形式：
点装置 -i https://pypi.douban.com/simple docker-compose
八，Docker 删除报错
41，docker 删除容器报错
来自守护程序的谬误响应：驱动程序笼罩无奈删除根文件系统 xxxxx：remove / var / lib / docker / overlay2 / xxxxx / merged：设施或资源忙碌
起因：容器挂载数据卷，无奈间接删除
解决形式：
grep docker / proc / * / mountinfo | grep xxxxx
kill 过程后
再从新删除容器
42，状态死机的容器删除报错
来自守护程序的谬误响应：驱动程序 aufs 无奈删除根文件系统 XXXXXXXXXXXXXXXX：aufs：重试后卸载谬误：/ var / lib / docker / aufs / mnt / xxxxxxxx：设施或资源忙碌
起因：dead 状态容器无奈删除，还在占用资源
解决形式：
docker rm -fv 容器 id 过几分钟后会主动删除
43，泊坞窗删除谬误报错
来自守护程序的谬误响应：抵触：无奈删除存储库援用“XXXX”（必须强制）- 容器 XXXX 正在应用其援用的映像 YYYY
起因：必然正在被某容器应用
解决形式：
须要删除相干 ID 容器后，能力删除
44，码头工人删除谬误报错
来自守护程序的谬误响应：抵触：无奈删除 XXXXXXXXXX（必须强制执行）- 在多个存储库中援用了图像
起因：从新登录 push 了更长的其余仓库
解决形式：
如果不须要此补充，docker rmi - f 强删
45，泊坞窗删除谬误报错
来自守护程序的谬误响应：抵触：无奈删除 XXX（无奈强制执行）- 图像具备相干的子图像
起因：存在依赖于父自身的子整合
解决形式：
强制删除或者或者批量删除容器，再删除更多
九，其余报错
46，docker：来自守护程序的谬误响应：驱动程序无奈对端点 XXXXXXX 上的内部连贯进行编程：（iptables 失败：iptables –wait - t 过滤器 -A DOCKER！-i docker0 -o docker0 -p tcp -d 172.17.0.2- -dport 8080 - j 承受：iptables：该名称没有链 / 指标 / 匹配。
起因：防火墙问题引起
解决形式：
敞开防火墙，重启 docker
47，
执行 docker info 呈现如下正告
正告：bridge-nf-call-iptables 已禁用
正告：bridge-nf-call-ip6tables 已禁用
起因：配置问题引起，须要启用 bridge-nf-call-iptables
解决形式：
vi /etc/sysctl.conf
增加以下内容
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
48，
docker 数据库相干报错
应用 Docker 创立 mysql 容器闪退
数据库未初始化，并且未指定明码选项
解决形式：
docker 运行 -d -e MYSQL_ROOT_PASSWORD = [明码] -p 3306：3306 mysql
为避免出现各种奇怪且偶发的问题，运维和开发人员应该有标准的去应用 docker 容器，最大水平的去防止因为使用不当而引起的故障，参考以下：
Docker 应用标准倡议
1. 尽量应用最近 1 - 2 年的新的稳固的 docker 版本
不要去装置往年前很老的版本，大量的 bug 曾经被新版本更新解决掉了
2. 尽量不要去发明十分大的代替，例如 5G10G 以上的
最好要轻量化，去除多余的软件，数据等
3. 容器内挂载宿主机配置，应用代替
容器须要 - v 主机的配置文件，尽量应用 ro 替换
4. 数据要挂载主机机物理硬盘或存储矩阵上
不要间接在容器里运行，防止容器停机机引起数据失落
5. 利用日志肯定要挂到宿主机上
不要间接打印到容器外部，防止只能 docker logs 形式查看，防止去 vulume 目录里查看日志
6. 不要只应用 latest 标签
标签要有个治理规范，能够依据标签查找对应版本
7. 不要应用容器 ip，配置里更不能写死（至多 172.17.0.x）
容器重启后，ip 很可能会变
8. 尽量不要在单容器内跑多过程
容器不是虚拟机，尽量做到 1 个容器，1 个过程
9. 跨环境可继续保持一致
相对是测试，UAT，生产环境，尽量放弃同一个正本，不要变更，环境变更只须要变更环境变量参数做区别
10. 肯定监控 docker 容器，即便发现问题
倡议应用 prometheus 监控容器
11. 肯定要限度 docker 容器的资源
尤其是 CPU，内存，硬盘空间，甚至是网络等，防止侵害占用主机机的硬件资源