那么对于这个方法,最需要注意的问题是,容器本身是“单进程”模型。(这并不是意味着容器只能跑一个进程。)
而是说因为容器=应用=进程,所以只能管理PID=1的进程,而其他再跑起来的进程,只能认为是托管状态。所以说除非应用进程具备“进程管理”能力,即helloworld程序需要具备systemd的能力。或者将容器的Pid=1的进程改成systemd,而这样会导致管理容器=管理systemd!=直接管理应用本身。
而如果不具备systemd的能力,那么一旦PID=1的进程kill或者死掉了,那么剩下3个进程的资源没有进行回收,那么这是一个很严重的问题。
总结的来说,一旦容器启动了多个进程,那么只能有一个PID=1的进程,而如果PID=1的进程挂了,那么就会没人回收剩下3个应用的回收,而如果run一个systemd进程来管理其他进程,那么这个时候没有办法直接管理其他的应用,这个时候应用状态的生命周期就不等于容器的生命周期,这样的情况就十分复杂了。
引申:Linux 容器的“单进程”模型,指的是容器的生命周期等同于 PID=1 的进程(容器应用进程)的生命周期,而不是说容器里不能创建多进程。当然,一般情况下,容器应用进程并不具备进程管理能力,所以你通过 exec 或者 ssh 在容器里创建的其他进程,一旦异常退出(比如 ssh 终止)是很容易变成孤儿进程的。
Pod的真正作用
而Pod就是用来K8s抽象出来的类比为进程组的概念,而上面提到的情况,就可以认为是一个拥有4个容器的pod,即现在不会塞进一个容器中,而是用4个分别独立的容器启动起来,包含在一个pod里面,而4个容器共享了一部分资源,所以说,Pod在K8s里面是一个逻辑单位(没有真实的去对应某些东西)。
总的来说,Pod 是 Kubernetes 分配资源的一个单位,因为里面的容器要共享某些资源,所以 Pod 也是 Kubernetes 的原子调度单位。
而Pod的设计问题早在 Google 研发 Borg 的时候,就已经发现了这样一个情况:这些应用之前往往有着密切的协作关系,使得它们必须部署在同一台机器上并共享某些资源。
4、Pod的具体业务案例
现在通过一个例子来帮助我们更好的理解为什么Pod是原子调度单位。
假设现在两个容器,是需要协作完成业务的,所以应该在一个Pod里面。第一个容器为业务容器A,完成写日志文件的功能,第二个容器为转发容器B,顾名思义,即将日志文件转发到后端进行对应处理。
A和B的资源需求如下:A 需要 1G 内存,B需要 0.5G 内存。
而当前集群环境的可用内存情况如下:Node01:1.25G 内存,Node02:2G 内存。
如果没有Pod,那么A和B需要运行在一台机子上,调度器先把A调到了Node01上,那么这就会使得B不能调度到01上了,因为资源不够,也就是内存不够B用了,这个时候调度失败,需要重新调度。