我们为什么需要pod？
1. 解决具有超亲密关系容器之间的成组调度问题：比如在存在A、B、C三个容器，这三个容器之间基于socket和文件交换进行通信，在docker swarm中，可以在这三个容器之间设置affinity约束来要求这三个容器必须调度
到同一个节点，但是往往就存在容器A和B调度在某个节点，而这个节点剩余的资源却又不足与调度容器C的情况。Mesos中有一个资源囤积（resource hoarding）的机制，会在所有设置了 Affinity 约束的任务都达到时，才开始对它们统一进行调度，但是调度效率
难免降低。在 Google Omega 论文中，则提出了使用乐观调度处理冲突的方法，即：先不管这些冲突，而是通过精心设计的回滚机制在出现了冲突之后解决问题，而这种复杂的机制却难于掌握。pod作为Kubernetes里的原子调度单位，统一按照Pod而非容器的资源需求计算来执行调度。
2. 支持容器设计模式：pod作为一个逻辑概念，通过一个中间容器pause，让业务容器通过join namespace的方式加入到pause中的namespace。比如多个业务容器之间由于都加入到了Network Namespace中，所以他们可以使用localhost进行通信，如果需要为kubernetes
开发一个网络插件，也只需要关心如何配置pause容器的Network Namespace，而不是各个业务容器如何使用你的网络配置。（如果你的网络插件需要在容器里安装某些包或者配置才能完成的话，是不可取的：Infra 容器镜像的 rootfs 里几乎什么都没有，没有你随意发挥的空间。当然，这同时也意味着你的网络插件完全不必关心用户容器的启动与否，而只需要关注如何配置 Pod，也就是 Infra 容器的 Network Namespace 即可)
通过init container来做一些初始化工作，典型的例子是利用pod中容器共享volume信息，通过init container将war包放入volume中，tomcat容器则从volume中取出war包进行发布。
pod中运行两个容器分别是sidecar容器和业务容器，业务容器将业务日志输出到volume中，sidecar容器中部署日志收集器不断收集日志发到es中。