Azure AKS节点syslog/内核日志占满磁盘，如何配置日志轮转策略

你碰到的问题核心非常明确：AKS默认针对容器运行时的日志做了完整的轮转适配，但节点级原生系统日志（syslog、内核日志、messages类）的默认轮转阈值、保留策略偏宽松，在日志量较大的节点上很容易攒出高磁盘占用，最终触发节点磁盘压力驱逐Pod。

你初步考虑的DaemonSet管理/var/log方案的局限性 #

先明确结论：这个方案能实现功能，但完全不符合集群管理的最佳实践，长期维护会踩很多坑：

• 把OS层的日志管理职责上移到K8s层，本质是绕过节点本身的日志治理机制，容易出现权限冲突、日志截断时机不可控、漏管非预期路径日志的问题
• 存在死锁风险：如果节点磁盘已经达到90%以上的使用率，对应的DaemonSet可能因为镜像拉取失败、节点资源不足无法正常调度运行，反而没法在最需要清理空间的时候发挥作用
• 长期维护成本极高：每次AKS节点版本升级、OS镜像迭代，都需要重新校验DaemonSet的hostPath挂载路径、截断逻辑和新版本OS的兼容性，额外增加了不必要的运维负担
• 违背了节点管理的职责边界：K8s层的DaemonSet应该聚焦于工作负载观测、流量治理这类平台核心能力，OS层的配置应该优先通过节点原生机制实现。

符合AKS最佳实践的分层处理方案 #

1. 首选：调整节点原生的系统日志轮转配置（零额外组件，稳定性最高） #

AKS默认的Ubuntu节点基于rsyslog + logrotate组合管理系统日志，默认配置通常是单日志文件达到100M才触发轮转、最多保留7个压缩归档，在日志密集的节点上很容易产生几十G的无效占用。
你可以通过AKS节点池的自定义初始化能力，批量在所有节点上下发调整后的轮转策略：

• 修改/etc/logrotate.d/rsyslog规则：把单文件轮转阈值调整为10M-50M区间，最多保留3个压缩归档，超出大小的归档直接自动删除；对内核日志、syslog单独设置更严格的轮转阈值
• 配套调整/etc/rsyslog.conf的写入策略，减少无意义的日志缓存占空间
• 针对systemd管理的journal日志，通过journald.conf设置最大占用空间为节点磁盘容量的2%，避免journal日志不受控增长

这套配置完全运行在节点OS层，即使节点上K8s组件完全异常，日志轮转也能正常触发，不存在依赖K8s运行才能清理空间的死锁问题。

2. 短期应急：快速释放已占用的磁盘空间 #

如果当前节点已经因为磁盘满触发驱逐，不需要等待配置生效就能快速恢复：

• 执行journalctl --vacuum-size=200M，快速把systemd journal日志压缩到200M以内，通常这一步就能释放30%-50%的系统日志占用
• 对正在写入的syslog、kern.log、messages执行安全截断：truncate -s 0 /var/log/syslog /var/log/kern.log /var/log/messages，注意不要直接删除这些正在被rsyslog写入的文件，否则会导致服务停止写日志

3. 长期增强：配合日志采集进一步降低本地磁盘占用 #

等基础轮转配置稳定运行后，如果你通过Azure Monitor、Container Insights采集节点系统日志，完全可以把节点本地的日志保留时间压缩到最短：采集逻辑会从日志文件读取内容上报到平台后，节点本地不需要长期留存完整的日志归档，这时候可以把本地日志的保留阈值调整为仅留存最近10分钟的日志内容，进一步压缩系统日志的磁盘占用。

常见配置踩坑提醒 #

• 不要为了省磁盘直接禁用rsyslog服务：AKS节点的网络插件、节点健康检查组件依赖syslog输出的日志做故障定位，完全禁用会导致后续节点异常时没有排查依据
• 不要通过带hostPath挂载的DaemonSet做强权限的日志删除操作：如果容器进程权限控制不当，误删/var/log路径下的audit日志、kubelet认证缓存等关键文件，会直接导致节点进入NotReady状态

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