陈少文的博客
·
高频 IO 的 POD 并不适合设置 Limit
内容提要
基于Kubernetes的Elasticsearch频繁重启，导致服务几乎不可用。内存使用持续增长，超过限制后导致异常退出。系统内核版本、节点负载都正常。大量的Cache使用导致内存压力。解决方案是重启应用，推荐修改ECK的配置值来触发重启。
关键要点
-
基于Kubernetes的Elasticsearch频繁重启，导致服务几乎不可用。
-
Pod内存使用持续增长，接近限制后触发异常退出，错误日志显示Elasticsearch意外退出。
-
Elasticsearch Pod内存限制为64GB，JVM内存限制为32GB。
-
运行环境检测显示系统内核版本和集群版本正常，节点负载低。
-
大量Cache使用导致内存压力，触发容器Memory OOM。
-
Cache是操作系统用于缓存最近访问过的文件数据的一部分内存，Elasticsearch的RSS使用量维持在32GB。
-
直接清理Cache会影响其他应用，且清理时间较长。
-
推荐重启应用以释放Cache，重启方式包括删除Pod、重启StatefulSet和ECK Operator重启。
-
建议修改ECK的Request配置值来触发重启，避免新Pod被识别为新的Elasticsearch Node。
延伸问答
为什么基于Kubernetes的Elasticsearch会频繁重启？
Elasticsearch频繁重启是因为Pod内存使用持续增长，接近限制后触发异常退出。
Elasticsearch Pod的内存限制是多少？
Elasticsearch Pod的内存限制为64GB，JVM内存限制为32GB。
如何解决Elasticsearch Pod的内存压力问题？
推荐重启应用以释放Cache，重启方式包括删除Pod、重启StatefulSet和ECK Operator重启。
Cache对Elasticsearch的内存使用有什么影响？
大量Cache使用导致内存压力，触发容器Memory OOM，影响Elasticsearch的稳定性。
直接清理Cache有什么问题？
直接清理Cache会影响其他应用，并且清理时间较长，可能导致训练任务的缓存失效。
如何修改ECK配置以避免新Pod被识别为新的Elasticsearch Node？
建议修改ECK的Request配置值来触发重启应用，以避免新Pod被识别为新的Elasticsearch Node。
