主题
rke1-k8s1.16.3 exception 节点 Pod 分布不均分析结论
数据来源：
exception_node_check_20260723_161231排查结果
一、问题现象
三台带有 node-type=exception:NoSchedule 污点的节点 Pod 数量分布不均：
| 节点 | max-pods | current-pods | CPU | 内存 |
|---|---|---|---|---|
| szb12033 | 110 | 36 | 160核 | 756G |
| szb13034 | 150 | 86 | 160核 | 1T |
| szb14017 | 110 | 75 | 160核 | 756G |
二、核心指标汇总
| 指标 | szb12033 | szb13034 | szb14017 |
|---|---|---|---|
| 节点状态 | Ready | Ready | Ready |
| 运行 Pod 总数 | 38 | 84 | 74 |
| CPU requests | 1430m (0%) | 22050m (13%) | 2130m (1%) |
| Memory requests | 3912Mi (0%) | 174996Mi (16%) | 7412Mi (0%) |
| CPU limits | 162 (101%) | 491 (306%) | 448 (280%) |
| Memory limits | 377344Mi (48%) | 1063424Mi (99%) | 963072Mi (124%) |
| Allocatable 内存 | 790730396Ki (~754G) | 1089762388Ki (~1T) | 790677652Ki (~754G) |
| FailedScheduling 事件 | 无 | 无 | 无 |
注：Pod 数量包含
cattle-node-agent、calico-node、nodelocaldns、trident-csi等基础 Pod。
三、分布不均原因分析
3.1 调度器本身无异常
- 三台节点均为
Ready状态 - 未产生
FailedScheduling事件 - 多副本小规格 Deployment 在三台节点上分布相对均匀
这说明调度功能正常，Pod 数量差异不是由节点不可调度或调度失败导致的。
3.2 szb13034 承载了大量大规格 Pod
szb13034 上运行了多台仅在该节点出现的大规格业务 Pod，例如：
| Pod | CPU requests | Memory requests |
|---|---|---|
| a11-center-prd-service-tag-cod | 1 | 16Gi |
| chq-bills-bills | 1 | 16Gi |
| a01-dianpei-private-for-store | 1 | 8Gi |
| a01-order-crmapiservice | 1 | 8Gi |
| a01-order-crmwdnew-service | 1 | 8Gi |
| a11-center-orderprint-template | 1 | 8Gi |
| a11-center-reorganize-order-route-query | 1 | 8Gi |
| a11-center-trade-center-openapi-gateway | 1 | 8Gi |
一台 1C/8Gi 的 Pod，相当于约 40 个 20m/100Mi 的小 Pod。这些大规格 Pod 集中在 szb13034，直接导致了该节点 Pod 数量和资源 requests 远高于其他两台。
3.3 szb13034 内存规格更大
- szb13034：1T 内存
- szb12033 / szb14017：756G 内存
Kubernetes 默认调度器在调度大资源请求 Pod 时，会优先选择资源更充足的节点。szb13034 内存多约 33%，因此更容易被选中承载大内存 Pod。
3.4 小规格多副本 Pod 分布相对均匀
以下 Deployment 在三台节点上的副本分布基本均衡：
| Deployment | szb12033 | szb13034 | szb14017 |
|---|---|---|---|
| a11-center-dtd-bill-job | 3 | 3 | 3 |
| a11-center-reorganize-order-consumer | 3 | 3 | 3 |
| a11-center-perfect-trace-order-loader | 2 | 2 | 2 |
| a11-center-external-data-hbase-consumer | 2 | 2 | 2 |
| a11-center-route-eta-fb | 2 | 2 | 2 |
| a11-center-waybill-center-forbes-sender | 3 | 3 | 4 |
这说明常规滚动更新/副本调度机制工作正常，Pod 不均主要来自于 szb13034 上的独占型大规格 Pod。
3.5 部分 Deployment 未调度到 szb12033
例如：
a08-mobile-open-api：szb13034 有 10 个，szb14017 有 12 个，szb12033 有 0 个a03-finance-fund-kafka：szb13034 有 3 个，szb14017 有 3 个，szb12033 有 0 个
可能原因：
- 这些 Pod 创建时 szb12033 尚不可调度或资源不足
- 存在节点选择器（nodeSelector）或节点亲和性（nodeAffinity）约束
- 滚动更新时旧 Pod 未迁移到新节点
- Pod 反亲和性导致副本被限制在部分节点
四、风险识别
4.1 limits 严重超售
| 节点 | Memory limits 占比 |
|---|---|
| szb12033 | 48% |
| szb13034 | 99% |
| szb14017 | 124% |
- szb13034 的 memory limits 已接近 100%
- szb14017 的 memory limits 已超过 allocatable（124%）
风险：当业务实际内存使用接近 limits 时，极易触发 OOMKill。虽然 Kubernetes 调度只看 requests，但运行时资源竞争取决于实际使用与 limits。
4.2 单节点故障影响面大
szb13034 承载了最多数量的 Pod，且包含多台大规格业务 Pod。一旦该节点故障或需要维护，其上 Pod 同时迁移会对剩余节点造成巨大压力，可能引发级联故障。
4.3 max-pods 配置不一致
szb13034 的 max-pods 为 150，另外两台为 110。这不利于横向对比节点负载，也可能导致调度上限判断不一致。
五、排查建议
5.1 检查大规格 Pod 的调度约束
确认 szb13034 上的大规格 Pod 是"只能"运行在该节点，还是"恰好"运行在该节点：
bash
# 查看 Pod 的 nodeSelector 和 affinity
kubectl get pod <pod-name> -n default -o yaml | grep -A30 nodeSelector
kubectl get pod <pod-name> -n default -o yaml | grep -A50 affinity
# 查看 Deployment 级别的调度约束
kubectl get deployment <deployment-name> -n default -o yaml | grep -A50 affinity5.2 检查节点标签差异
bash
kubectl get nodes -l node-type=exception --show-labels确认 szb13034 是否有其他节点标签吸引了大规格 Pod。
5.3 查看调度器日志
bash
kubectl -n kube-system get pods -l component=kube-scheduler
kubectl -n kube-system logs <kube-scheduler-pod> | grep -E "szb12033|szb13034|szb14017"虽然当前无 FailedScheduling 事件，但调度器日志可以解释为什么某些 Pod 被调度到特定节点。
5.4 使用 kubectl top 查看实际资源使用
bash
kubectl top node szb12033 szb13034 szb14017
kubectl top pod --all-namespaces --sort-by=memory确认实际使用是否与 requests/limits 趋势一致。
六、优化建议
统一 max-pods 配置 三台节点 CPU 相同，建议统一为 110 或 150，避免理解偏差。
评估大规格 Pod 迁移可行性 如果 szb12033/szb14017 的 requests 余量充足，可以通过滚动更新将部分 szb13034 上的大规格 Pod 迁移过去，降低单节点集中度。
部署 Kubernetes Descheduler 配置
LowNodeUtilization和RemoveDuplicates策略，让 Pod 分布更均衡。设置合理的 resource limits 尤其是 szb14017 memory limits 已达 124%，建议审查这些 Pod 的 limits 是否设置过大，必要时调低或迁移。
增加 Pod 反亲和性 对于关键大规格 Deployment，建议配置
podAntiAffinity，避免同类 Pod 过度集中在单一节点。
七、结论
当前三台 exception 节点的 Pod 数量差异主要由 szb13034 承载了更多大规格、高内存请求的业务 Pod 导致。调度器本身工作正常，节点状态良好，无调度失败事件。
但需要关注：
- szb13034 memory limits 已达 99%
- szb14017 memory limits 已达 124%
- szb13034 单节点承载压力过大，存在故障扩散风险
建议尽快排查大规格 Pod 的调度约束，并考虑通过迁移或扩容来平衡负载。