背景:git
修改了configmaps以后,重启pods,Kubernetes中pods一个失败、一个runing:bash
分析思路:spa
1.查看问题pods:blog
1.1.表现:pods数量频繁变化:由于pods不断陷入(create-error-create)的循环。it
1.2.说明:变量
replicas设置为2。故 原始pod一个,状态正常;新pod一个,一直失败配置
MiniumReplicasAvailable设置为1。此时看到了这个配置的重要性啊,要不全挂了,服务不可用。若是不能当即找出问题,并解决。。。若是是线上出现了此类问题,就是活生生的生产事故啊,细思极恐!循环
2.一度觉得是kubectl的问题;结果查找方向彻底错误map
3.领导大人出马以后,对比pods配置以后,重大发现:pods指定的image版本不一样。问题定位成功!command
kubectl edit pods * -n namespace
4.解决:修改deployments,将image版本回滚到正确版本
kubectl edit deployments * -n namspace
而后重启pods便可。
5.临时方案搞定,但问题来了:如何找到是谁发布的,团队合做人这么多?
5.1若是pods正常运行,没问题。直接进入pods中,查看环境变量便可知道。
kubectl exec -ti /bin/bash -n namespace
why?哈哈。。。秘密武器来了,大领导在image push到镜像仓库之时,作了两项工做:
1.git 代码没提交、不是最新版本,不能够push image(防止团队之间,代码覆盖)
2.image push时,将git command id 、push image的操做人、push image的操做日期、git branch的版本信息(或,tag信息),做为环境变量存入了image中。
有了以上两部的,天然能够定位责任人、提交版本、git提交负责人。
5.2.可是目前pods没有启动,怎么办?
5.2.1 image pull 到本地
5.2.2.1 方式一
5.2.2.2 方式二
Done