Scheduler - HR Manager

Scheduler（人事经理）是 Kubernetes 控制平面中的关键组件之一。它的作用是把新创建但尚未分配节点的 Pod，合理地安排到合适的节点上运行。

---

🧩 Scheduler 的职责

• Pod 分配
  👉 当用户或控制器创建 Pod 时，Pod 先处于 “Pending” 状态，没有节点。Scheduler 会为它选择一个合适的节点。
• 调度策略
  • 资源匹配：检查节点的 CPU、内存等资源是否满足 Pod 的需求。
  • 约束条件：考虑 Pod 的调度规则（如 NodeSelector、Affinity、Taints/Tolerations）。
  • 优先级：在多个候选节点中选择最优的一个。
• 写入结果
  👉 Scheduler 将选择结果写入 Pod 的 spec.nodeName，然后由 Kubelet（工厂主管） 在该节点上真正启动 Pod。

---

📌 类比理解

• Scheduler = 人事经理
  • 当公司有新员工（Pod）入职时，人事经理负责把他们分配到合适的工厂（节点）。
  • 分配时要考虑工厂的产能（资源）、工人技能匹配（约束条件）、以及整体效率（优先级）。
  • 分配完成后，工厂主管（Kubelet）才会真正安排工人上岗。

---

⚙️ 调度流程

1. Pod 创建 → 进入 Pending 队列。
2. Scheduler 过滤节点 → 找出满足条件的候选节点。
3. Scheduler 打分 → 根据策略选择最优节点。
4. Scheduler 更新 Pod → 写入 nodeName。
5. Kubelet 执行 → 在目标节点启动 Pod。

---

⚠️ 注意事项

• 如果没有合适的节点，Pod 会一直处于 Pending 状态。
• 可以通过 Affinity/Anti-Affinity、Taints/Tolerations 来控制调度行为。
• 在大规模集群中，Scheduler 的性能和策略优化非常关键。

---

💡 总结

Scheduler 是 Kubernetes 的 人事经理，负责把新 Pod 分配到合适的节点。它不执行 Pod，只负责决策；真正的执行由 Kubelet 完成。

---

🧩 Affinity 和 Anti-Affinity

Kubernetes 中的 Affinity（亲和性）和 Anti-Affinity（反亲和性）是调度策略，用来控制 Pod 在节点上的分布。它们能让你指定 Pod 应该靠近或远离某些节点或其他 Pod，从而实现高可用性、性能优化和故障隔离。

---

🧩 Affinity（亲和性）

• Node Affinity（节点亲和性）
  • 让 Pod 调度到满足特定标签的节点上。
  • 分为 硬性要求（requiredDuringSchedulingIgnoredDuringExecution）和 软性偏好（preferredDuringSchedulingIgnoredDuringExecution）。
  • 示例：只允许 Pod 调度到带有 SSD 的节点。
• Pod Affinity（Pod 亲和性）
  • 让 Pod 调度到靠近某些已有 Pod 的节点上。
  • 适合需要高带宽通信的服务，例如数据库和缓存服务部署在同一节点或同一可用区。

---

🧩 Anti-Affinity（反亲和性）

• Node Anti-Affinity（节点反亲和性）
  • 避免 Pod 调度到某些节点上。
  • 示例：避免将敏感应用调度到公共网络节点。
• Pod Anti-Affinity（Pod 反亲和性）
  • 避免 Pod 调度到已有特定标签的 Pod 所在节点。
  • 常用于高可用场景，例如确保同一应用的副本分布在不同节点或不同可用区。

---

📌 应用场景

• 高可用性：通过 Pod Anti-Affinity，确保副本分布在不同节点，避免单点故障。
• 性能优化：通过 Pod Affinity，把需要频繁通信的服务放在一起。
• 资源优化：通过 Node Affinity，把数据密集型应用调度到有 SSD 的节点。
• 合规与安全：通过 Node Anti-Affinity，避免 Pod 调度到不符合安全标准的节点。 腾讯云 CSDN博客

---

📝 示例配置

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - myapp
      topologyKey: "kubernetes.io/hostname"
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - myapp
      topologyKey: "kubernetes.io/hostname"

👉 这个配置表示：Pod 必须调度到已有 app=myapp 的节点（亲和性），同时避免调度到已有相同标签的节点（反亲和性）。

---

💡 总结

• Affinity = 靠近谁
• Anti-Affinity = 远离谁
• 它们让调度更智能，提升 高可用性、性能和安全性。

---

🧩 Taints 和 Tolerations

Taints 和 Tolerations 是 Kubernetes 中另一组重要的调度机制，它们和 Affinity/Anti-Affinity 搭配使用，可以实现更精细的 Pod 调度控制。

---

🧩 Taints（污点）

• 定义：在节点上打上“污点”，表示这个节点不欢迎某些 Pod。

• 效果：除非 Pod 有相应的 Toleration，否则不会被调度到该节点。

• 用途：

  • 保留节点给特定工作负载（例如 GPU 节点只给 AI 任务用）。
  • 隔离不稳定或特殊用途的节点。

👉 类比：工厂门口贴了一个“特殊用途”告示，普通工人不能进。

---

🧩 Tolerations（容忍）

• 定义：Pod 上的配置，表示它可以容忍某些节点的污点。

• 效果：允许 Pod 被调度到带有对应污点的节点。

• 用途：

  • 指定某些 Pod 可以运行在特殊节点上。
  • 结合 Taints，实现更灵活的调度策略。

👉 类比：工人持有特别通行证，可以进入贴了“特殊用途”告示的工厂。

---

📌 应用场景

• 专用节点：给 GPU 节点打上污点，只允许 AI 训练 Pod 容忍并进入。
• 故障隔离：给不稳定节点打上污点，避免普通 Pod 被调度过去。
• 优先级控制：关键任务 Pod 可以容忍污点，普通 Pod 不行。

---

📝 示例配置

节点打污点：

kubectl taint nodes node1 key=value:NoSchedule

👉 表示 node1 节点有一个污点，普通 Pod 不会被调度到这里。

Pod 容忍污点：

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

👉 表示这个 Pod 可以容忍 key=value:NoSchedule 的污点，因此能调度到 node1。

---

💡 总结

• Taints = 节点的限制条件（不欢迎某些 Pod）。
• Tolerations = Pod 的通行证（允许进入带污点的节点）。
• 它们结合使用，可以实现 节点隔离、专用资源分配、故障控制。