高频 IO 的 POD 并不适合设置 Limit
内容提要
基于Kubernetes的Elasticsearch频繁重启，导致服务几乎不可用。内存使用持续增长，超过限制后导致异常退出。系统内核版本、节点负载都正常。大量的Cache使用导致内存压力。解决方案是重启应用，推荐修改ECK的配置值来触发重启。
延伸解读
内存限制与OOM触发机制
文章指出，容器Memory OOM的触发指标是container_memory_working_set_bytes，其组成为RSS和Cache。Elasticsearch的RSS稳定在32GB，但Cache持续增长，导致working_set超过64GB限制而触发OOM。这解释了为何JVM内存限制32GB仍会出现Pod异常退出。
Cache增长与IO压力的关联
大量Cache使用源于频繁的IO操作，操作系统会缓存最近访问的文件数据。在数据导入过程中，Page Cache持续增长，直到导入停止才不再增加，但不会立即释放。这提示高频IO场景下，Cache可能成为内存限制的隐形杀手。
清理Cache的局限性与风险
直接清理Cache无法按应用维度进行，会影响主机上其他应用，且清理耗时较长。此外，集群运行训练任务，若使用相同数据集，清理Cache会导致缓存失效，增加训练时间。因此，重启应用成为更可行的释放Cache方式。
重启方式的选择与注意事项
文章推荐修改ECK的Request配置值来触发重启，避免新Pod被识别为新的Elasticsearch Node而触发索引重建。其他方式如删除Pod或重启StatefulSet可能带来此风险。但作者也指出，具体触发条件尚不完全确定，需谨慎操作。
Q&A
为什么基于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。
