3.7 KiB
3.7 KiB
Email Task 部署故障排查与修复记录
1. 问题现象
部署 email-task 时出现调度失败:
Warning FailedScheduling 0/1 nodes are available: 1 Insufficient memory.
no new claims to deallocate, preemption: 0/1 nodes are available:
1 No preemption victims found for incoming pod.
表现为:
Deployment期望副本无法全部就绪Pod长时间Pending
2. 排查思路
按以下顺序排查:
- 看部署配置是否过高请求(
requests/limits+replicas) - 看节点可分配资源和已分配资源(确认是否真的是内存不足)
- 看滚动策略是否会额外拉起新 Pod(
maxSurge可能放大内存压力) - 看容器健康检查是否匹配服务类型(任务型服务不一定监听端口)
3. 关键排查命令
3.1 查看节点可分配资源
kubectl get nodes -o custom-columns=NAME:.metadata.name,ALLOCATABLE_CPU:.status.allocatable.cpu,ALLOCATABLE_MEM:.status.allocatable.memory
3.2 查看部署与 Pod 状态
kubectl -n juwan get deploy email-task -o wide
kubectl -n juwan get pods -l app=email-task -o wide
kubectl -n juwan describe pod -l app=email-task
3.3 查看节点资源分配占比
kubectl describe node minikube
关注输出中的 Allocated resources:
memory requests已接近节点上限(本次约 97%)
3.4 查看部署策略与探针配置
kubectl -n juwan get deploy email-task -o yaml
kubectl -n juwan logs deploy/email-task --tail=120
4. 根因分析
本次是组合问题:
-
内存请求过高 + 副本过多
- 原始配置:
replicas=3 - 每个 Pod 请求
memory=512Mi - 单节点场景下,叠加现有业务后无法继续调度
- 原始配置:
-
滚动更新默认
maxSurge=25%- 更新时可能额外起新 Pod,进一步触发内存不足
-
探针不匹配服务行为
- 原配置为
tcpSocket:8080探针 - 实际
email-task是任务型服务,日志显示启动后并未提供该端口服务 - 导致
Readiness/Liveness持续失败
- 原配置为
5. 修复方案
仅修改文件:
deploy/k8s/service/email/email.yaml
5.1 降低资源请求与副本基线
replicas: 3 -> 1requests.cpu: 500m -> 100mrequests.memory: 512Mi -> 128Milimits.cpu: 1000m -> 500mlimits.memory: 1024Mi -> 512Mi
5.2 调整 HPA 基线与上限
- 两个 HPA(CPU / Memory)统一:
minReplicas: 3 -> 1maxReplicas: 10 -> 3
5.3 调整滚动发布策略
strategy.rollingUpdate.maxSurge: 0strategy.rollingUpdate.maxUnavailable: 1
目的:避免滚动期间额外拉起 Pod 造成瞬时内存不足。
5.4 移除不适配的 8080 TCP 探针
移除:
readinessProbe.tcpSocket:8080livenessProbe.tcpSocket:8080
6. 修复执行命令
kubectl apply -f deploy/k8s/service/email/email.yaml
kubectl -n juwan rollout restart deploy/email-task
kubectl -n juwan rollout status deploy/email-task --timeout=180s
kubectl -n juwan get pods -l app=email-task -o wide
kubectl -n juwan describe pods -l app=email-task | Select-String -Pattern 'FailedScheduling|Unhealthy|Warning|Events|Node:'
7. 修复结果
Deployment滚动成功- 新 Pod 成功调度并
Running - 无新的
FailedScheduling与Unhealthy事件
8. 后续建议
- 若要恢复多副本,先按节点容量逐步上调(建议先 2 副本并观测)。
- 为任务型服务设计更合适的健康检查方式:
- 可考虑
exec探针或业务自检端点。
- 可考虑
- 在单节点开发环境中统一降低默认
requests,防止多个服务叠加后调度失败。 - 如需高可用,建议扩容节点而不是仅依赖压缩资源。