工作日报 - 2026-07-23

一、今日工作内容

1. 生成 kubectl 筛选 exception 节点脚本

根据需求编写脚本，筛选出带有 node-type=exception:NoSchedule 污点的节点。

• 产出文件：list_exception_nodes.sh
• 实现方式：通过 kubectl get nodes -o json 结合 jq 过滤 taints
• 运行方式：./list_exception_nodes.sh

2. 排查 exception 节点 Pod 分布不均问题

收到反馈：三台 exception 节点 Pod 数量分布不均：

节点	max-pods	current-pods	CPU	内存
szb12033	110	36	160核	756G
szb13034	150	86	160核	1T
szb14017	110	75	160核	756G

完成以下工作：

• 编写排查脚本 check_exception_node_distribution.sh，一键收集：
  • 节点状态与污点
  • Allocatable / Allocated 资源
  • 各节点 Pod 数量与资源请求汇总
  • 最近 FailedScheduling 和 Scheduled 事件
• 编写排查文档 rke1-k8s1.16.3-exception节点Pod分布不均排查文档.md

3. 分析排查结果

读取 exception_node_check_20260723_161231 目录下的排查数据，完成分析：

• 三台节点均为 Ready，无 FailedScheduling 事件
• 调度器工作正常，小规格多副本 Deployment 分布相对均匀
• 分布不均主因：szb13034 承载了大量大规格、高内存请求的独占型 Pod
• szb13034 内存为 1T，比另外两台多约 33%，调度器更倾向于将大资源请求 Pod 调度到该节点

关键指标：

节点	Pod 数	CPU requests	Memory requests	Memory limits
szb12033	38	1430m (0%)	3912Mi (0%)	48%
szb13034	84	22050m (13%)	174996Mi (16%)	99%
szb14017	74	2130m (1%)	7412Mi (0%)	124%

4. 输出分析结论文档

• 产出文件：rke1-k8s1.16.3-exception节点Pod分布不均分析结论.md
• 内容包含：原因分析、风险识别、排查建议、优化建议、最终结论

5. szb13032 节点异常问题处理

处理节点 szb13032 异常事件：

操作	结果
重启 kubelet	未解决
重启 docker 服务	docker 服务 hang 住
重启物理主机	问题解决，节点恢复

• 初步判断问题出在 Docker daemon 或系统底层资源层面，而非 kubelet 本身
• 已记录处理过程与后续排查建议，形成 rke1-k8s1.16.3-szb13032节点异常排查处理记录.md

6. 阅读 kubelet2.log 分析 coredns 调度问题

通过分析 kubelet2.log，发现：

• coredns Pod coredns-6d546f654-7mt65 被调度到 szb13032

• Volume 挂载、Calico CNI IP 分配均成功

• 但容器启动时 Docker runtime 反复返回 DeadlineExceeded：

  StartContainer ... failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
  ContainerStatus ... failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded

• 随后 kubelet PLEG 不健康，节点变为 NotReady：

  skipping pod synchronization - PLEG is not healthy
  Node became not ready: ... Reason:KubeletNotReady Message:PLEG is not healthy

• 结论：coredns 调度到 szb13032 失败是表象，根因是 Docker runtime 无响应导致 kubelet CRI 调用超时

二、主要结论

1. 调度功能正常：节点 Ready，无调度失败事件，常规多副本 Pod 已被打散。
2. Pod 数量差异主因是 Pod 规格差异：szb13034 上运行了多台大规格业务 Pod，导致数量和资源请求偏高。
3. 存在运行风险：
   • szb13034 memory limits 已达 99%
   • szb14017 memory limits 已达 124%（超过 allocatable）
   • szb13034 单节点承载压力过大，存在故障扩散风险

三、产出文件清单

文件名	说明
list_exception_nodes.sh	筛选 exception 污点节点的脚本
check_exception_node_distribution.sh	exception 节点 Pod 分布不均一键排查脚本
rke1-k8s1.16.3-exception节点Pod分布不均排查文档.md	排查思路与步骤文档
rke1-k8s1.16.3-exception节点Pod分布不均分析结论.md	基于实际数据的分析结论
rke1-k8s1.16.3-szb13032节点异常排查处理记录.md	szb13032 节点异常处理记录
工作日报-20260723.md	本日报

四、后续待办

1. 检查 szb13034 上大规格 Pod 的 nodeSelector / affinity / tolerations，确认是否被强制绑定到该节点。
2. 评估将部分大规格 Pod 从 szb13034 迁移到 szb12033 / szb14017 的可行性。
3. 统一三台 exception 节点的 max-pods 配置。
4. 考虑部署 Kubernetes Descheduler，配置 LowNodeUtilization 策略实现长期均衡。
5. 关注 szb13034 和 szb14017 的实际内存使用，防范 OOMKill 风险。
6. 为 szb13032 类似故障建立标准信息收集流程（sosreport、dmesg、journalctl 等），避免重启后丢失现场。
7. 评估 Docker 19.3.8 稳定性，考虑升级 Docker 或迁移至 containerd。