k8s排错---Accept error: accept unix /var/run/docker.sock: accept4: too many open files； retrying in 5m

报错现象：docker打开的文件句柄过多导致docker异常

• 从messages日志中获取到的信息

o old resource version: 188849596 (188851955)
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 5ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 10ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 20ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 40ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 80ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 160ms
Jul  3 17:01:34 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 320ms
Jul  3 17:01:35 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 640ms
Jul  3 17:01:35 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 1s
Jul  3 17:01:36 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 1s
Jul  3 17:01:37 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 1s
Jul  3 17:01:38 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: http: Accept error: accept unix /var/run/docker.sock: accept4: too many open files; retrying in 1s
Jul  3 17:01:39 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: time="2021-07-03T17:01:39.233596915+08:00" level=error msg="invalid image access: \"sha256:7f456dade28356d8fe54c4bf44a242c3f4720b938c6d87c4242e1b61b7f995a6\", error: \"failed to get digest sha256:7f456dade28356d8fe54c4bf44a242c3f4720b938c6d87c4242e1b61b7f995a6: open /var/lib/docker/image/overlay2/imagedb/content/sha256/7f456dade28356d8fe54c4bf44a242c3f4720b938c6d87c4242e1b61b7f995a6: too many open files\""
Jul  3 17:01:39 iZ2ze65tsjaqwt9pp6gjl7Z dockerd: time="2021-07-03T17:01:39.234122985+08:00" level=error msg="invalid image access: \"sha256:99e59f495ffaa222bfeb67580213e8c28c1e885f1d245ab2bbe3b1b1ec3bd0b2\", error: \"failed to get digest sha256:99e59f495ffaa222bfeb67580213e8c28c1e885f1d245ab2bbe3b1b1ec3bd0b2: open /var/lib/docker/image/overlay2/imagedb/content/sha256/99e59f495ffaa222bfeb67580213e8c28c1e885f1d245ab2bbe3b1b1ec3bd0b2: too many open files\""

临时解决：重启docker

systemctl daemon-reexec
systemctl restart docker

永久方案：修改内核参数

四种办法：

1、办法一：适用场景 – 单个进程打开文件句柄数过多

• ulimit中的nofile表示单进程可以打开的最大文件句柄数，可以通过ulimit -a查看，子进程默认继承父进程的限制（注意，是继承，不是共享，子进程和父进程打开的文件句柄数是单独算的）。

• 网上还有一种解读是nofile表示单用户可以打开的文件句柄数，因为他们在limit.conf中看到类似于“openstack soft nofile 65536”，便认为是openstack用户最多可以打开的文件句柄数。该解读是错误的，“openstack soft nofile 65536”表示的含义是当你执行"su - openstack"切换到openstack用户后，你创建的所有进程最大可以打开的文件句柄数是65536。

• 要查看一个进程可以打开的文件句柄数，可以通过“cat /proc//limits”查看。

• 要修改ulimit中的nofile，可以通过修改/etc/security/limits.conf文件，在其中加入类似“openstack soft nofile 65536”的语句来进行修改。修改完成后，可以通过“su - openstack”切换用户，或者重新登录，来使该配置生效。

• 要动态修改一个进程的限制，可以使用prlimit命令，具体用法为：“prlimit --pid ${pid} --nofile=102400:102400”。

2、办法二：适用场景—操作系统打开的文件句柄数过多

• 整个操作系统可以打开的文件句柄数是有限的，受内核参数“fs.file-max”影响。

• 可以通过执行“echo 100000000 > /proc/sys/fs/file-max”命令来动态修改该值，也可以通过修改"/etc/sysctl.conf"文件来永久修改该值。

3、办法三：适用场景 — systemd对该进程进行了限制

• 该场景仅针对被systemd管理的进程（也就是可以通过systemctl来控制的进程）生效，可以通过修改该进程的service文件（通常在/etc/systemd/system/目录下），在“[Service]”下面添加“LimitNOFILE=20480000”来实现，修改完成之后需要执行"systemctl daemon-reload"来使该配置生效。

4、办法四：适用场景 — inotify达到上限

• inotify是linux提供的一种监控机制，可以监控文件系统的变化。该机制受到2个内核参数的影响：“fs.inotify.max_user_instances”和“fs.inotify.max_user_watches”，其中“fs.inotify.max_user_instances”表示每个用户最多可以创建的inotify instances数量上限，“fs.inotify.max_user_watches”表示么个用户同时可以添加的watch数目，当出现too many open files问题而上面三种方法都无法解决时，可以尝试通过修改这2个内核参数来生效。修改方法是修改"/etc/sysctl.conf"文件，并执行"sysctl -p"。