20250720-6-Kubernetes 调度-nodeName字段，DaemonS_笔记

一、污点与容忍

1. 给节点添加污点

1）命令格式

• 
• 基本语法：kubectl taint node [node] key=value:[effect]
• 示例：kubectl taint node k8s-node1 gpu=yes:NoSchedule
• 操作说明：与打标签命令类似，将"label"替换为"taint"即可

2）value键值配置



• 键值规范：污点以键值对形式配置，如gpu=nvidia
• 实际应用：通常用于标记特殊节点，如GPU节点可标记为gpu=nvidia

3）effect动作



• 
• NoSchedule：Pod一定不会被调度到该节点（最常用）
• PreferNoSchedule：尽量不调度，非必须配置容忍
• NoExecute：不仅不调度，还会驱逐节点上已有Pod

4）污点效果



• 强制隔离：当节点设置NoSchedule后，未配置容忍的Pod绝对不会被调度到该节点
• master节点：K8s默认给master节点打上node-role.kubernetes.io/master:NoSchedule污点

5）资源不够的情况



• 资源不足表现：即使集群资源不足，未配置容忍的Pod也不会被调度到有污点的节点
• 实际现象：Pod会保持Pending状态，如示例中的pod2和pod5

6）配置污点容忍



• 
• 配置位置：在Pod的spec中添加tolerations字段
• 关键字段：
  • key：需要匹配的污点键名
  • operator：匹配操作符（Equal/Exists）
  • value：需要匹配的污点值
  • effect：需要匹配的污点效果

7）查看污点

• 查看命令：kubectl describe node [node] | grep Taint
• 输出示例：

8）创建尝试分配

• 实验现象：当所有节点都有污点且Pod未配置容忍时，Pod会保持Pending状态
• 错误提示：0/3 nodes available: 1 node(s) had taint {...}, that the pod didn't tolerate

9）配置污点容忍并分配

• 
• 正确配置：必须确保tolerations中的key、value、effect与节点污点完全匹配
• 验证方法：通过kubectl get pods -o wide查看Pod最终调度到的节点

2. 污点容忍

• operator类型：
  • Equal：要求value严格匹配（最常用）
  • Exists：只需key存在即可，不检查value
• 特殊值处理：
  • 空key+Exists：匹配所有污点
  • 空effect：匹配所有effect效果

3. 相关知识点

• 删除污点：kubectl taint node [node] key:[effect]-
• 实用技巧：可通过K8s官方文档搜索"tolerations"获取配置示例模板
• 常见错误：value拼写错误会导致容忍失效（如将"nvidia"误写为"nvdia"）

二、pod的配置问题

• 
• nodeSelector使用：通过disktype: "ssd"标签选择特定节点，但不会100%保证调度到目标节点
• 污点容忍特性：配置容忍后仅表示可以调度到带污点的节点，并非强制调度
• 调度可能性：当存在普通节点时，Pod仍可能调度到其他非目标节点

三、大师节点配置容忍性泡的示例

1. 污点与污点容忍的概念

• 
• Taints作用：避免Pod调度到特定Node，保障master节点安全性和专注性
• Tolerations作用：允许Pod调度到持有Taints的Node，但不是强制调度
• 应用场景：
  • 专用节点分组管理
  • 特殊硬件节点（SSD/GPU）
  • 基于Taint的驱逐

2. 污点容忍的配置方法

• 
• 基本配置：
• effect取值：
  • NoSchedule：不调度
  • NoExecute：不执行
  • PreferNoSchedule：尽量不调度

3. 污点容忍的省略情况

• 
• value省略：可以只保留key不指定value，如master节点的node-role.kubernetes.io/master
• key省略：通过operator: Exists可容忍所有带指定effect的污点
• 范围影响：省略value/key会扩大容忍范围，适配更多环境

4. 静态泡与污点容忍的关系

• 静态Pod特性：不受调度器管理，由kubelet直接管理
• master节点运行：k8s组件采用静态Pod方式启动，不受污点限制
• 两种例外情况：
  • 静态Pod（如etcd/kube-apiserver）
  • 配置了污点容忍的Pod（如calico）

5. 配置污点容忍的示例

• 全节点部署需求：为保证集群通信，calico需要在所有节点运行
• 通用容忍配置：
• 设计目的：适配不同k8s环境，确保网络组件必运行

6. 污点容忍的范围与实际应用

• 范围控制：
  • 指定key+value：精确匹配特定污点
  • 仅指定effect：容忍所有带该effect的污点
  • 使用Exists操作符：不校验key/value，仅看effect
• 实际建议：生产环境应明确指定key/value，避免过度容忍

四、部署配置容忍泡的示例

• 验证方法：创建5副本Deployment测试全节点调度
• 配置要点：
• 预期结果：Pod可调度到所有带NoSchedule污点的节点
• 与静态Pod区别：非静态Pod必须显式配置容忍才能在污点节点运行

五、查看分布情况

1. Pod调度情况

• Pending状态分析：多个Pod处于Pending状态，原因是节点存在污点{gpu:nvidia2}和{gpu:nvidia}，而Pod未配置相应容忍
• 节点污点检查：通过kubectl describe node可查看节点污点信息，显示master节点有NoSchedule污点
• 运行状态示例：
  • nginx-6799fc88d8-zqcrh：1/1 Running
  • pod2：0/1 Pending 74m
  • web-54c699bb5c-*系列：多个处于ContainerCreating状态

2. Pod扩容尝试

• 扩容策略：从5个副本扩容到10个副本进行测试
• 调度效果：部分Pod仍无法调度，显示"1 node(s) had taint {gpu:nvidia2}"等错误
• 关键现象：5个副本时未分配成功，扩容后部分Pod开始运行在node1和node2节点

3. 污点容忍配置

• 基础容忍配置：
• 特殊容忍配置：
  • CriticalAddonsOnly：关键组件专用容忍
  • NoExecute：用于驱逐场景的容忍
• 配置原则：
  • 不指定key时容忍所有NoSchedule污点
  • 需要精确匹配时应指定key/value对

4. Pod分布验证

• 成功调度案例：
  • web-54c699bb5c-9w81z：运行在k8s-node1(10.244.36.71)
  • web-54c699bb5c-htdgn：运行在k8s-node1(10.244.36.73)
• 节点分布规律：Pod均匀分布在node1和node2节点，master节点未参与调度

5. 污点去除操作

• 去除命令：kubectl taint node <node-name> <taint-key>-
• 关键操作：去除master节点的NoSchedule污点后，Pod可调度到master节点
• 验证方法：通过kubectl describe node | grep Taint确认污点已去除

6. 污点与容忍总结

• 精确匹配配置：
• 实践经验：
  • 明确指定key/value的配置更可靠
  • calico等系统组件使用Exists操作符容忍所有污点
  • 生产环境建议为关键组件配置专用容忍
• 常见问题：
  • 效果(effect)必须匹配：NoSchedule/NoExecute
  • master节点默认有NoSchedule污点
  • 多个污点需要分别配置容忍

六、配置容忍并查看分布情况

1. Pod容忍配置

• 配置方法：在Pod的spec中通过tolerations字段配置容忍，允许Pod被调度到带有特定污点的节点上
• 关键参数：
  • key：污点的键名
  • operator：比较运算符（Equal/Exists）
  • value：污点的值（当operator为Equal时需指定）
  • effect：污点效果（NoSchedule/PreferNoSchedule/NoExecute）

2. 节点直接指定

• 
• nodeName使用：通过spec.nodeName字段可直接指定Pod运行的节点，绕过调度器
• 应用场景：适用于需要精确控制Pod运行位置的场景
• 注意事项：直接指定节点会失去调度器的自动容错和负载均衡能力

七、k配置问题

1. 配置必要性分析

• 配置争议：在容忍配置中，key参数是否必须存在存在不同理解
• 实践经验：
  • 通常建议明确指定key值（如"gpu"）
  • 但实际使用中发现并非绝对必要
• 待研究点：需要进一步研究key参数在不同场景下的深层含义和最佳实践

八、nodeName

1. nodeName意义

• 强制调度机制：通过nodeName字段可直接指定Pod运行的目标节点，完全绕过kube-scheduler调度器
• 特殊应用场景：主要用于测试环境，当需要精确控制Pod部署位置时使用
• 与调度器关系：不参与调度器的节点筛选流程，直接跳过所有调度策略（如节点亲和性、污点容忍等）

2. 应用案例

• 配置方法：
• 实际效果验证：
  • 案例中创建pod7并指定到k8s-node1后，Pod立即进入Running状态（00:44:37验证）
  • 对比普通Pending状态的Pod（如pod2/pod5），证明nodeName确实绕过调度器限制
• 使用注意事项：
  • 生产环境慎用：可能导致Pod无法调度（当目标节点不可用时）
  • 测试环境优势：比nodeSelector更快速直接，无需预先配置节点标签
  • 典型测试场景：验证特定节点上的硬件/软件兼容性时使用
• 与常规调度区别：
  • 常规调度：经过节点筛选（nodeSelector/nodeAffinity）→ 打分 → 绑定流程
  • nodeName调度：直接绑定指定节点，相当于"走后门"机制（00:45:17讲解）

九、DaemonSet

1. DaemonSet功能

• 
• 节点全覆盖：确保在集群每个节点（包括新加入节点）上都运行一个Pod副本
• 自动扩展：新节点加入集群时会自动创建Pod，无需人工干预
• 运维特性：适用于需要以守护进程方式在每个节点运行的场景

2. DaemonSet应用场景

• 网络插件：如Calico网络组件，需要在所有节点部署网络代理
• 监控Agent：采集节点级监控指标（如CPU/内存使用率）
• 日志Agent：收集节点上所有Pod的日志（如Filebeat）
• 运维工具：主要用于基础设施层而非业务应用层

3. DaemonSet示例

• 与Deployment区别：
  • 不需要设置replicas副本数
  • 不支持strategy更新策略字段
  • 资源类型需改为DaemonSet
• 污点处理：
  • 默认不调度到有污点的节点
  • 可通过tolerations配置容忍特定污点
  • 实验时建议先删除节点污点：kubectl taint node <node-name> <taint-key>-

4. 部署日志采集程序

• 
• YAML关键配置：
• 部署验证：
  • 使用kubectl get pods -o wide查看Pod分布
  • 通过kubectl describe ds <name>检查调度状态
  • 节点增加时会自动创建新Pod（约30秒内完成）

十、调度失败原因分析

• 查看方法：
  • 查看调度结果：kubectl get pod <NAME> -o wide
  • 查看失败原因：kubectl describe pod <NAME>
• 常见原因：
  • 资源不足：节点CPU/内存无法满足pod的request配置
  • 污点问题：节点配置了污点但pod没有相应容忍
  • 标签不匹配：节点没有pod要求的标签
  • 磁盘不足：虽然少见但也会导致调度失败（需注意错误信息）

十一、DaemonSet控制器

1. DaemonSet控制器概述

• 工作特点：自动在符合条件的节点上创建pod
• 验证案例：删除节点污点后，DaemonSet会自动拉起pod

2. DaemonSet创建问题

• 命令行限制：不支持kubectl create直接创建
• 替代方案：通常使用YAML文件进行部署

3. DaemonSet不常用原因

• 使用场景：主要用于节点级守护进程，不是常规工作负载

4. node selector与污点区别

• 功能差异：
  • node selector：节点必须具有指定标签
  • 污点：节点排斥非特定pod
• 优先级关系：两者功能不同，不存在优先级比较
• 调度disable：使节点完全不调度新pod，不同于污点的选择性排斥

5. toleration与taint匹配

• 特殊配置：
  • 当toleration的key为空且operator为"Exists"时
  • 表示能容忍任意taint（除非指定了effect限制）

6. dry-run选项区别

• client模式：仅在客户端验证配置
• server模式：提交到API server进行验证
• 应用场景：测试资源配置时使用不同验证级别

十二、答疑

1. 权重的作用与理解

• 调度加分机制：权重相当于调度系统中的加分值，类似于比赛评委的特殊加分权限
• 实际应用场景：以中国好声音为例，特定评委可通过加分提高选手获胜概率
• 技术实现原理：在Kubernetes调度器打分环节会计算该值，影响节点分配优先级
• 学习建议：初学者只需理解其加分功能，深入理解需研究整个调度打分流程

2. 关于fact分配到master的疑问

• 现象描述：测试发现pod无法分配到master节点，与预期行为不符
• 排查过程：讲师重现测试环境，创建10个pod均未分配到master
• 可能原因：环境配置存在隐藏影响因素，需进一步验证
• 临时结论：初步排除理解错误，转向环境因素排查

3. 验证测试环境是否影响分配

• 配置验证：确认使用了正确的effect和operator配置组合
• 测试建议：建议学员尝试相同配置验证分配行为
• 最新发现：经过反复测试后确认配置理论上应生效
• 环境变量：强调环境差异可能导致不同表现，需实际验证

4. 数字与优先级的关系

• 数值规律：数字越大表示优先级越高，对应调度分数越高
• 评分类比：类似评委打分（1-100分范围），高分增加胜出概率
• 权重机制：高权重值会显著提升节点被选中的可能性
• 使用建议：合理设置权重值范围，避免极端数值影响调度平衡

5. 练习与验证

• 练习内容：
  • 验证master节点分配问题
  • 测试不同权重值对调度的影响
  • 尝试各种tolerations配置组合
• 验证方法：通过kubectl create命令部署测试用例
• 注意事项：记录完整测试过程，注意环境差异因素
• 交流机制：鼓励学员在群内分享验证结果和异常情况

十三、知识小结