Kubernetes中Python Pod因内存增长重启，如何无代码改进行Profiling？

阿华AIGC实验室

2026-5-14

解决Kubernetes中Python Flask+Socket.IO Pod内存泄漏的无代码修改Profiling方案

首先，退出码137已经明确告诉你，Pod是被Kubernetes的OOM Killer（内存不足终止器）干掉的，这和你观察到的内存持续增长完全对应。下面是几个不需要修改应用代码、也不用额外部署代理容器的Profiling方案，专门适配你的Python 3.5 + Flask + Socket.IO环境：

1. 使用`py-spy`：无依赖的Python采样分析器

py-spy是个用Rust写的轻量级分析工具，它不需要在你的容器里安装任何Python依赖（因为是静态编译的二进制文件），也不用修改你的应用代码，就能直接对运行中的Python进程做CPU和内存采样。操作步骤如下：

先下载对应你服务器架构的py-spy二进制文件到本地

把二进制文件复制到运行中的Pod里：

kubectl cp ./py-spy <你的Pod名称>:/tmp/py-spy

进入Pod的shell环境：

kubectl exec -it <你的Pod名称> -- /bin/bash

给py-spy添加执行权限：
```
chmod +x /tmp/py-spy
```
找到Python主进程的PID（通常是1，不确定的话用ps aux | grep python查看），然后运行采样命令生成火焰图：
```
/tmp/py-spy record -o /tmp/memory-profile.svg --pid <进程PID>
```
让它运行几分钟（根据你内存增长的速率调整），然后按Ctrl+C停止。最后把生成的火焰图复制到本地查看：
```
kubectl cp <你的Pod名称>:/tmp/memory-profile.svg ./memory-profile.svg
```
火焰图里能直观看到哪些函数占用了最多内存，帮你定位泄漏点。

2. 利用Kubernetes临时容器（Ephemeral Containers）

如果你的Kubernetes集群版本在1.23以上，临时容器是个更灵活的选择——它不需要修改原Pod的配置，就能直接挂载到运行中的Pod上，共享PID命名空间和文件系统：

运行以下命令创建一个和你应用同版本Python的临时容器，直接进入调试环境：
```
kubectl debug -it <你的Pod名称> --image=python:3.5 --target=<主容器名称> --share-processes
```
在本地另一个终端，把已下载好的py-spy二进制文件复制到临时容器里：
```
kubectl cp ./py-spy <你的Pod名称>:/tmp/py-spy -c <临时容器名称>
```
回到临时容器的shell，给py-spy添加执行权限：
```
chmod +x /tmp/py-spy
```
找到原Pod中Python主进程的PID（用ps aux就能看到共享的进程列表），然后按照方法1里的采样命令进行分析即可。这个方法的好处是不用在原容器里留下任何文件，调试完临时容器会自动销毁。

3. 快速监控内存趋势：`kubectl top`

虽然这不算严格的Profiling，但能帮你快速确认内存增长的规律：

实时查看Pod的内存使用情况：
```
kubectl top pod <你的Pod名称> --containers
```
每隔几分钟运行一次，或者用watch kubectl top pod <你的Pod名称>持续监控，能帮你判断内存是缓慢增长还是突然飙升，为后续Profiling提供方向。