我们有一个Kubernetes服务，其Pod需要一些时间来准备第一个请求。基本上，第一个传入请求将从Redis读取一些缓存的值，并且这些请求可能需要更长的时间才能处理。当这些新创建的Pod准备就绪并接收全部流量时，在从Redis正确加载并缓存所有内容之前，它们可能在30秒内反应迟钝。
我知道，我们绝对应该对应用程序进行重组，以防止这种情况发生，但是不幸的是，这在不久的将来是不可行的（我们正在努力）。
如果有可能减少新创建的Pod的重量，那将是很好的，因此，随着时间的流逝，随着时间的增加，它们将在开始时收到1/10的流量。这对于我们新部署的应用程序版本查看其是否正常也非常有用。
答案 0 :(得分：1)
为什么您需要在第一次调用时加载缓存，而不是挂在就绪探针上的心跳中？另一种选择是在kubernetes中使用init containers
答案 1 :(得分：1)
直到可以对应用程序进行重组以在内部进行“启动”为止。
对于在Kubernetes上运行时，请查看Container Lifecycle Hooks，尤其是PostStart钩子。文档here和示例here。
似乎“ ...在postStart处理程序完成之前，容器的状态未设置为RUNNING”的行为可以帮助您。
几乎没有类似“ ...无法保证钩子在容器ENTRYPOINT之前执行”的陷阱，因为“ ... postStart处理程序相对于容器的代码异步运行”，而“ ...没有参数”传递给处理程序”。
也许自定义脚本可以使用一些重试逻辑来模拟第一个请求，以等待应用程序启动？