Kubernetes 最小就绪秒如何影响就绪探测？

假设我有这样一个部署模板

spec:
  minReadySeconds: 15
  readinessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: 80
      scheme: HTTP
    initialDelaySeconds: 20
    periodSeconds: 20
    successThreshold: 1
    timeoutSeconds: 5

这将如何影响我的应用程序的新版本？

minReadySeconds

和

initialDelaySeconds

是否同时计数？

initialDelaySeconds

是否先出现，然后再出现

minReadySeconds

？

来自Kubernetes：

.spec.minReadySeconds

是一个可选字段，用于指定新创建的Pod在没有任何容器崩溃的情况下准备就绪的最短秒数，以便将其视为可用。该值默认为0（Pod一准备就绪即视为可用）。要了解有关Pod何时视为就绪的更多信息，请参阅

因此，您新创建的应用程序吊舱必须在

.spec.minReadySeconds

秒之前准备就绪，才能视为可用

initialDelaySeconds

：启动活动性或就绪性探测之前容器启动后的秒数

因此，

initialDelaySeconds

在

minReadySeconds

之前

---

比如说，吊舱中的容器在

t

秒时启动。准备就绪探测将在

t+initialDelaySeconds

秒时启动。假设Pod在

t1

秒（

t1>t+initialDelaySeconds

）时准备就绪。因此，该pod将在

t1+minReadySeconds

秒后可用。

因此，在短准备状态下，探测器的

initialDelaySeconds

然后

minReadySeconds

。在这两个之后，我的应用程序就可以运行了traffic@DeanChristianArmada对