Pod的调理机制

发表于 2024-8-9 01:11:10 | 显示全部楼层 |阅读模式

一、Pod调理概述

API Server 担当客户端提交Pod对象创建哀求后的利用过程中，有一个重要的步骤就是由调理器步伐 kube-scheduler 从当前集群中选择一个可用的最佳节点来接收并运行它，通常是默认的调理器 kube-scheduler 负责实行此类使命。
对于每个待创建的Pod对象来说，调理过程通常分为两个阶段：过滤 --> 打分，过滤阶段用来过滤掉不符合调理规则的Node，打分阶段建立在过滤阶段之上，为每个符合调理的Node举行打分，分值越高则被调理到该Node的机率越大。
二、Pod调理策略实现方式

nodeName（直接指定Node主机名）
nodeSelector （节点选择器，为Node打上标签，然后Pod中通过nodeSelector选择打上标签的Node）
污点taint与容忍度tolerations
NodeAffinity 节点亲和性
Pod Affinity Pod亲和性
Pod Anti-Affinity Pod反亲和性

三、kube-scheduler调理

kube-scheduler 是Kubernetes 集群的默认调理器，而且是集群控制面(master)的一部分。对每一个新创建的Pod大概是未被调理的Pod，kube-scheduler会选择一个最优的Node去运行这个Pod。
然而，Pod内的每一个容器对资源都有不同的需求，而且Pod自己也有不同的资源需求。因此，Pod在被调理到Node上之前，根据这些特定的资源调理需求，需要对集群中的Node举行一次过滤。
在一个集群中，满足一个Pod调理哀求的全部Node称之为可调理节点。如果没有任何一个Node能满足Pod的资源哀求，那么这个Pod将一直停顿在未调理状态直到调理器可以或许找到合适的Node。
调理器先在集群中找到一个Pod的全部可调理节点，然后根据一系列函数对这些可调理节点打分，然后选出其中得分最高的Node来运行Pod。之后，调理器将这个调理决定关照给kube-apiserver，这个过程叫做绑定。
在做调理决定是需要考虑的因素包罗：单独和整体的资源哀求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
1、kube-scheduler调理的流程

kube-scheduler给一个pod做调理选择包含两个步骤
1.过滤（Predicates 预选策略）2.打分（Priorities 优选策略）

过滤阶段：过滤阶段会将全部满足 Pod 调理需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源可否满足 Pod 的资源哀求。在过滤之后，得出一个 Node 列表，里面包含了全部可调理节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调理。
打分阶段：在过滤阶段后调理器会为 Pod 从全部可调理节点中选取一个最合适的 Node。根据当前启用的打分规则，调理器会给每一个可调理节点举行打分。最后，kube-scheduler 会将 Pod 调理到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。
整体流程如下图所示：

2、过滤阶段

PodFitsHostPorts：检查Node上是否不存在当前被调理Pod的端口（如果被调理Pod用的端口已被占用，则此Node被Pass）。
PodFitsHost：检查Pod是否通过主机名指定了特性的Node (是否在Pod中定义了nodeName)
PodFitsResources：检查Node是否有空闲资源(如CPU和内存)以满足Pod的需求。
PodMatchNodeSelector：检查Pod是否通过节点选择器选择了特定的Node (是否在Pod中定义了nodeSelector)。
NoVolumeZoneConflict：检查Pod哀求的卷在Node上是否可用 (不可用的Node被Pass)。
NoDiskConflict：根据Pod哀求的卷和已挂载的卷，检查Pod是否合适于某个Node (例如Pod要挂载/data到容器中，Node上/data/已经被其它Pod挂载，那么此Pod则不适合此Node)
MaxCSIVolumeCount：：决定应该附加多少CSI卷，以及是否高出了设置的限制。
CheckNodeMemoryPressure：对于内存有压力的Node，则不会被调理Pod。
CheckNodePIDPressure：对于进程ID不足的Node，则不会调理Pod
CheckNodeDiskPressure：对于磁盘存储已满大概接近满的Node，则不会调理Pod。
CheckNodeCondition：Node报告给API Server说自己文件体系不足，网络有写问题大概kubelet还没有准备好运行Pods等问题，则不会调理Pod。
PodToleratesNodeTaints：检查Pod的容忍度是否能承受被打上污点的Node。
CheckVolumeBinding：根据一个Pod并发流量来评估它是否合适（这实用于结合型和非结合型PVCs）。

3、打分阶段

当过滤阶段实行后满足过滤条件的Node，将举行打分阶段。

SelectorSpreadPriority：优先镌汰节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
InterPodAffinityPriority：优先将 Pod 调理到类似的拓扑上（如同一个节点、Rack、Zone 等）
LeastRequestedPriority：节点上放置的Pod越多，这些Pod利用的资源越多，这个Node给出的打分就越低，所以优先调理到Pod少及资源利用少的节点上。
MostRequestedPriority：尽量调理到已经利用过的 Node 上，将把计划的Pods放到运行整个工作负载所需的最小节点数量上。
RequestedToCapacityRatioPriority：利用默认资源评分函数形状创建基于requestedToCapacity的 ResourceAllocationPriority。
BalancedResourceAllocation：优先平衡各节点的资源利用。
NodePreferAvoidPodsPriority：根据节点注释对节点举行优先级排序，以利用它来提示两个不同的 Pod 不应在同一节点上运行。scheduler.alpha.kubernetes.io/preferAvoidPods。
NodeAffinityPriority：优先调理到匹配 NodeAffinity （Node亲和性调理）的节点上。
TaintTolerationPriority：优先调理到匹配 TaintToleration (污点) 的节点上
ImageLocalityPriority：尽量将利用大镜像的容器调理到已经下拉了该镜像的节点上。
ServiceSpreadingPriority：尽量将同一个 service 的 Pod 分布到不同节点上，服务对单个节点故障更具弹性。
EqualPriority：将全部节点的权重设置为 1。
EvenPodsSpreadPriority：实现首选pod拓扑扩展约束。

4、kube-scheduler 调理示例

默认设置利用的就是kube-scheduler调理组件，下面例子启动三个Pod，看分别被分配到哪个Node。
4.1、创建 Deployment 资源清单

[code]cat > scheduler-pod.yaml nodeName-pod.yaml