在 Kubernetes 中，能够被创建、调度和管理的最小单元是 Pod。
Pod 可以想象成一个篮子，而容器则是篮子里的鸡蛋，当 Kubernetes 需要调度容器时，它直接把一个篮子（连同篮子里的鸡蛋）从一个宿主机调度到另一个宿主机，而不是一个一个地搬运里面的鸡蛋。篮子与鸡蛋的关系主要表现在：
1. 一个 Pod 里的容器能有多少定义的资源也取决于这个篮子的大小
2. label 是贴在篮子上的
3. IP 分配给篮子而不是容器，篮子里面的所有容器共享这个 IP
4. 哪怕只有一个鸡蛋（容器），Kubernetes 仍然会给它分配一个篮子
Pod 是为了解决“如何合理使用容器支撑企业级复杂应用”这个问题而诞生的。同一个 Pod 里的容器有以下两个特性：
- 通过 Kubernetes Volume 机制，在容器间可以共享存储
- 可以通过 localhost 直接访问另一个容器
目前而言，Pod 对于 Kubernetes 最有用的价值就是 “原子化调度”。即在为一个 Pod 选择目的宿主机时，会考虑这个机器是否能够放下整个 Pod，而避免出现本该部署在一起的容器因为资源不足无法满足“超亲密”关系的尴尬。
label
在 Kubernetes 中，label 是一种重要的且被广泛应用的组织、分类和选择 Kubernetes 对象的机制。
labels 属性是一组绑定到 Kubernetes 对象上的 key/value 对，label 一般不直接作为系统内部唯一标识 Kubernetes 对象的依据，label 并不保证唯一性。
利用一个 label 的 key 代表一个资源管理纬度（如 release、environment 等），不同的 Kubernetes 对象携带一个或一组相同的 label，是 Kubernetes 实现多维度资源管理的精华所在。
一个合法的 key 由两部分组成 —— 前缀（prefix）和名字（name），中间由一个 / 分隔，其中，前缀和 / 是可选的，标识属于哪个域。
- name 字段最多由 63 个字符组成，接受的字符包括
a-z，0-9和-，全部小写，开头和结尾只能是小写字母和数字，中间用-连接（比如An1-ame0和2n1_ame0是非法的） - 如果指定了前缀，那么前缀必须是一个 DNS 子域名（即一系列用
.分隔的 DNS 标签，总长度不超过 253 个字符） - 如果前缀是缺省的，那么认为该 label 是用户私有的
Kubernetes API 目前支持两种类型的 label selector 查询条件：
- 基于值相等的查询条件，如
environment=production,tier!=frontned - 基于子集的查询条件，如
environment in (production,qa)、tier notin (frontend,backend)、partition（注意第三个的含义是过滤出值包含 partition 的资源对象，不需要检查 value）
Pod 字段说明
在所有的配置文件中，需要着重说明 spec 字段。
所有的资源对象都会在该字段下告诉系统自己的期望状态，而 Kubernetes 负责收集该资源对象的当前状态与期望状态进行匹配，进而维护应用容器集群一直处于用户所期望的状态。
Pod 内网络通信的原理
在每个 Pod 中，都会存在一个 [gcr.io/google_containers/pause](http://gcr.io/google_containers/pause) 的容器，所有外界给 Pod 指定的网络参数都只会定义在这个网络容器上，然后其他容器通过共享这个网络容器的 network namespace 来分享这些配置。