20250720-5-Kubernetes 调度-污点与污点容忍_笔记

一、nodeSelector与nodeAffinity

1. nodeSelector基本概念

• 简单匹配机制：通过节点标签(key-value)进行Pod调度约束
• 完全匹配要求：要求标签字符串必须完全相等才能匹配

2. nodeAffinity特性

• 
• 逻辑组合优势：相比nodeSelector提供更丰富的匹配逻辑
  • 支持操作符：In、NotIn、Exists、DoesNotExist、Gt、Lt
• 策略分级：
  • 硬策略(required)：必须满足的调度条件
  • 软策略(preferred)：优先但不强制满足的条件
• 配置复杂度：定义方法比nodeSelector复杂得多，但功能更强大

3. 配置示例

apiVersion: v1
kind: Pod
metadata:name: with-node-affinity
spec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: disktypeoperator: Invalues:- ssdpreferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference:matchExpressions:- key: disktypeoperator: Invalues:- ssd2containers:- name: webimage: nginx

• 实践建议：
  • 官方参考：建议直接从Kubernetes官方文档获取最新配置示例
  • 记忆技巧：不需要刻意记忆完整语法结构，使用时复制模板即可
  • 查询方法：在官方文档搜索"nodeAffinity"可获取权威配置指南

4. 核心区别总结

• 匹配精度：
  • nodeSelector仅支持完全匹配
  • nodeAffinity支持多种逻辑运算符
• 策略灵活性：
  • nodeSelector只有硬性要求
  • nodeAffinity支持软硬两种策略
• 使用场景：
  • 简单需求使用nodeSelector
  • 复杂调度需求使用nodeAffinity

二、nodeAffinity



1. 节点亲和性基础概念

• 基本功能: 类似于nodeSelector，但提供更灵活的节点选择方式，可以根据节点上的标签约束Pod调度
• 核心区别:
  • 支持更多逻辑组合操作符：In、NotIn、Exists、DoesNotExist、Gt、Lt
  • 分为软策略和硬策略两种调度方式
• 策略类型:
  • 硬策略(required): 必须满足条件才会调度
  • 软策略(preferred): 尝试满足但不保证，设置权重值(1-100)影响调度优先级

2. 节点亲和性配置示例

• 
• 配置结构:
  • 与containers同级设置affinity字段
  • 固定语法格式：requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution
• 关键配置项:
  • key: 节点标签键名(如disktype)
  • operator: 常用In操作符
  • values: 可指定单个或多个标签值(如ssd1,ssd2)
• 实际应用场景:
  • 硬件厂商区分(如三星/金士顿SSD)
  • 特殊硬件配置(如NVIDIA GPU)
  • 可用区调度优化

3. 硬策略实践演示

• 
• 配置特点:
  • 必须满足标签匹配才会调度
  • 节点标签变更后会重新触发调度
• 验证过程:
  • 初始无匹配标签时Pod保持Pending状态
  • 为节点添加匹配标签后Pod自动调度
  • 错误提示明确显示不匹配原因
• 注意事项:
  • 与nodeSelector同时存在时需同时满足
  • 多个matchExpressions需全部满足

4. 软策略实践演示

• 配置特点:
  • 设置weight权重值(1-100)影响调度优先级
  • 即使不匹配也能调度到其他节点
• 权重机制:
  • 调度器对符合要求的节点计算总分
  • 匹配的节点会加上权重值
  • 最终选择总分最高的节点
• 典型应用:
  • 优先但不强制使用特定硬件
  • 优化但不严格要求区域分布

5. 节点亲和性使用建议

• 选择建议:
  • 简单场景使用nodeSelector
  • 复杂匹配需求使用nodeAffinity
• 配置技巧:
  • 硬策略确保关键要求
  • 软策略提供灵活性
  • 权重值通常设为1即可
• 常见误区:
  • 过度配置复杂匹配条件
  • 忽视节点标签管理
  • 混淆硬策略和软策略的区别

三、Kubernetes调度机制

1. nodeSelector与nodeAffinity



• 基本关系：nodeAffinity是nodeSelector的增强版，两者都通过节点标签约束Pod调度
• 逻辑组合：支持6种操作符：In（多值匹配）、NotIn（排除匹配）、Exists（存在键）、DoesNotExist（不存在键）、Gt（大于）、Lt（小于）
• 策略类型：
  • 硬策略(required): 必须满足条件才会调度，配置在requiredDuringSchedulingIgnoredDuringExecution字段
  • 软策略(preferred): 优先但不强制满足，配置在preferredDuringSchedulingIgnoredDuringExecution字段，可设置权重(weight)
• 使用场景：
  • 当需要复杂逻辑组合（如多选、取反）时使用nodeAffinity
  • 当希望Pod尽量但不强制调度到特定节点时使用软策略
• 配置示例：

2. 污点(Taints)与污点容忍(Tolerations)



• 
• 核心概念：
  • 污点(Taints): 节点主动拒绝Pod调度的机制，相当于节点的"排斥标签"
  • 容忍(Tolerations): Pod声明能接受哪些污点，相当于"宽容度"
• 效果类型：
  • NoSchedule: 绝对禁止调度（新Pod）
  • PreferNoSchedule: 尽量避免调度
  • NoExecute: 禁止调度且驱逐现有Pod
• 应用场景：
  • 专用节点管理（如按业务线分组）
  • 特殊硬件节点（如SSD/GPU节点）
  • 基于污点的驱逐（较少使用）

3. master与node的区分



• 本质区别：
  • master节点：部署控制平面组件（apiserver、controller-manager、scheduler）
  • node节点：运行工作负载组件（kubelet、kube-proxy）
• 特殊现象：
  • master节点默认带有污点node-role.kubernetes.io/master:NoSchedule
  • 通过kubectl get node查看的是所有运行kubelet的节点（包括master）
• 识别方式：
  • ROLE字段显示control-plane/master
  • 实际通过部署的组件类型区分，而非主机名
• 调度影响：
  • 普通Pod默认不会调度到master节点
  • 需要特殊容忍配置才能调度到master

四、知识小结

知识点	核心内容	技术对比/易混淆点	应用场景
NodeSelector	通过标签强制匹配节点调度	仅支持简单键值匹配	专用节点分配、硬件隔离
NodeAffinity	支持复杂逻辑（硬性/软性策略、多值匹配）	硬性策略（requiredDuringScheduling）需严格满足条件；软性策略（preferredDuringScheduling）可容忍不匹配	多厂商硬件调度（如GPU/SSD标签组合）
污点与容忍（Taint/Toleration）	节点主动排斥Pod，需Pod显式声明容忍	与NodeAffinity方向相反（节点主导）	专用节点隔离（如Master节点默认污点）、特殊硬件预留
权重值（Weight）	软性策略中调整节点优先级（1-100）	权重越高越优先调度，但非强制	多节点资源均衡场景
Master/Node角色区分	由部署组件决定（Master含kube-apiserver等，Node含kubelet）	易混淆点：节点名称≠角色，需通过kubectl get nodes查看	集群架构设计