生产环境中,对于运维来说,可能不需要亲自去编写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