背景: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