2020年1月1日就收到一個故障，註定不是平凡的一年。
javascript
因此呢，決定年後戒菸。。。至因而哪一年的年後，我沒說。。。哈哈哈
java
在建立一個pod以後，出現一個報錯，都是按照套路來的，怎麼可能會報錯呢。。mysql
查看一下相關的日誌看看(kubectl describe pods test-pod)：
sql
看最後的事件就是不停的重啓失敗的容器，查看一下容器的日誌：
docker
發現容器沒有任何日誌，查看一下容器是否啓動：
bash
發現容器是沒有日誌的，並且容器已經啓動了，可是容器是正常退出的，畢竟狀態碼爲0，查看messages日誌，看看有沒有其餘的報錯信息：
微信
Feb 28 04:50:27 dockermaster kubelet: E0228 04:50:27.861552 6256 pod_workers.go:190] Error syncing pod 68581c76-5a06-11ea-8ebf-ba810801ac07 ("test-pod_default(68581c76-5a06-11ea-8ebf-ba810801ac07)"), skipping: [failed to "StartContainer" for "container-1" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=container-1 pod=test-pod_default(68581c76-5a06-11ea-8ebf-ba810801ac07)"Feb 28 04:50:27 dockermaster kubelet: , failed to "StartContainer" for "container-2" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=container-2 pod=test-pod_default(68581c76-5a06-11ea-8ebf-ba810801ac07)"
發現有報錯信息error syncing pod，啓動容器以後失敗，從而造成了崩潰循環。
運維
此報錯信息表示：容器進程崩潰或者退出，也就是容器沒有在後臺運行的進程，從而致使此種狀況，有的時候是容器報錯了，例如mysql啓動的時候，須要添加環境變量，若是沒添加，那麼也會出現這種報錯，無限的重啓循環。
oop
從而能夠修改建立的yaml文件，在其中直接添加相關運行的命令：
ui
刪除原來的，進行從新建立：
mysql進程退出的以下圖所示：
在這裏能夠看到相關的日誌，能夠查看到環境變量的缺失，並且在查看容器的時候，能夠看到容器的退出碼爲1，表示容器的進程崩潰。
查看messages日誌能夠看到kubelet報錯是相似的：
Feb 28 05:18:35 dockermaster kubelet: E0228 05:18:35.860866 6256 pod_workers.go:190] Error syncing pod 2ceaa659-5a12-11ea-8ebf-ba810801ac07 ("test-pod_default(2ceaa659-5a12-11ea-8ebf-ba810801ac07)"), skipping: failed to "StartContainer" for "container-1" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=container-1 pod=test-pod_default(2ceaa659-5a12-11ea-8ebf-ba810801ac07)"
崩潰就像龍捲風。。。一次不成功，會再次重試，會一直重試，也就致使了crash loop。。。就像戒菸，不停的戒菸。。。
遇事也是同樣的，當你碰到那種對人不對事的，哎喲，有意思了，好玩了。。。就像遇到了251，是可忍孰不可忍，雖然沒什麼卵用，可是，說。。。仍是要說的。
雲原生，生在雲上，長在雲上，k8s是最好的編排器，而容器也是最底層的基本組成組件之一。
恍惚半生爛如泥，連笑都怕失了禮儀，看似明媚又光鮮，奈何自知力微薄。
全部的教養在收到指責後蕩然無存。。。不要拿無知挑戰黑名單。。。
本文分享自微信公衆號 - SRE運維實踐（gh_319dd73ec076）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。