背景：
修改了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