背景：
修改了configmaps之后，重启pods，Kubernetes中pods一个失败、一个runing：
分析思路：
1.查看问题pods：
1.1.表现：pods数量频繁变化：因为pods不断陷入（create-error-create）的循环。
1.2.说明：
replicas设置为2。故 原始pod一个，状态正常；新pod一个，一直失败
MiniumReplicasAvailable设置为1。此时看到了这个配置的重要性啊，要不全挂了，服务不可用。如果不能立即找出问题，并解决。。。如果是线上出现了此类问题，就是活生生的生产事故啊，细思极恐！
2.一度以为是kubectl的问题；结果查找方向完全错误
3.领导大人出马之后，对比pods配置之后，重大发现：pods指定的image版本不同。问题定位成功！
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