容器无限重启

序言

    睡一觉,又是新的一天,年复一年。。。日复一日。。。年年日日共今朝。。。


    双十一就快到了,各位单身狗,在通往相亲的路上拥挤么。。。哈哈

背景

    在使用容器的时候,有众多的选项供我们选择,也就是dockerd --help的各种选项,当修改了dockerd的配置的时候,需要重新加载配置文件或者重启。。。或者对容器进行升级,那么这个时候就有一个选项live-restore为true,从而可以试试这个选项。

640?wx_fmt=png


    随便启动了elk容器玩玩,嗬。。。发现打死都不能启动。。。在启动的时候,感觉整个vm都挂了。。。


640?wx_fmt=png


    嗯,至此。。进入了无限重启的循环。

解决之道

     既然容器进入了一个循环,,查看相关的系统日志,变更导致的故障?就因为我修改了dockerd的一个参数???好吧。。。先回滚。。。


    回滚之后,发现依旧是无限重启。。。看看内存。。。    嗯。。发现内存不够,看了看容器的最低内存配置,发现至少需要2G,好吧,给你2G。。。呵,容器,说好的不依赖底层环境呢,说好的一次镜像到处浪呢,尼玛,怎么浪不起来了。。。朕给你的才是你的,朕不给你、你不能抢。。。


640?wx_fmt=png


    给了2G内存,发现不卡了,世界一下清净了。。。但是,你给我打印一个info就挂了,是什么意思,到底是啥意思。。。

   

    那么就查看一下是不是OOM被杀了。。。呵,JAVA写的。。。

640?wx_fmt=png


    从上面可以看到,并不是因为内存的限制导致被OOM杀了,但是却明明白白的重启了四次。。。那么再次查看一下重启的策略。。。

640?wx_fmt=png


    呵呵,居然是无限重启。。。重启的次数还没有限制。。。在一般的镜像中,都是不会设置这种无限重启的策略的,这个elk的镜像还是有点意思的,居然直接将策略帮我设置好了。。。


    系统总是会出问题的,总是在你意想不到的地方出现问题。。。容器日志没有出错的地方,查看dockerd的日志,也是好的。。。好像。。。陷入了困境。。


    这个时候,好像已经无解了,那么。。。就只能找人问问这是为啥了,这个JAVA进程启动到一半挂了。。挂了。。。为啥。。。


    闲着无聊,查看一下系统的top,看看性能参数。。。

640?wx_fmt=png

    哎哟,这一看不得了,系统好像很繁忙的样子,毕竟。。。只有一颗CPU,那么。。。增加一个CPU试试。。。成就不够,时间来凑。。。

640?wx_fmt=png


    嗬,居然启动成功了。。。。说好的不依赖底层环境的。。呵,容器。。。当然,只能说运行一次成功之后,然后再次进行移植是没问题的。。重启后性能如下。。。呵,JAVA。。。


640?wx_fmt=png

    

    至此问题解决,主要原因就是因为内存和CPU不足,然后重启策略是无限重启,从而导致容器进入了重启循环。。。

640?wx_fmt=png

风言风语

    最近总是发现有几个虚拟机无辜重启,对,是无辜的。。。也不知道是啥原因。。。最后发现是物理机宕机,虚拟机自动迁移了,在用户层面的表现就是,重启了,为毛啊。。。你猜,我就不告诉你,内核崩溃了。。。(uptime查看重启是否一致)


    本来准备玩玩消息队列的,毕竟玩的少。。。最后折腾了一把无限重启。。。孟婆汤了解一下,喝了就当是重启了。。。


    标签,我们总是喜欢打标签,例如你是个逗比,他是个傻逼。。。各种label,从而,无论是在监控系统中,还是在日志系统中,都可以引入标签,标签可以有多种,环境分类,生产,预生产,测试,开发等;系统分类,某某系统,某系统。。。好像也没啥魔力,在k8s中,pod也是根据标签找到相关的容器。。。


    举一反三的能力。。。嗯。。。有点意思。


    有的时候看各种熟悉的东西,我草,那看书的速度。。。一天恨不得一本书;看不熟悉的东西,我草,头疼,那看书的速度。。。还要配合谷歌翻译才能看的懂。。。


    在编程中,我们要使用各种数据结构,那么你为什么要选择list而不是map或者dictionary?我要是说。。。冥冥之中我就感觉这个不错,估计你也不能信服。。。那就只能说,每种数据结构都有合适的地方,有序的还是无序的?我选择list的时候,是不是考虑了高性能,高扩展性?我选择了map是不是因为如果这个数据量很大很大的时候,性能依旧不降低。。。嗯。。吹牛逼了解一下。。。其实我就是靠赶紧用各种数据结构的,但是。。。你们非要听我吹。。。


    写一个程序,不就调用一堆的模块或者API接口么,有什么了不起的。。。其实,我也觉得没啥了不起的,也的确是调用了几个API,调用了几个模块,那么一百人对于同一个问题有一百种写法,每一种伟大的程序也是调用了几个API,那么牛逼在哪儿?客户使用起来简单,性能高,扩展性好,使用了各种设计模式。。。复用程度高,你接口不断变化,我能不断的适应,我能兼容你的各种接口。。。Emmm。。不知道怎么吹了。。。


    编程,功能的实现好像每个人都会,那么每个人写的到底是BUG还是程序,就看你的程序运行起来,能完美的避过多少坑。。。Emmm,只写BUG了解一下。。。


    我在等,等每一个坑的轮回。。。嗯,每个人都不想碰到坑,各种异常的情况,能跑多远,能走的多块,就看你绕开的速度了。。。Emmm,好像是这样。。。


    所谓的八二法则,花了百分之二十的时间实现功能,其他的百分之八十的代码就是为了捕获异常,就是为了让程序极度的健壮。。。Emmm,我是吹牛逼的。。。


640?wx_fmt=jpeg

    有没有感觉自己就是一个BUG,不断的调试,不断的优化,不断的重构,只是为了适应这个社会快速的发展,只是为了适应业务的高速发展。。。

我们不是真的怕失去,而是怕没有更好的替代。。。

瞎说什么大实话。。。

so boring。。


  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值