minReadySeconds 如何影响就绪探针？

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

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

这将如何影响我的应用程序的新版本？会不会minReadySeconds and initialDelaySeconds同时计数？会不会initialDelaySeconds那么先来minReadySeconds?

来自库伯内特斯部署文档 https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#min-ready-seconds:

.spec.minReadySeconds是一个可选字段，指定新创建的 Pod 在没有任何容器崩溃的情况下应准备就绪的最小秒数，以便将其视为可用。默认为 0（Pod 一旦准备好就被视为可用）。要了解有关 Pod 何时被视为就绪的更多信息，请参阅容器探针 https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

所以你新创建的应用程序 Pod 必须准备好.spec.minReadySeconds被视为可用的秒数。

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

So initialDelaySeconds出现在之前minReadySeconds.

可以说，pod 中的容器已启动于t秒。准备就绪探测将在以下时间启动t+initialDelaySeconds秒。假设 Pod 准备就绪t1秒（t1 > t+initialDelaySeconds）。所以这个 Pod 将在之后可用t1+minReadySeconds秒。