我们有一个 Kubernetes 服务，它的 pod 需要一些时间来预热第一个请求。基本上，第一个传入的请求将从 Redis 读取一些缓存的值，这些请求可能需要更长的处理时间。当这些新创建的 Pod 准备就绪并接收全部流量时，它们可能会在长达 30 秒内变得响应不快，然后才能从 Redis 正确加载和缓存所有内容。
我知道，我们绝对应该重组应用程序以防止这种情况，不幸的是，这在不久的将来是不可行的(我们正在研究它(。
如果可以减轻新创建的 pod 的重量，那就太好了，这样它们在开始时将收到 1/10 的流量，随着时间的推移，权重会增加。这对于我们应用程序的新部署版本也非常有用，可以查看它的行为是否正确。
为什么您需要在第一次调用中加载缓存，而不是在与就绪探测挂钩的心跳中加载？另一种选择是在 kubernetes 中使用 init 容器
。直到应用程序可以重组以在内部执行此"启动"...
在 Kubernetes 上运行时，请查看容器生命周期钩子，特别是PostStart钩子。此处的文档和此处的示例。
似乎"...在 postStart 处理程序完成之前，容器的状态不会设置为"正在运行"，这可以帮助您。
很少有像"...不能保证钩子将在容器入口点之前执行"，因为"...postStart 处理程序相对于容器的代码异步运行"和"...没有参数传递给处理程序"。
也许自定义脚本可以使用一些重试逻辑来模拟第一个请求以等待应用程序启动？