实用指南：k8s中的schedule

所有的新建pod都需要走scheduler

一个非MasterNode上可以运行多个Pod，只要资源足够

1. Node 的本质
   一个 Node = 一台物理机 或 虚拟机。
   它有自己的 CPU、内存、存储和网络资源。
   Pod 就是运行在 Node 上的“工作负载单元”。

2. Node 和 Pod 的关系
   一个 Node 可以运行多个 Pod（只要资源足够）。
   Pod 调度到 Node 上时，Scheduler 会检查 Node 是否有足够的 CPU / 内存 / 存储 / 网络资源。
   限制因素：
   Node 的总资源容量
   Pod 的 requests 和 limits 调整
   节点污点（Taint）和 Pod 的容忍（Toleration）
   Pod 的亲和性/反亲和性规则
   资源和调度策略决定一个 Node 能跑多少 Pod。就是 所以，不是 Node 限制 Pod 数量，而

3. 举例
   假设一个 Node 有 16 核 CPU，64Gi 内存：
   Pod A 需要 2 核 + 8Gi
   Pod B 需要 1 核 + 4Gi
   Pod C 必须 4 核 + 16Gi
   只要资源允许，可以同时跑很多 Pod。
   在大规模集群中，一个 Node 上运行 几十个甚至上百个 Pod 是非常常见的。

Scheduler

1. Scheduler 的位置

• Scheduler 是控制平面（Control Plane）的核心组件。
• 运行在 Master Node 上。
• 作用：为新创建的未调度 Pod选择合适的 Node。（唯一作用）

---

2. 工作流程

1. Pod 创建

   • 用户通过 kubectl 或 API Server 提交 Pod。
   • Pod 信息写入 etcd，此时 spec.nodeName 为空（表示未调度）。

2. 监听 Pending Pod

   • Scheduler 通过 API Serverwatch新的 Pod。
   • 当发现 Pod 处于 Pending 状态时，开始调度。

3. 调度决策
   调度分两步：

   • 预选（Filtering）：过滤掉不符合条件的节点
     • 节点资源不足（CPU/内存不够）
     • 节点打了 Taint（污点）
     • 不满足 Pod 的 NodeSelector、NodeAffinity 等约束
   • 优选（Scoring）：对剩余节点打分，选择最优节点
     • 负载均衡
     • 节点剩余资源利用率
     • 拓扑结构（跨可用区分布等）

4. 绑定 Pod 到节点

   • Scheduler 通过 API Server 发起Bind 请求。
   • API Server 更新 Pod 的 spec.nodeName，写入 etcd。

5. kubelet 启动容器

   • 目标 Node 上的 kubelet 通过API Server发现 Pod 被分配给自己。
   • kubelet 调用容器运行时（containerd/Docker）拉取镜像并启动容器。

---

3. 关键点总结

• Scheduler不直接写 etcd，只通过 API Server 更新信息。
• 触发调度的条件：发现有新的Pending Pod。
• 调度结果是 Pod 被绑定到某个 Node。
• 最终由 kubelet通过API server发现得启动pod，并且在该 Node 上实际启动 Pod。

Kubernetes Scheduler 选 Node 依据规则

1. 过滤阶段（Predicates / Filter）

目的：排除不满足条件的 Node

• 资源要求否足够就是：CPU、内存、GPU 等
• 节点标签/污点：NodeSelector、Node Affinity、Taints/Tolerations
• 存储需求：PVC 是否能绑定到 Node 的 PV
• 端口冲突：Pod 端口是否已被占用

2. 打分阶段（Priorities / Score）

目的：在候选 Node 中选择最优 Node

• 资源利用率：Prefer evenly distributed / Least requested
• 拓扑亲和：PodAffinity / PodAntiAffinity
• 数据局部性：调度靠近所需 PV 或缓存数据
• 自定义调度策略：Scheduler Extender、插件策略

3. 最终选择

• 计算每个 Node 的总得分 → 选择最高分 Node
• 若有多 Node 得分相同 → 随机选一个