免费容器保活手记：闲置只看 CPU，心跳走平台 exec

手里有两台免费容器，配置很小，只跑一点轻量东西。免费的意思是：平台随时可能回收闲置实例。于是保活成了刚需。但保活这件事本身也有讲究——保活脚本如果比业务还重，就本末倒置了。这篇记录一下我们最后定下来的做法：闲置判定只看 CPU，心跳走平台 exec，每 25 分钟一次。

一、闲置到底看什么：流量会骗人

最开始想当然的办法是看流量：容器还有没有请求进来，有流量就是活着，没流量就是闲了。实际跑了一段时间发现这个判据不靠谱。

流量太容易造假了。平台自己的健康检查会定期打过来，监控探针会定期打过来，公网上的扫描器也会时不时扫过来。这些都会产生流量，但没有一次是真实的使用。按流量判，一个常年没人用的容器也可能看起来“很忙”；反过来，一个正在跑定时任务的容器，对外可能一个请求都没有，按流量判它就是“闲的”。

真正能说明容器在干活的，是 CPU。跑任务、处理数据、执行脚本，都会留下 CPU 占用；而一个没人用、没任务的容器，CPU 会长时间贴在零附近。平台回收闲置实例，判据一般也是计算资源的占用情况，而不是“有没有人访问它”。所以我们把判定口径改成：只看 CPU，不看流量。CPU 长期为零，才是闲置；有真实的 CPU 活动，就不是闲置。

这个取舍还有一个好处：判定口径和平台的回收口径对齐了。保活的目标不是让容器看起来忙，而是让它真的产生一点计算活动。

二、心跳为什么走平台 exec，不在容器里装 agent

判定口径定下来之后，下一个问题是：心跳从哪里发。

直觉的做法是在容器里装一个常驻 agent，定时上报、定时干点活。但免费容器的资源本来就紧张，常驻 agent 要占内存、占 CPU，还要自己保证不死——为了保活，又引入了一个需要保活的东西，逻辑上就绕晕了。而且 agent 本身一旦出问题，保活就跟着失效，排查的时候还要先进容器看 agent 的日志。

我们最后选的是平台 exec：保活脚本跑在容器外面，每 25 分钟调用一次平台 API，在容器里执行一条轻量命令。容器内不留任何常驻进程，命令执行完就退出，不占内存，不留尾巴。平台侧下发、容器侧执行，执行本身产生一次真实的 CPU 活动，闲置判定也就满足了。

这个做法还有一个附带好处：保活脚本和业务完全解耦。容器重启、重建、换镜像，都不影响保活脚本；保活脚本出问题，也不会拖垮容器里的业务。两边各管各的，出问题的时候定位也快。

三、25 分钟一次：频率也要留余量

频率定 25 分钟，是一个留了余量的选择。太密了没有意义，白白消耗平台 API 调用次数，还可能被平台当成异常行为；太疏了会撞上回收阈值——真到阈值边缘才想起来敲门，万一某一次调用失败、网络抖动一下，中间就断档了。

25 分钟这个间隔，是在“远小于回收阈值”和“调用次数可控”之间取的平衡点。脚本本身是纯脚本实现，不依赖任何常驻服务，失败了也不立刻告警——单次失败大概率是网络抖动，下一轮补上就行；只有连续多次失败，才值得去看一眼。

四、平台停机窗口：不硬扛，等恢复

免费容器还有一个现实：平台每天傍晚有一段停机窗口，窗口内实例是不在的，之后恢复。这段时间里保活脚本再怎么敲门也没用，门根本不在。

我们的处理是：不硬扛。窗口内调用失败是预期内的，不报错、不刷屏、不发告警，等窗口过去、实例恢复了，下一轮心跳自然就接上了。保活的目标是“平台认为你还活着”，不是“7×24 小时绝对在线”。分清这两件事，脚本才能安静——安静的脚本才是好脚本，半夜不吵人的保活才是合格的保活。

五、边界：保活不等于管理

最后一条是边界。这两台容器目前的定位就是“保活 only”：只保证它们活着，不在上面部署业务、不改配置、不碰管理操作。保活脚本里不出现任何凭据，凭据只放在加密存储里，调用时再取。

这个边界现在看起来有点保守，但它是故意的。免费资源的定位一旦扩大，投入的管理成本会立刻超过它本身的价值。先让它稳定地活着，有朝一日真的需要它承担业务了，再谈管理也不迟。

总结

免费容器保活，最后就三条原则：判定看计算不看流量，心跳走平台不走容器内常驻，频率留余量、窗口期不硬扛。都不复杂，但每一条都是被“想当然的做法”坑过之后才定下来的。保活这件事，目标从来不是把脚本写得多漂亮，而是让它安静、便宜、长期不用管。