Pod 是Kubernetes项目中的原子调度单位
简单类比，容器的本质是进程，Kubernetes就像是管理进程的操作系统。
在Linux机器里，执行pstree -g命令后
可以展示当前系统中正在运行的进程的树状结构。
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
在一个真正的操作系统里，进程并不好似独自运行的，而是以进程组的方式，有原则地组织在uyiqi。像rsyslogd程序，负责的是linux操作系统的日志处理。和内核日志模块imklog，imuxsock等相互协作，共同完成 rsyslogd程序的职责.
这三个进程一定要运行在同一台机器上，否则，它们之间基于Socket的通信和文件交换，都会出现问题。
而把类似的应用给容器化，由于受限于容器的单进程模型，这三个模块必须被制作成三个不同的容器。设置affinity的属性来统一安排。
（单进程模型是指容器没有管理多个进程的能力而不是运行多个容器的能力，容器里的PID=1de进程是容器本身，其他进程都是PID=1的子进程，用户编写的应用，无法像正常操作系统里的init进程或者systemd那样拥有进程管理的功能。）
但是这在容器中会造成 成组调度(gang scheduling)问题。（例如，前两个容器被分配至某一节点，而当地三个容器加入后，发现内存硬件不足）
比如 在Mesos中有一个资源囤积(Resource hoarding)的机制，会在所有设置了Affinity约束的任务达到时，才开始对它们统一进行调度。(有调度效率损失和死锁的可能性)
在Google Omege论文中，提出乐观调度处理冲突的方法，先不管这些冲突，通过回滚机制来解决冲突之后的问题。(技术复杂)
在Kubernetes项目中，Pod是Kubernetes里的原子调度单位，这就意味着，Kubernetes项目的调度器，是同一按照Pod而非容器的资源需求进行计算的。
像上述问题，就会形成一个包括三个容器的Pod来处理，根本就不会选择小于限制条件的内存的节点.
适用于超亲密关系容器：互相之间会直接的文件交换，使用localhost或者Socker文件进行文本通信，会发生非常频繁的远程调用，需要共享某些Linux Namespace（如，一个容器需要加入另一个容器的network namespace）
但像PHP与Mysql虽然会发生访问，但更适合做成两个Pod。
Pod最重要的一个事实是： 它只是一个逻辑概念。
Pod里的所有容器，共享的是同一个network Namespace，并且可以声明共享同一个Volume。
假设一个Pod中有A和B两个容器：
为保证对等关系而非拓扑关系，就不能像Docker那样：容器B先启动，容器A后启动。
docker run --net=B --volumes-from=B --name=A image-A..
在Kubernetes项目中，Pod的实现是需要使用一个中间容器Infra。Infra容器永远都是第一个被创建的容器，而用户的其它容器，则通过Join Network Namespace的方式，与Infra容器关联在一起。
Infra容器在Kubernetes项目中，一定是占用极少资源的镜像。目前是用汇编语言编写，处于暂停状态的容器，大小为100～200kb
对于Pod里的容器A和B来说：
它们可以直接使用localhost进行通信；
它们看到的网络设备跟Infra容器看到的完全一致
网络资源包括Ip对于Pod来说只有一个，被Pod内的所有容器所共享
Pod的生命周期与Infra容器一致，与用户定义的A或B无关
容器设计模式论文：https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/burns
