原文地址：http://kubernetes.io/v1.0/docs/user-guide/pods.html
Pod的发展

资源的共享及通信
Pod使Pod内的数据共享及通信变得容易

Pod的中的应用均使用相同的网络命名空间及端口，并且可以通过localhost发现并沟通其他应用，每个Pod都有一个扁平化的网络命名空间下IP地址，它是Pod可以和其他的物理机及其他的容器进行无障碍通信，（The hostname is set to the pod’s Name for the application containers within the pod）主机名被设置为Pod的名称（这个没翻译出来…）

除了定义了在Pod中运行的应用之外，Pod还定义了一系列的共享的磁盘，磁盘让这些数据在容器重启的时候不回丢失并且可以将这些数据在Pod中的应用进行共享

管理
Pod通过提供一个高层次抽象而不是底层的接口简化了应用的部署及管理，Pod 作为最小的部署及管理单位，位置管理，拷贝复制，资源共享，依赖关系都是自动处理的。（fate sharing估计就说什么时候该死了，什么时候该新增一个了…）

Pod的使用
Pod可以作为垂直应用整合的载体，但是它的主要特点是支持同地协作，同地管理程序，例如：

内容管理系统，文件和数据加载，本地缓存等等

日志和检查点备份，压缩，循环，快照等等

数据交换监控，日志追踪，日志记录和监控适配器，以及事件发布等等

代理，网桥，适配器

控制，管理，配置，更新

总体来说，独立的Pod不会去加载多个相同的应用实例

选择考虑
为什么不直接在一个容器上运行所有的应用？

1：透明，Pod中的容器对基础设施可见使的基础设施可以给容器提供服务，例如线程管理和资源监控，这为用户提供很多便利
2：解耦软件依赖关系,独立的容器可以独立的进行重建和重新发布，Kubernetes 甚至会在将来支持独立容器的实时更新
3：易用，用户不需要运行自己的线程管理器，也不需要关心程序的信号以及异常结束码等
4：高效，因为基础设施承载了更多的责任，所以容器可以更加高效
为什么不支持容器的协同调度
容器的协同调度可以提供，但是它不具备Pod的大多数优点，比如资源共享，IPC，选择机制，简单管理等

Pod的持久化
Pod并不是被设计成一个持久化的资源，它不会在调度失败，节点崩溃，或者其他回收中（比如因为资源的缺乏，或者其他的维护中）幸存下来

总体来说，用户并应该直接的去创建Pod，用户因该一直使用controller(replication controller),即使是一个节点的情况，这是因为controller提供了集群范围内的自我修复，以及复制还有展示管理

集群API的使用是用户的主要使用方式，这是相对普遍的在如下云管理平台中（ Borg, Marathon, Aurora, and Tupperware.）

Pod的直接暴露是如下操作变得更容器
1：调度和管理的易用性
2：在没有代理的情况下通过API可以对Pod进行操作
3：Pod的生命周期与管理器的生命周期的分离
4：解偶控制器和服务，后段管理器仅仅监控Pod
5: 划分清楚了Kubelet级别的功能与云平台级别的功能，kubelet 实际上是一个Pod管理器
6：高可用，当发生一些删除或者维护的过程时，Pod会自动的在他们被终止之前创建新的替代

API 对象
Pod是最高的资源在Kubernetes REST API中，更多清参考https://htmlpreview.github.io/?https://github.com/GoogleCloudPlatform/kubernetes/v1.0.1/docs/api-reference/definitions.html#_v1_pod