【云原生 实战研发】2：Pod的深入实践与理解_pod 深度学习(1)

那么对于这个方法，最需要注意的问题是，容器本身是“单进程”模型。（这并不是意味着容器只能跑一个进程。）
而是说因为容器=应用=进程，所以只能管理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用了，这个时候调度失败，需要重新调度。