Kubernetes场景下如何释放容器占用的资源？

第一步：排查容器内残留进程 #

• 程序退出后存在未被回收的孤儿/僵尸进程是最高发的原因，尤其是多进程架构的加密程序未正确处理子进程退出信号时极易出现。执行命令kubectl exec -it <目标Pod名称> -- ps aux查看容器内运行的进程列表，确认是否存在加密程序相关的残留子进程。
• 若存在残留进程，手动kill对应进程后观察资源指标是否回落。后续优化镜像启动逻辑，使用tini等轻量init进程作为容器1号进程，自动接管回收孤儿进程即可从根源解决该问题。

第二步：确认指标统计与Kubernetes资源配额逻辑 #

• 先校验Prometheus指标计算逻辑：如果你用irate(container_cpu_usage_seconds_total[1m])这类短窗口速率计算实时CPU利用率，优先等待2-3个指标采集周期（通常为30s-2min），排除采集延迟导致的指标更新滞后问题。
• 检查Pod的资源配置：若Pod未配置resources.limits或所在节点存在资源压力，kubelet可能不会立即释放该Pod预留的资源配额。尝试手动删除该Pod触发重建，若重建后的Pod初始资源指标正常，说明是当前Pod的cgroup统计残留导致。

第三步：排查内核态资源占用 #

• 由于你的程序使用了共享文件夹挂载，加密过程中产生的大量IO可能触发内核线程（如NFS共享对应的nfsiod、页回收线程kswapd等）运行，这类内核线程的资源消耗会被计入对应Pod的cgroup统计中，即使用户态程序退出，内核收尾任务也可能持续占用CPU一段时间。
• 可以登录Pod所在节点，进入对应Pod的cgroup目录执行cat tasks查看关联的线程ID，确认是否有内核线程残留关联。

永久修复方案 #

• 若确认是cgroup统计误差导致，可将Kubernetes集群升级至1.24及以上版本，该版本修复了多个cgroup v1场景下的资源统计不准问题；如果使用cgroup v2，可调整kubelet的CPU统计周期参数降低误差概率。

内容的提问来源于stack exchange，提问作者LyLa