kube-scheduler日志过大引发Master节点DiskPressure告警的原因及解决咨询

嘿，这个问题我之前在大规模K8s集群里碰到过类似的情况，咱们一步步拆解原因和解决办法：

为什么会出现这种情况？ #

1. 残留的节点资源没清干净 #

节点ip-10-0-0-1.ec2.internal肯定已经挂了（要么EC2实例被删了，要么手动移除了节点），但K8s的API Server里还留着这个节点的记录。kube-scheduler每次调度Pod的时候，都会跑节点预选逻辑（就是你日志里提到的predicates.go里的代码），每次检查到这个“幽灵节点”就会报错，500节点的集群调度频率很高，错误日志自然疯狂增长。

2. scheduler缓存同步出问题 #

kube-scheduler会本地缓存节点状态，1.13.x这个老版本在大规模集群节点变动时，偶尔会出现缓存没跟上API Server的情况——明明节点已经删了，缓存里还存着，导致scheduler反复去查这个不存在的节点，刷出一堆重复错误。

3. Logrotate的延迟压缩放大了问题 #

虽然Logrotate每小时跑，但delaycompress意味着旧日志不会立刻压缩，这1小时里纯文本的错误日志疯狂写入，直接飙到20GB，瞬间把80GB的盘占满。

解决和规避方案 #

1. 先清掉残留的节点（最紧急） #

先确认这个节点是不是真的没了：

kubectl get nodes | grep ip-10-0-0-1.ec2.internal

如果没结果，直接强制删除这个残留的节点记录：

kubectl delete node ip-10-0-0-1.ec2.internal --grace-period=0 --force

这一步做完，scheduler就不会再盯着这个节点报错了，日志量会立刻降下来。

2. 调整Logrotate配置，减少磁盘压力 #

找到kube-scheduler的Logrotate配置（一般在/etc/logrotate.d/kube-scheduler），修改成这样：

/var/log/kube-scheduler.log {
    hourly
    rotate 5
    compress
    # 去掉delaycompress，让旧日志轮转后立刻压缩
    missingok
    notifempty
    copytruncate
    # 再加个size限制，比如1GB就轮转，不用等1小时
    size 1G
}

这样就算再出现日志暴涨，单份日志最多1GB，而且会立刻压缩，不会一下子占满磁盘。

3. 调低scheduler的日志级别（临时缓解） #

1.13.x版本的scheduler默认日志级别可能偏高，你可以修改它的启动参数，把日志级别降到--v=2（原来可能是v=3或更高），这样非关键的错误就不会疯狂输出了。在kops部署的集群里，你可以通过kops edit cluster或者修改Master实例组的配置来调整这个参数。

4. 升级K8s版本（长期根治） #

1.13.x是真的老了，早就过了维护期，后续的版本（比如1.21+）修复了很多缓存同步和日志输出的问题。如果集群兼容性允许，建议尽快升级到稳定的新版本，从根源上避免这类老bug。

5. 加个定时任务清理旧日志 #

可以加个crontab任务，定期清理过期的压缩日志，防止日积月累占磁盘：

# 每天凌晨0点删除7天前的kube-scheduler压缩日志
0 0 * * * find /var/log -name "kube-scheduler.log.*.gz" -mtime +7 -delete

内容的提问来源于stack exchange，提问作者AlexS