Pod的调理机制
目录[*]一、Pod调理概述
[*]二、Pod调理策略实现方式
[*]三、kube-scheduler调理
[*]1、kube-scheduler调理的流程
[*]2、过滤阶段
[*]3、打分阶段
[*]4、kube-scheduler 调理示例
[*]4.1、创建 Deployment 资源清单
[*]4.2、应用Deployment
[*]4.3、查看被kube-scheduler自动调理的Pod
[*]四、nodeName调理
[*]1、创建Pod资源清单
[*]2、应用Pod
[*]3、查看Pod的调理情况
[*]4、验证容器是否正常启动并在运行中
[*]五、nodeSelector调理
[*]1、分别给两个node添加标签
[*]2、查看node节点标签
[*]3、创建Pod资源清单
[*]4、应用Pod
[*]5、查看Pod调理情况
[*]6、删除标签
[*]7、查看Pod状态
[*]8、把Pod删除后重新创建
[*]9、describe查看events
[*]六、污点taint与容忍度tolerations调理
[*]1、概述
[*]2、污点
[*]2.1、污点类型
[*]2.2、Master污点
[*]2.3、查看k8s集群中Master节点的污点
[*]2.4、查看体系级别Pod的容忍度
[*]2.5、定义污点
[*]2.6、添加污点
[*]2.7、查看污点
[*]2.8、创建 Pod 资源清单
[*]2.9、应用Pod并查看Pod调理情况
[*]2.10、删除污点
[*]3、容忍度
[*]3.1、怎样定义
[*]3.2、为node打上不同等级的污点
[*]添加一个worker节点
[*]3.3、查看集群中节点的污点
[*]3.4、创建容忍NoSchedule级别污点的Pod
[*]3.4.1、应用Pod并查看调理情况
[*]3.5、创建容忍PreferNoSchedule级别污点的Pod
[*]3.5.1、应用Pod并查看调理情况
[*]3.6、创建容忍NoExecute级别污点的Pod
[*]3.6.1、应用Pod并查看调理情况
[*]3.7、创建没有容忍度的Pod
[*]3.7.1、应用Pod并查看调理情况
[*]3.8、清除用于测试污点
[*]七、NodeAffinity 节点亲和性调理
[*]1、概述
[*]2、两种规则
[*]3、定义节点亲和性规则注意点
[*]4、节点硬亲和性
[*]4.1、节点硬亲和性设置模板
[*]4.2、参数解析
[*]4.3、给 Node 节点添加标签
[*]4.4、调理到同时有environment=sit和role=db标签的节点（存在）
[*]4.5、调理到同时有environment=prod和role=db标签的节点（不存在）
[*]4.6、调理到具有 environment=sit 标签但不具有 role=db 标签的节点
[*]4.7、调理到具有environment 标签的节点（无论其值）
[*]5、节点软亲和性
[*]5.1、节点软亲和性设置模板
[*]5.2、参数解析
[*]5.3、示例
[*]5.3.1、分析
[*]5.3.2、应用Deploymet查看调理情况
[*]6、清除 Node 标签
[*]八、PodAffinity Pod亲和性调理
[*]1、概述
[*]2、分类
[*]3、Pod 硬亲和性
[*]3.1、Pod 硬亲和性设置模板
[*]3.2、参数解析
[*]3.3、为 Node 打上不同地区的标签
[*]3.4、创建 Pod 资源清单（利用 Pod 硬亲和性）
[*]3.5、查看调理结果
[*]3.6、创建带有特定标签的 Pod
[*]3.7、查看调理结果
[*]4、Pod 软亲和性
[*]4.1、Pod 软亲和性设置模板
[*]4.2、参数解析
[*]4.3、创建带有 app=nginx 和 app=busybox 标签的 Pod。
[*]4.4、创建 Pod 软亲和性的 Deployment
[*]4.5、应用标签为 cache 和 db 的 Pod
[*]4.6、应用带有 Pod 软亲和性的 Deployment
[*]4.7、查看Pod调理情况
[*]九、Pod Anti-Affinity Pod反亲和性调理
[*]1、概述
[*]2、分类
[*]3、Pod 硬反亲和性
[*]3.1、Pod 硬反亲和性设置模板
[*]3.2、创建带有硬反亲和性规则的Deployment
[*]3.3、应用Deployment查看Pod调理情况
[*]4、Pod软反亲和性
[*]4.1、Pod 软反亲和性设置模板
[*]4.2、创建带有 Pod 软反亲和性的 Deployment
[*]4.3、应用 Deployment 查看调理情况
一、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 会从中随机选取一个。
整体流程如下图所示：
https://img2023.cnblogs.com/blog/3332572/202408/3332572-20240809005509825-1365850109.png
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 资源清单
cat > scheduler-pod.yamlnodeName-pod.yaml
页:
[1]