mirror of
https://github.com/Baim0/baim0-learn.git
synced 2026-10-19 17:57:45 +08:00
add kube-scheduler 调度性能瓶颈笔记
This commit is contained in:
Your Name
@@ -0,0 +1,189 @@
|
||||
---
|
||||
title: 大规模集群 kube-scheduler 调度性能瓶颈
|
||||
date: 2026-08-21
|
||||
tags:
|
||||
- kubernetes排障
|
||||
categories:
|
||||
- kubernetes排障
|
||||
---
|
||||
|
||||
## 问题现象
|
||||
|
||||
集群规模接近 2000 节点、数万 Pod，出现大量 Pod 持续 `Pending` 且**无任何 Event 产生**，调度队列堆积，新 Pod 无法及时调度。
|
||||
|
||||
## 问题原因
|
||||
|
||||
核心是 kube-scheduler 在大规模集群下计算开销过大，形成恶性循环。先看调度机制，再看三个关键问题点。
|
||||
|
||||
### 调度机制
|
||||
|
||||
```
|
||||
新建 Pod → 进入调度队列 → 过滤节点(Filter) → 打分排序(Score) → 绑定节点(Bind)
|
||||
↑ |
|
||||
|____________ 调度失败时回退等待(Backoff) _________|
|
||||
```
|
||||
|
||||
- 调度失败的 Pod 进入 **Backoff 队列**，等待时间随失败次数指数增长，上限为 `podMaxBackoffSeconds`。
|
||||
- **调度失败后会回退等待，而不是立即重试**，这是理解后续问题的关键。
|
||||
|
||||
### 抢占机制详解
|
||||
|
||||
#### 什么是抢占
|
||||
|
||||
当**高优先级 Pod 在 Filter 阶段找不到任何可用节点**时，调度器会尝试驱逐（删除）节点上的低优先级 Pod，为它腾出资源。抢占由 **DefaultPreemption** 插件在 **PostFilter** 扩展点触发，是调度失败后的“最后一搏”。
|
||||
|
||||
> 抢占不是无条件发生的：只有 `priority > 0` 的 Pod（即设置了 PriorityClass）才能发起抢占；`priority = 0` 的 Pod 无法抢占他人，但仍可能成为被驱逐的受害者。
|
||||
|
||||
#### 抢占流程
|
||||
|
||||
```
|
||||
高优先级 Pod Filter 失败（无任何可调度节点）
|
||||
↓
|
||||
触发 PostFilter：DefaultPreemption
|
||||
↓
|
||||
并行 DryRun 预演：对（几乎）每个节点模拟“移除低优先级 Pod”
|
||||
直到该 Pod 能放下为止
|
||||
↓
|
||||
选出候选节点 candidate + 受害者列表 victims
|
||||
↓
|
||||
NominatePod：将该 Pending Pod 提名(nominated)到目标节点，预留资源
|
||||
↓
|
||||
异步驱逐受害者 Pod（走 API Server 删除，尊重优雅终止期）
|
||||
↓
|
||||
受害者退出后，Pending Pod 重新入队并被真正调度到该节点
|
||||
```
|
||||
|
||||
#### 受害者选择（Victim Selection）
|
||||
|
||||
在**单个节点**上，调度器按以下顺序模拟移除 Pod，直到待调度 Pod 能够放下：
|
||||
|
||||
1. **先移除优先级最低的 Pod**（优先级从低到高依次移除）；
|
||||
2. 同优先级下，优先移除**正在终止**的 Pod（deletion timestamp 更早的）；
|
||||
3. 同优先级下，优先移除 **terminationGracePeriod 更短**的 Pod；
|
||||
4. 过程中尽量满足 **PodDisruptionBudget（PDB）**，但 PDB 只是“尽力而为”的软约束，必要时仍会违反。
|
||||
|
||||
#### 候选节点选择（Candidate Selection）
|
||||
|
||||
当多个节点都能通过抢占满足要求时，调度器按以下优先级选出**唯一**目标节点：
|
||||
|
||||
| 优先级 | 选择标准 | 含义 |
|
||||
| ------ | ---------------------------- | -------------------------------------- |
|
||||
| 1 | PDB 违规数量最少 | 尽量少地破坏可用性预算 |
|
||||
| 2 | 受害者数量最少 | 尽量少驱逐 Pod |
|
||||
| 3 | 受害者中最高优先级最低 | 尽量驱逐“更不重要”的 Pod |
|
||||
| 4 | 受害者优先级总和最小 | 整体上损失最小 |
|
||||
|
||||
#### 提名 Pod（Nominated Pod）机制
|
||||
|
||||
- 抢占成功后，Pending Pod 会被记录为 **Nominated Pod**，其 status 中带上 `nominatedNode` 字段，指向目标节点。
|
||||
- 在受害者真正被删除、资源释放之前，这个“提名”会**在调度器 cache 中预留**相应资源，避免其他 Pending Pod 重复抢占同一批资源。
|
||||
- 受害者驱逐是**异步**的，Pending Pod 需要等待受害者真正退出后，才会被调度到该节点。
|
||||
|
||||
#### 抢占为什么是性能瓶颈
|
||||
|
||||
- 每个无法调度的 Pending Pod 在抢占评估时，都要对（几乎）**所有节点**执行一次 DryRun：遍历节点上所有 Pod、按优先级排序、模拟移除。
|
||||
- 单次抢占评估复杂度 ≈ `待调度 Pod 数 × 节点数 × 每节点 Pod 数`。
|
||||
- 本案例：`2000 节点 × 数万 Pod`，抢占评估（而非正常调度）成为最主要的 CPU 开销来源。
|
||||
|
||||
### 关键问题点
|
||||
|
||||
**问题一：Pod 流转机制导致重复评估**
|
||||
|
||||
- Pod 结束运行时，所有不可调度的 Pending Pod 都要重新评估（资源可能被释放）。
|
||||
- 大规模集群中 Pod 频繁创建销毁 → Pending Pod 被频繁重新评估 → 计算开销累积。
|
||||
|
||||
**问题二：抢占机制的性能开销**
|
||||
|
||||
- 高优先级 Pod 无法调度时，会尝试驱逐低优先级 Pod 腾资源（详见上文「抢占机制详解」）。
|
||||
- 每个 Pending Pod 调度时都会**遍历所有节点的所有 Pod** 比较优先级。
|
||||
- 本案例：`2000 节点 × 数万 Pod = 极大计算开销`。
|
||||
|
||||
**问题三：SchedulingHint 功能未启用**
|
||||
|
||||
| 版本 | SchedulingHint 状态 |
|
||||
| ------- | ------------------- |
|
||||
| 1.28 | Alpha，默认关闭 |
|
||||
| 1.29+ | Beta，默认开启 |
|
||||
|
||||
- SchedulingHint 可智能判断哪些 Pending Pod 需要重新评估，避免无谓的重复评估。
|
||||
- 客户集群为 **1.28**，该功能默认未启用 → 每次 Pod 删除，所有 Pending Pod 全部重新评估。
|
||||
|
||||
### 问题链路
|
||||
|
||||
```
|
||||
大规模集群(2000节点/数万Pod)
|
||||
↓
|
||||
Pod 频繁创建销毁
|
||||
↓
|
||||
每次 Pod 结束 → 所有 Pending Pod 重新评估（无 SchedulingHint 优化）
|
||||
↓
|
||||
每个 Pending Pod 评估时遍历所有节点的所有 Pod（抢占机制）
|
||||
↓
|
||||
调度器 CPU/内存压力剧增
|
||||
↓
|
||||
调度队列堆积，新 Pod 无法及时处理
|
||||
↓
|
||||
Pod 持续 Pending，无 Event 产生
|
||||
```
|
||||
|
||||
## 解决方案
|
||||
|
||||
### 紧急缓解
|
||||
|
||||
清理冗余 Pod，调度压力明显缓解。
|
||||
|
||||
### 参数优化
|
||||
|
||||
**1. `podMaxBackoffSeconds`：默认 10 → 推荐 60**
|
||||
|
||||
增大 backoff 时间，让更多 Pod 被标记为不可调度，减少 Pending Pod 被频繁重新评估的次数；额外收益是 CA（Cluster Autoscaler）能更快感知不可调度 Pod 从而更快弹节点。
|
||||
|
||||
**2. `percentageOfNodesToScore`：默认动态计算 → 推荐 10**
|
||||
|
||||
- 默认公式：`percentageOfNodesToScore = 50 - (nodes / 125)`，最小 5%。
|
||||
- 只评估足够多的可行节点即可打分，无需评估全部节点。
|
||||
- 2000 节点集群设为 10% ≈ 只评估约 200 个节点，显著降低单次调度计算量。
|
||||
|
||||
**3. 抢占配置调整**
|
||||
|
||||
| 方案 | 配置方式 | 影响 |
|
||||
| -------------- | ---------------------------- | -------------------------- |
|
||||
| 关闭抢占 | `disablePreemption: true` | 完全跳过抢占评估，显著降开销 |
|
||||
| 限制抢占范围 | 调整 PriorityClass 配置 | 减少参与抢占的 Pod 数量 |
|
||||
|
||||
### 配置示例
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1
|
||||
kind: KubeSchedulerConfiguration
|
||||
podMaxBackoffSeconds: 60
|
||||
percentageOfNodesToScore: 10
|
||||
profiles:
|
||||
- schedulerName: default-scheduler
|
||||
pluginConfig:
|
||||
# 其他配置...
|
||||
```
|
||||
|
||||
## 关键要点
|
||||
|
||||
### 大规模集群调度器配置建议
|
||||
|
||||
| 集群规模 | podMaxBackoffSeconds | percentageOfNodesToScore |
|
||||
| ------------- | -------------------- | ------------------------ |
|
||||
| < 500 节点 | 10（默认） | 默认 |
|
||||
| 500-1000 节点 | 30 | 20 |
|
||||
| 1000-2000 节点| 60 | 10 |
|
||||
| > 2000 节点 | 60 | 5-10 |
|
||||
|
||||
### 监控指标
|
||||
|
||||
| 指标 | 说明 | 告警阈值建议 |
|
||||
| ------------------------------------- | ------------------ | -------------- |
|
||||
| `scheduler_pending_pods` | 等待调度的 Pod 数 | 按集群规模设定 |
|
||||
| `scheduler_scheduling_duration_seconds`| 调度延迟 | P99 > 1s 告警 |
|
||||
| `scheduler_queue_incoming_pods_total` | 入队 Pod 速率 | 突增时告警 |
|
||||
| `scheduler_preemption_attempts_total` | 抢占尝试次数 | 异常增高时告警 |
|
||||
|
||||
### 版本升级
|
||||
|
||||
如条件允许，升级至 **Kubernetes 1.29+**，默认开启 SchedulingHint，从根源上优化大规模集群调度性能。
|
||||
Reference in New Issue
Block a user