最近发现打榜人员提供的被测服务因为 OOM 导致被测服务 POD 重启，而 POD 重启对于大多数榜单的测试流程来说都是不可接受的。
POD 重启对测试流程不可接受的原因在于，被测服务往往不是无状态的。有些榜单在测试的时候需要给被测服务传入一些初始化数据，例如推荐相关的榜单，需要传入推荐的候选数据；文档搜索相关的榜单，需要传入待搜索的文档。因为这些初始化数据使得被测服务无法做到无状态，所以造就了 POD 重启后，服务丢失数据从而无法合理进行预测。
POD 重启的原因在于，打榜人员提交被测服务的容器镜像后，榜单测试方会利用 helm 进行打包，而默认的 helm chart 使用的是 deployment，而非 job，导致了被测服务 POD 在出错后被重启。
最终的解决也简单，从默认的 helm chart 中将 template/deployment.yaml 删了，然后再补充一个 template/job.yaml。
补充，其实 POD 重启还有一个问题，那就是 POD 重启后，kubectl logs pod 只能看到重启后 POD 的日志，而看不到历史 POD 的日志，从而不知道 POD 最开始因为什么原因导致 Error。（当前打榜平台并没有对 K8S 的 POD 日志进行持久化存储）