我需要了解哪些限制可以导致kubectl rollout超时，“watch until until timeout”。
我正在推出一项需要在启动时加载数据库的服务。我们在一个节点上运行此服务，遗憾的是它与数据库服务器的连接速度较慢。 51分钟后，它还有相当多的数据需要加载，但是当推出超时时，即使我在服务上的“初始活动延迟”设置为90分钟。还有什么可能导致它在最初的活动延迟之前超时？
更新：
要回答评论和回答：
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:17:39Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.5+coreos.0", GitCommit:"b8e596026feda7b97f4337b115d1a9a250afa8ac", GitTreeState:"clean", BuildDate:"2017-12-12T11:01:08Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
我不控制平台。我相信由于我们拥有的服务器版本，我仅限于该客户端版本。
更新：
我更改了它以将您指定的属性设置为7200，但它似乎没有任何区别。
然后，我决定改变活体探测器的工作方式。该服务具有自定义SpringBoot运行状况检查，在此之前，如果数据库已完全加载，则仅返回UP。我现在已经更改了它，以便活体探测器使用一个参数来调用运行状况检查，该参数指示它是一个实时检查，因此它可以通过准备检查来告知实时检查。它无条件地返回，但只有在准备就绪时才准备好。不幸的是，这并没有帮助推出。即使我可以看到实时检查返回UP，但显然需要等待服务准备就绪。它在53分钟后超时，就在它准备好之前。
我现在要看一个有点丑陋的妥协，即让环境知道它处于“缓慢”的环境中，即使没有准备就绪，准备就绪检查就绪。我想我们至少会增加一个很大的初始延迟。
我相信你想要的是你的部署中的.spec.progressDeadlineSeconds。如果您看到kubectl describe deployment <deployment-name>的输出，它将具有以下值：Type=Progressing, Status=False. and Reason=ProgressDeadlineExceeded。
您可以将其设置为一个非常大的数字，大于pod /容器所需的数量。即7200秒，即2小时。