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源创计划”，欢迎正在阅读的你也加入，一块儿分享。