我需要了解哪些限制会导致kubectl卷展栏超时并显示“直到超时前关闭手表”。
我正在推出一项服务，该服务需要在启动时加载数据库。我们正在一个不幸的是与数据库服务器相对连接较慢的节点上运行此服务。 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。现在，我对其进行了更改，以便活动性探针使用指示其为活动检查的参数来调用运行状况检查，以便可以从就绪检查中区分活动检查。它无条件返回活动状态，但只有在准备就绪时才准备就绪。不幸的是，这无助于推广。即使我可以看到实时检查正在恢复正常运行，它显然也需要等待服务准备就绪。它在53分钟后超时，早于准备就绪。
我现在要看一个有点丑陋的折衷方案，即让环境知道它处于“缓慢”的环境中，并准备好返回准备就绪状态，即使尚未准备就绪。我想我们至少会为此添加一个较大的初始延迟。
答案 0 :(得分：1)
我相信您想要的是.spec.progressDeadlineSeconds。如果看到kubectl describe deployment <deployment-name>的输出，它将具有以下值：Type=Progressing, Status=False. and Reason=ProgressDeadlineExceeded。
您可以将其设置为一个非常大的数字，它大于容器/容器要拿出的数字。即7200秒，即2个小时。