Kubernetes技术与架构（七）

1     前言

1.1   CNCF

1.2   云原生

1.3   公有云服务

1.4   私有云服务

1.5   混合云服务

2     Kubernetes定义

2.1   基本概念

2.2   架构演进

2.2.1 传统部署（Traditional deployment ）

2.2.2 虚拟化部署（Virtualized deployment）

2.2.3 容器化部署（Container deployment）

2.3   使用场景

2.4   使用约束

3     Kubernetes架构

3.1   集群架构

3.2   控制面（Control Plane）组件

3.2.1kube-apiserver

3.2.2etcd

3.2.3kube-scheduler

3.2.4kube-controller-manager

3.2.5cloud-controller-manager

3.3   节点（Node）组件

3.3.1kubelet

3.3.2kube-proxy

4     Kubernetes技术

4.1   容器化技术

4.1.1 cgroups技术

4.1.1.1 基本定义

4.1.1.2 核心接口文件

4.1.1.3 基本运作

4.1.1.3.1     挂载

4.1.1.3.2     进程

4.1.1.3.3     线程

4.1.1.3.4     事件

4.1.1.3.5     控制器

4.1.1.3.6     委派授权

4.1.1.3.7     指导原则

4.1.1.4 资源分发模型

4.1.1.4.1     权重

4.1.1.4.2     限制

4.1.1.4.3     保护

4.1.1.4.4     分配

4.1.1.5 控制器

4.1.1.5.1     处理器

4.1.1.5.2     内存

4.1.1.5.3     IO

4.1.1.5.4     进程

4.1.1.5.5     设备

4.1.1.5.6     RDMA

4.1.2 Docker容器运行环境

4.1.2.1 Docker架构

4.1.2.2 使用场景

4.1.3 containerd容器运行环境

4.1.3.1 Containerd架构

4.1.3.2 使用场景

4.1.4 Pod的基本概念

4.1.4.1 Pod的定义

4.1.4.2 Pod的编写

4.1.4.3 Pod的生命周期

4.1.4.3.1     Pod的阶段

4.1.4.3.2     Pod的状态

4.1.5 Pod的调度策略

4.1.5.1 拓扑配置

Kubernetes提供Pod弹性可伸缩的资源调度策略，该策略可以约束Pod在集群中的拓扑关系以及扩展收缩的合理分布，用户可以使用该策略保证Pod在集群中的高可用性以及高效的资源利用率。Pod的拓扑关系配置如下所示：

上图的配置项描述如下所示：

topologySpreadConstraints

节点表示拓扑策略的配置，可定义一个或者多个拓扑策略，多个拓扑策略的计算方式是逻辑与

maxSkew

<integer>表示整数类型，必填且大于0，该字段表示调度Pod资源时的不平衡分布的最大程度，作为一个在某种条件下的参照值，方便做比较之后做出的调整，该值的使用方式依靠whenUnsatisfiable设置的值： 当whenUnsatisfiable：DoNotSchedule时，对比所有匹配的节点区域的可调度Pod的数量，取最小数量N，假设当前节点区域的Pod总数是M，则K=M-N，取K与maxSkew做比较确定符合资源调度的节点区域。例如，kubernetes集群中有3个区域，能匹配调度Pod的数量分别是2/4/5，则取最小值2，取2与2/4/5的差值，再与maxSkew比较，得出适合调度的节点区域（与maxSkew作等值比较）。 当whenUnsatisfiable：ScheduleAnyway时，优先调度那些更能降低资源不平衡分布的程度的节点区域。

minDomains

<integer>表示整数类型，属于可选项，是一个参照值 当该值被指定时，必须大于0，用户可以同时指定minDomains的值以及whenUnsatisfiable:  DoNotSchedule 当符合topologyKey的区域数量小于minDomains时，Pod调度器认为集群内可用于调度Pod的最小数量是0，则使用计算的方式确定可调度的资源。 当符合topologyKey的区域数量大于或者等于minDomains时，Pod调度器不使用此值 当不指定minDomains值，则默认等于1

topologyKey

该配置项指定调度的节点的标签，假如kubernetes集群中有两个节点的标签与该值相同，则Pod调度器认为所匹配的节点在同一个拓扑关系中，则Pod调度器将在这两个节点区域中平衡地调度Pod实例

whenUnsatisfiable

该配置项表示在一个Pod不能满足调度的约束条件或者策略时如何处理该Pod 当值等于DoNotSchedule（默认值）时，调度器不用调度该Pod 当值等于ScheduleAnyway值时，调度器优先调度那些能最小化不平衡程度的区域节点

labelSelector

用于匹配Pod或者检索集群中的具有相同标签的Pod，Pod调度器需要统计Pod的数量，用于在区域节点的拓扑关系中确定Pod资源调度的策略

4.1.5.2 节点标签

拓扑配置项topologyKey对应的节点标签，确定每个拓扑策略中包括的节点区域。其形式如region: us-east-1或者zone: us-east-1a

假如kubernetes集群中拥有4个节点，如下所示：

如上所示，其中LABELS是节点的标签，在kubernetes集群中的逻辑结构如下所示：

由以上的分析可知，为了保证拓扑策略的一致性，Pod调度器使用节点标签标记节点区域内的分组，每组内设置对应的拓扑策略。

4.1.5.3 拓扑实例1

本示例展示只有一个拓扑策略的资源调度，假设kubernetes集群中拥有4个节点，节点中调度了3个同一个应用的Pod实例，Pod的标签是foo:bar，则集群的逻辑结构如下所示：

假设用户需求是需要再增加一个Pod实例，能平衡地分布在集群节点区域中，则Pod的拓扑策略配置如下所示：

由以上的配置可知，拓扑策略需要匹配的节点区域是topologyKey: zone，也就是，区域节点的标签是zone: <any value>的都符合该拓扑策略，Pod的调度器将忽略不符合此区域节点的标签的节点。其中，whenUnsatisfiable: DoNotSchedule表示如果找不到合适的区域节点，Pod调度器将停止为新的Pod调度任何资源。Pod调度器的计算拓扑策略的方式如下所示：

• 假设新增的Pod放在zoneA，则得出zoneA的调度结果是[3，1]，其中数值3表示新增一个Pod实例后zoneA的Pod的实例总数，数值1表示zoneA与zoneB中已经存在的最小的Pod实例数（zoneA已存在2个Pod实例，zoneB中已存在1个Pod实例）。则根据拓扑策略的调度算法，则3-1=2，取2与maxSkew=1作出比较后，发现不相等，所以只能放在zoneB中调度新的Pod。

• 假设新增的Pod放在zoneB，则得出zoneB的调度结果是[2，1]，其中数值2表示新增一个Pod实例后zoneB的Pod的实例总数，数值1表示已经存在的最小的Pod实例数，则根据拓扑策略 ，则2-1=1，取1与maxSkew=1作出比较后，发现相等，所以Pod调度器将在zoneB中调度新的Pod。

Pod调度器增加新的Pod的集群结构如下所示（其中myPod表示新增的Pod实例）：

或者

综上所述，调整拓扑策略中的配置项的值，可以约束Pod调度器的实行资源调度行为：

• 调整maxSkew：2的是时候，新增的Pod实例将被调度到zoneA中

•  调整topologyKey：node的时候，Pod调度器将根据node作为计算颗粒度，而非根据zone作为计算颗粒度，因此，新增的Pod实例将被调度到zoneB的node4中，其计算方法也是根据参照maxSkew的值

• 调整whenUnsatisfiable：ScheduleAnyway的时候，新增的Pod实例将被调度到已存在Pod实例数最小的节点区域中

4.1.5.4 拓扑实例2

本实例展示两个拓扑策略的资源调度，kubernetes的集群结构如下所示：

假设用户需求是需要再增加一个Pod实例，能平衡地分布在集群节点区域中，则Pod的拓扑策略配置如下所示：

如上所示，根据配置的拓扑策略，Pod调度器先计算拓扑策略1，也就是，先计算topologyKey: zone颗粒度的，将新增的Pod实例调度到节点区域zoneB，再计算拓扑策略2，也就是计算topologyKey: node颗粒度的，将新增的Pod实例调度到区域节点node4。

4.1.5.5 拓扑实例3

本实例展示两个拓扑策略的资源调度时发生冲突的情况，kubernetes的集群结构如下所示：

假设用户需求是需要再增加一个Pod实例，能平衡地分布在集群节点区域中，则Pod的拓扑策略配置如下所示：

如上所示，根据配置的拓扑策略，Pod调度器先计算拓扑策略1，也就是，先计算topologyKey: zone颗粒度的，将新增的Pod实例调度到节点区域zoneB，再计算拓扑策略2，也就是计算topologyKey: node颗粒度的，将新增的Pod实例调度到区域节点node2，而node2是在zoneA中，所以，该场景在资源调度发生冲突，这种情况下，Pod调度器将设置新增的Pod实例一直处于等待的状态（pengding）。

为了解决以上的问题，需要调整Pod的拓扑实例的配置项，例如增大maxSkew的值或者设置whenUnsatisfiable: ScheduleAnyway让Pod调度器自行调整。

4.1.5.6 拓扑实例4

Pod调度器根据spec.nodeSelector配置项或者根据spec.affinity.nodeAffinity配置项实行资源调度。假设kubernetes集群中包括zoneA、zoneB、zoneC三个节点区域，如下所示：

假设用户需求是需要再增加一个Pod实例，能平衡地分布在集群节点区域中，则Pod的拓扑策略配置如下所示：

如上所示，如果根据Pod调度器的计算方式，与maxSkew=1对比分析，则新增的Pod实例应该被调度到节点区域zoneC中，但是根据spec.nodeSelector节点选择器的定义，则zoneC被排除在外，新增的Pod实例被调度到zoneB中。

4.1.5.7 系统约束

Kubernetes集群的调度器默认提供了一些规则，如下所述：

• 与待调度的Pod的命名空间相同的已经存在Pod，才参与Pod数量的统计以及参与调度算法

• Pod调度器忽略那些不同于topologySpreadConstraints[*].topologyKey拓扑策略配置项的节点区域，不同标签的区域节点或者节点区域不参与maxSkew的计算，错误的节点标签类型不参与maxSkew的计算

• 与topologySpreadConstraints[*].labelSelector配置不同的节点不参与区域节点的数量的统计

Kubernetes集群的提供默认拓扑策略的设置，该设置集群内有效：

Kubernetes集群提供Pod调度器级别的默认拓扑策略设置：

Kubernetes集群提供关闭默认拓扑策略的设置：

（未完待续）