minReadySeconds 和 Readiness Probe
在 K8s 服务启动的时间顺序很容易混淆。 minReadySeconds 与 Readiness Probe 这里会有些解释：
.spec.minReadySeconds是一个可选的字段，用于指定 Pod 从创建到就绪所需要的最小秒数，这个时间结束之后会被视为 Pod 可用。 默认值是 01；initialDelaySeconds表示容器启用探针之前的秒数。假设 Pod 启动需要t秒，那么在t+initialDelaySeconds之后； 探针开始执行。假设t1秒之后 Pod 就绪(t1>t+initialDelaySeconds)，那么 Pod 会在t1+minReadySeconds之后认为可用；- 也就是说
initialDelaySeconds和健康检测，都是发生在minReadySeconds之前的；
这里面涉及到 3 个层面的事情：
- Deployment 滚动更新
.spec.minReadySeconds是在 Deployment 上配置的，Pod 无感知，在滚动更新时作为 Deployment 认为新 Pod 已经可用，老 Pod 杀掉的一个参考值； Deployment 在获取到 Pod 处于 Ready 状态时，再等待minReadySeconds的时间之后，杀掉老的 Pod - Pod 的状态
Pod 的启动分两个阶段：容器启动、应用启动。
initialDelaySeconds是开始执行健康监测的时间。也就是说 K8s 假定 initialDelaySeconds 是容器启动和应用启动的时间。 如果 Pod 没有设置健康监测，Pod 立即被置为可用。而配置了健康监测之后，健康监测通过才会标记为可用； - 添加到 service 提供服务 只要 Pod 状态为可用，就会添加到 Endpoints 列表中，对外提供服务；
总结：minReadySeconds 不会影响 Pod 的对外提供服务，影响的是滚动更新中哪些 Pod 不提供服务时机（Kill Pod）。
当然上面说的是流程，实际上 K8s 的设计中，不存在 Deployment Kill Pod 这样的操作，Deployment 通过控制 ReplicaSet 中的副本数增减来实现滚动更新 （maxUnavailable 和 maxSurge 两个参数）。