k8s错误CrashLoopBackOff

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是最好的编排器，而容器也是最底层的基本组成组件之一。

恍惚半生烂如泥，连笑都怕失了礼仪，看似明媚又光鲜，奈何自知力微薄。

所有的教养在收到指责后荡然无存。。。不要拿无知挑战黑名单。。。

k8s错误CrashLoopBackOff

原文：https://blog.51cto.com/15060545/2651516