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 会从中随机选取一个。
整体流程如下图所示：

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