生产环境中，对于运维来说，可能不需要亲自去编写Dockerfile来构建镜像，大多数是研发部门来做这个事情，但我认为运维岗位有必要清楚Dockerfile的构建过程，再不济也应该知道运行这个image时，最后的进程是怎么样的，这会更有利于测试维护。
在我的公司来说，底层运维和研发是搭不上话的，更别说了解Dockerfile了，这就需要自己来研究。
今天客户让检查Kubernetes环境，说是环境起不来了，我通过远程ssh，结果发现ssh无法连接，客户方检查结果为内存oom溢出（环境已运行半年），因为是测试环境故而将服务器重启，内存被释放。然后我检查Kubernetes环境，发现大多数pod无法启动，状态为ImagePullBackOff和Evicted，还有NodeAffinity。
ImagePullBackOff：镜像下载失败，意味着本地没有镜像
Evicted：一般可以查看到
describe信息，我见过的此状态都是磁盘容量问题NodeAffinity：调度节点亲和性失败
偶然的一次机会，解决项目故障的分析过程中，看到项目中有研发团队写好的Dockerfile，居然出现了两个FORM，吸引了我的眼球。和我自己之前写过的文章 Dockerfile构建简单镜像 有所不同，决定一探究竟。
涉及到docker的几个配置文件
/etc/docker/daemon.json # 启动配置文件
/root/.docker/config.json # 启动配置文件
/etc/systemd/system/docker.service # 启动文件
这里使用nfs为PV&PVC做后端存储
[root@node1 ~]# yum -y install nfs-utils rpcbind
[root@node1 ~]# mkdir /nfsdata/mysql_pv
[root@node1 ~]# vim /etc/exports
/nfsdata *(rw,no_root_squash,sync)
[root@node1 ~]# exportfs -r
[root@node1 ~]# systemctl start rpcbind nfs-server
[root@node1 ~]# systemctl enable rpcbind nfs-server试想一个场景
现在有一个正常运行的多副本应用，要对应用进行更新（比如更新image），Kubernetes会启动新副本来代理旧副本，然后发生了以下事件：
1、正常情况下新副本需要10s左右来完成准备工作，在此之前无法响应更新后的业务请求。
2、但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）
这个环境是生产环境中的真实项目，仅做参考 通过Docker+k8s来部署web集群，GitLab+Jenkins实现代码自动化部署，在Jenkins中通过构建脚本，实现k8s对容器web集群代码自动更新
1 / 4
