Kubernetes 设计解读 – Pod

By | 13 9 月, 2020

在 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-z0-9- ,全部小写,开头和结尾只能是小写字母和数字,中间用 - 连接(比如 An1-ame02n1_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 来分享这些配置。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注