kubelet的containerLogMaxSize参数未生效的排查及解决方法咨询

针对你遇到的问题，我结合EKS环境的特性整理了几个排查和解决方向，你可以一步步来试：

1. 确认kubelet配置文件的正确性 #

首先检查你修改的kubelet配置文件（通常是/var/lib/kubelet/config.yaml），确认containerLogMaxSize确实设置为"100 Mi"，注意单位是Mi而不是MB，拼写和格式不能错。如果是通过EKS节点组的配置注入的参数，还要检查节点组的启动脚本或配置模板，确保你的配置没有被节点初始化过程覆盖。

2. 验证kubelet是否成功加载新配置 #

执行以下命令检查kubelet配置的有效性：

kubelet --config /var/lib/kubelet/config.yaml --validate-config

如果有配置错误会直接提示。另外查看kubelet的重启日志，确认没有加载失败的情况：

journalctl -u kubelet | grep "containerLogMaxSize"

看看日志里有没有显示加载了这个新参数的记录。

3. 检查容器运行时（containerd）的日志配置 #

EKS默认使用containerd作为容器运行时，它自身的日志轮转配置可能会覆盖kubelet的设置。打开/etc/containerd/config.toml，找到[plugins."io.containerd.grpc.v1.cri".containerd.default_runtime.options]部分，检查是否存在max_log_size参数：

• 如果这个参数设置为10（单位是MB），会优先生效，你需要把它改成100或者注释掉这个参数，让kubelet的配置接管。
• 修改后记得重启containerd服务：systemctl restart containerd，再重启kubelet。

4. 测试新容器的日志行为 #

需要注意的是，已运行的容器不会自动应用新的kubelet配置，只有新启动的容器才会使用更新后的日志轮转规则。你可以启动一个测试容器，比如：

kubectl run test-log --image=busybox --command -- sh -c "while true; do echo 'test log line' >> /dev/stdout; sleep 0.1; done"

然后监控这个容器的日志文件大小（通常在/var/log/pods/下对应容器的日志路径），看看是否到100MB才触发轮转。

5. 排查节点组的配置覆盖问题 #

如果你是通过EKS节点组管理节点，有些节点组会在每次节点启动时通过用户数据或CloudFormation模板重置kubelet配置。你可以检查节点组的用户数据，看看是否有脚本会覆盖/var/lib/kubelet/config.yaml里的参数，如果有的话，需要在节点组的配置里直接修改containerLogMaxSize参数，而不是手动修改节点上的文件。

备注：内容来源于stack exchange，提问作者merlin2011