序言
2020年1月1日就收到一个故障，注定不是平凡的一年。
所以呢，决定年后戒烟。。。至于是哪一年的年后，我没说。。。哈哈哈
CrashLoopBackoff
在创建一个pod之后，出现一个报错，都是按照套路来的，怎么可能会报错呢。。
查看一下相关的日志看看(kubectl describe pods test-pod)：
看最后的事件就是不停的重启失败的容器，查看一下容器的日志：
发现容器没有任何日志，查看一下容器是否启动：
发现容器是没有日志的，而且容器已经启动了，但是容器是正常退出的，毕竟状态码为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启动的时候，需要添加环境变量，如果没添加，那么也会出现这种报错，无限的重启循环。
从而可以修改创建的yaml文件，在其中直接添加相关运行的命令：
删除原来的，进行重新创建：
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是最好的编排器，而容器也是最底层的基本组成组件之一。
恍惚半生烂如泥，连笑都怕失了礼仪，看似明媚又光鲜，奈何自知力微薄。
所有的教养在收到指责后荡然无存。。。不要拿无知挑战黑名单。。。
