声明:这是我在大学毕业后进入第二家互联网公司学习的内容

背景

周末群里突然告警，信息是eks的node磁盘超过到80%的阀值，这台机器没有计算缓存的文件，而且经常更新，为啥会出现这个问题呢，一起来看看吧

监控

查看监控，可以发现这台机器经过3个多月的时间磁盘一直在上涨

图片链接 ###

我突然想到这会不会是每次容器更新新版本的镜像导致，查询资料发现

  • –image-gc-high-threshold 参数用于定义触发映像垃圾收集的磁盘使用百分比。默认值为 85%。
  • –image-gc-low-threshold 参数用于定义映像垃圾收集尝试释放的磁盘使用百分比。默认值为 80%。

这个时候要么增加告警阀值为85%以上，要么就尝试清理磁盘

查看eks的最佳实践发现

EKS最佳实践

要使用 Amazon EKS 工作线程节点清理映像缓存，请使用下面的 kubelet 垃圾收集参数：

  • –image-gc-high-threshold
  • –image-gc-low-threshold

它还需要进入到服务器去改kubelet并且重启，非常的麻烦，而且我们的服务器默认没有ssh权限，在设置节点组的时候就没有打开（因为我们没有需求登录到任何一台eks的node节点）

感觉它的推荐解决方法不是很靠谱

我的最佳实践

由于EKS的Node底层使用的是EC2 Auto Scaling模型，它的更新机制是，关机就会重新启动一台新的机器，所以我发现每台服务器的镜像用的是Amazon Linux 2 AMI（AWS自己的操作系统Amazon Linux 2），这个镜像每个月都会更新一次

EKS的Node更新操作系统的策略分为滚动更新和强制更新

  • 滚动更新会考虑集群的 Pod 中断预算。如果 Pod（一组容器）中断预算问题导致 Amazon EKS 无法正常耗尽在此节点组上运行的 Pod（一组容器），则更新将失败。

  • 强制更新不考虑 Pod 中断预算。通过强制节点重新启动，无论是否存在 Pod 中断预算问题，都会发生更新。

我选择滚动更新，期间容器会安全地被驱逐，并且更新到新的节点上

总结

以后每2个月定时更新一次节点组，一个是为了更新到最新的AMI系统（可能修复漏洞啥的），另一个就是为了清理镜像

定时执行这个脚本即可

1
eksctl upgrade nodegroup --name=node-group-name --cluster=cluster-name

参考资料

关于Kubernetes image垃圾镜像容器的回收

如何配置 Amazon EKS 工作线程节点，以按指定的磁盘使用百分比清理映像缓存？

Updating a managed node group