-本文转自@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，内存，硬盘空间，甚至是网络等，防止侵害占用主机机的硬件资源