容器总是有启动脚本，有的时候脚本有bug，从而造成容器的死循环。。。杀还是不杀。。。
杀？是凌迟处死？还是暴力强杀？。。。这个会触发微信的关键字过滤算法么。。。try。。。
风言风语环境不行，就只能靠人。。。人不行，就只能靠环境。。。瞎眼了解一下。。。
在一个生态系统中，无论你愿意不愿意，你总是在充当一个角色，内心是拒绝的？不可能的。。。
一直没搞清楚，为啥容器中还要运行一个容器，虽然知道是怎么实现的，但是却没搞清楚目的是为啥。。。直到看到了这张图。。。
在容器的生态系统中，runc是默认支持的，原来比较早的是使用lxc，而比较新颖的则是katacontaners，都是作为容器生态中的一部分，运行vm也只是一个其中的一个组件而已。。。
在使用docker的时候，可以看到默认使用的运行时环境：
在容器的生态系统中，存在这么多的运行时环境，而每个都有自己的特色，对于默认的runc来说，docker原生支持，而对于katacontainers能生存，主要的特色点在于推出了vm类型的容器，从而让容器运行在一个更安全，更隔离的环境中，而且能和宿主机的内核不同版本之下。。。
在运行一个vm的容器的时候，里面还可以运行容器，这个就涉及到一个规划的问题，在规划每个主机上运行的容器数量，是cpu密集型，还是io密集型，还是有状态的应用，还是无状态的应用，而且，如果使用的vm容器的隔离，那么子容器的隔离资源又怎么来设定。。。
在停止容器的时候，有几种方式，一种是直接docker stop表示kill -15来优雅杀死容器，所谓的优雅不过是保存一些相关的信息，比较安全的操作，当过一段时间之后，默认是10秒钟，如果没杀死，那就会使用kill -9强制杀死。。。
在杀容器的时候，也可以使用docker kill，这种可以直接传递信号过去杀，这个时候，就看你是不是要直接强杀了，例如docker kill -s 9 containerid。。
还有一种杀法，其实容器的运行，对于操作系统来说，也只是运行在用户空间的一个进程，从而可以直接杀死进程。。。
在杀死容器之后，可以看到容器的退出码为137，表示容器是被杀的。。。留下了事故现场。。。哈哈
还有一种可能就是，容器的进程变成了僵尸进程，这个时候，无论你是stop，还是kill，还是kill -9 都是不可能杀死的，毕竟defunc也不是那么好容易对付的。。
这个时候，就要杀死父进程了，在一般的情况下来说，运气好的话，父进程就是containerd-shim，杀这个就无所谓了。。。嗯，这个需要在操作系统层面来杀。。。
运气不好怎么办？不怕，毕竟靠运气也是一种战略。。。一不小心父进程是dockerd，那么，一杀，本系统上面的所有容器会全部挂掉。。。当时没试试重启dockerd进程。。。没准也可以。。。强杀有风险。。。运气更不好，就是父进程是init了，那么就只能重启操作系统了。。。
强扭的瓜不甜，小心小心。。。虽然容器都有ha，但是依旧有很大压力，毕竟服务可能会造成中断 。。。
昨夜观天象，感觉略有不妥。。。
在使用容器的时候，有几个需要注意的地方，一个是镜像，一个容器，而对于容器来说，使用的是export保存为tar，然后用import做为镜像；而对于镜像来说，是使用save保存镜像，而使用load来加载为本地的镜像。
风太大，我听不见。。。耳朵漏风。。。
使用export和import的时候，会丢失相关的信息。
使用save和load的时候，镜像不会丢失相关layer的信息。。。
僵尸进程，杀还是不杀，不杀，占用资源，杀。。。可能代价很大。。
在一个恶劣的生态系统中，想独善其身。。。很难。。。如何改善整体的生态，很好玩。。。。