<p>So we have a deployment that is using rolling updates. We need it to pause 180 seconds between each pod it brings up. My understanding is that I need to set <code>MinReadySeconds: 180</code> and to set the <code>RollingUpdateStrategy.MaxUnavailable: 1</code> and <code>RollingUpdateStrategy.MaxSurge: 1</code> for the deployment to wait. With those settings it still brings the pods up as fast as it can. . . What am I missing.</p>
<p>relevant part of my deployment</p>
<pre><code>spec:
    minReadySeconds: 180
    replicas: 9
    revisionHistoryLimit: 20
    selector:
      matchLabels:
        deployment: standard
        name: standard-pod
    strategy:
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 1
      type: RollingUpdate
</code></pre>

<p>Assuming that a pod is ready after a certain delay is not very idiomatic within an orchestrator like Kubernetes, as there may be something that prevents the pod from successfully starting, or maybe delays the start by another few seconds.</p>
<p>Instead, you could use <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">Liveliness and Readiness probes</a> to make sure that the pod is there and ready to serve traffic before taking down the old pod</p>
