minReadySeconds 如何影响就绪探测？答案

【问题标题】：How does minReadySeconds affect readiness probe?minReadySeconds 如何影响就绪探测？
【发布时间】：2019-04-13 19:28:41
【问题描述】：

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

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 google-kubernetes-engine

【解决方案1】：

来自 Kubernetes Deployment documentation：

.spec.minReadySeconds 是一个可选字段，它指定新创建的 Pod 应该准备好且其任何容器不崩溃的最小秒数，以使其被视为可用。这默认为 0（Pod 准备就绪后将被视为可用）。要了解有关何时认为 Pod 已准备就绪的更多信息，请参阅 Container Probes

因此，您新创建的应用程序 pod 必须准备好 .spec.minReadySeconds 秒才能被视为可用。

initialDelaySeconds: 容器启动后的活跃度或就绪性探测启动前的秒数。

所以initialDelaySeconds 在minReadySeconds 之前。

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

【讨论】：

所以简而言之，Readiness 探针的initialDelaySeconds 然后minReadySecoonds。在这两个之后，我的应用会为流量提供服务
@DeanChristianArmada 是的。