英文:
Kubernetes Google Server-side tagging memory leak troubleshooting
问题
最近，我们部署了由Google提供的服务器端标签解决方案的Kubernetes集群。他们提供了一个docker镜像，我们在部署在DigitalOcean上的托管Kubernetes集群中使用。
我们开始观察到内存使用逐渐增加。通过进一步分析这个问题并运行一些测试，我们怀疑上面列出的运行Docker镜像的容器导致了这个问题。下面你可以看到，重新启动容器导致内存使用显著下降。kubectl top pods -A给出的内存使用情况也表现出相同的下降。
我们已经为运行此镜像的部署设置了资源限制，以防止其增长到节点资源用尽。然而，我们没有预料到这个镜像会出现这种行为。有没有人知道这个镜像是否存在这个常见问题？还可能有其他原因，比如集群设置导致了这个问题吗？如何处理这种潜在的内存泄漏的最佳实践是什么？我们目前考虑的一个解决方案是每隔24小时安排一个rollout restart。
英文:
Recently, we deployed a Kubernetes cluster of the server-side tagging solution provided by Google. They provide a docker image that we are using in our managed Kubernetes cluster that is deployed on DigitalOcean.
We started observing that the memory usage is gradually increasing overtime. By analysing this problem further and running some tests we suspect that the containers running the Docker image listed above are causing this problem. Below you can see that restarting the containers resulted in a significant drop in the memory usage. The memory usage given by kubectl top pods -A demonstrated the same drop.
We have already set the resource limits for deployments running this image to prevent it from growing till the nodes run out of resources. However, we did not expect this behavior from this image. Does anyone know if this is a common problem with this image? Could there be any other reasons such as cluster settings causing this problem? And what would be the best practise to handle this potential memory leak? One of the solutions we are currently thinking of is scheduling a rollout restart every 24 hours.
答案1
得分: 0
问题已经解决。该问题似乎是在2023年6月6/7日发布的Google标签管理器版本中出现的，并在2023年6月13日发布的版本中得到解决。
英文:
The problem has resolved itself. The problem seemed to occur along with the June 6/7, 2023 release of Google Tag Manager and was resolved with the June 13, 2023 release.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论