4. Kubernetes 调度与资源管理：调度器原理、节点亲和性、资源请求与限制、QoS 等级
4.1 调度器核心原理：从 Pod 到 Node 的决策链路
Kubernetes 调度器（kube-scheduler）负责将待调度的 Pod 绑定到最合适的 Node 上。其决策过程分为两个阶段：过滤（Predicates） 和 打分（Priorities）。
- 过滤阶段：遍历所有 Node，剔除不满足 Pod 调度条件的节点（如资源不足、端口冲突、污点不兼容等）。
- 打分阶段：对通过过滤的 Node 按优先级策略打分（如资源余量、Pod 分散度、亲和性匹配度），选择最高分节点。
- 绑定：将 Pod 与选定 Node 的绑定关系写入 etcd。
FinOps 视角： 调度决策直接影响集群资源利用率。调度越分散，碎片越多；调度越集中，热点风险越高。合理的调度策略是成本优化的第一道防线。
4.2 节点亲和性：精准调度与成本对齐
节点亲和性（Node Affinity）允许 Pod 声明对 Node 标签的偏好或硬性要求，是资源画像与成本控制的关键工具。
| 类型 | 语法字段 | 调度行为 | FinOps 应用场景 |
|---|---|---|---|
| requiredDuringScheduling | requiredDuringSchedulingIgnoredDuringExecution |
硬约束，必须匹配，否则 Pod 无法调度 | 将 GPU Pod 强制调度到 GPU 节点，避免资源浪费 |
| preferredDuringScheduling | preferredDuringSchedulingIgnoredDuringExecution |
软约束，尽量匹配，不匹配也可调度 | 将批处理作业优先调度到 Spot 实例节点，降低成本 |
成本优化技巧： 使用
preferredDuringScheduling 配合 weight 字段，让非关键工作负载优先使用低价实例（如 Spot/Preemptible VM），同时保证在低价实例不足时仍可调度到按需实例。
4.3 资源请求与限制：资源画像的基石
每个容器必须声明 requests（调度保证）和 limits（使用上限）。这两个值直接决定调度决策和成本核算。
apiVersion: v1
kind: Pod
metadata:
name: cost-aware-pod
spec:
containers:
- name: app
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "500m"
limits:
memory: "512Mi"
cpu: "1000m"| 参数 | 作用 | 对成本的影响 |
|---|---|---|
| requests | 调度时保证的资源量，Node 必须满足 | 决定集群容量规划，requests 越高，集群规模越大，成本越高 |
| limits | 容器可使用的资源上限，超过则被限流或 OOM Kill | 设置过高会导致资源闲置，设置过低会影响应用稳定性 |
| requests == limits | Guaranteed QoS，资源完全预留 | 成本最高，但性能最稳定，适合关键业务 |
| requests < limits | Burstable QoS，允许超卖 | 成本较低，适合可突发负载，但需监控实际使用 |
常见误区： 很多团队将 requests 设置得远高于实际使用，导致集群资源利用率低于 30%。建议基于历史监控数据（如 Prometheus 的 container_resource_requests 指标）定期调整 requests，实现资源画像的持续优化。
4.4 QoS 等级：资源保障与超卖策略
Kubernetes 根据容器的 requests 和 limits 配置，将 Pod 划分为三个 QoS 等级。等级决定了节点资源紧张时的驱逐顺序。
| QoS 等级 | 配置条件 | 驱逐优先级 | 适用场景 |
|---|---|---|---|
| Guaranteed | 所有容器 requests == limits，且不为 0 | 最低（最后被驱逐） | 数据库、核心 API、支付服务 |
| Burstable | 至少一个容器 requests < limits | 中等 | Web 服务、批处理任务、CI/CD |
| BestEffort | 所有容器未设置 requests 和 limits | 最高（最先被驱逐） | 开发测试、非关键日志处理 |
4.5 调度与成本控制的最佳实践
- 资源画像先行：基于 Prometheus 等监控工具，统计每个容器过去 7 天的 P50/P95/P99 资源使用量，作为 requests 设置的依据。
- 避免过度预留：将 requests 设置为 P95 使用量，limits 设置为 P99 使用量，既保证稳定性又避免浪费。
- 利用节点亲和性实现成本分层：将 Guaranteed Pod 调度到按需实例，将 Burstable/BestEffort Pod 调度到 Spot 实例。
- 定期审计 QoS 分布：使用
kubectl get pods -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass查看集群 QoS 分布，确保非关键工作负载没有误用 Guaranteed。
核心结论： 调度器、节点亲和性、资源请求与限制、QoS 等级四者共同构成了 Kubernetes 资源管理的闭环。在 FinOps 框架下，这四者的合理配置直接影响集群的资源利用率、稳定性与成本。资源画像越精准，成本控制越有效。