<p>Consider a pod which has a healthcheck setup via a http endpoint <code>/health</code> at port 80 and it takes almost 60 seconds to be actually ready &amp; serve the traffic.</p>

<pre><code>readinessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 60
livenessProbe:
  httpGet:
    path: /health
    port: 80
</code></pre>

<p><strong>Questions:</strong></p>

<ul>
<li>Is my above config correct for the given requirement? </li>
<li>Does liveness probe start working only after the pod becomes ready ? In other words, I assume readiness probe job is complete once the POD is ready. After that livenessProbe takes care of health check. In this case, I can ignore the <code>initialDelaySeconds</code> for livenessProbe.  If they are independent, what is the point of doing livenessProbe check when the pod itself is not ready! ?</li>
<li>Check this <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/" rel="noreferrer">documentation</a>. What do they mean by </li>
</ul>

<blockquote>
  <p>If you want your Container to be able to take itself down for
  maintenance, you can specify a readiness probe that checks an endpoint
  specific to readiness that is different from the liveness probe.</p>
</blockquote>

<p>I was assuming, the running pod will take itself down only if the livenessProbe fails. not the readinessProbe. The doc says other way. </p>

<p>Clarify!</p>

KitKarson
<p>I'm starting from the <strong>second problem</strong> to answer. The second question is:</p>

<blockquote>
  <p>Does <strong>liveness probe</strong> start working only after the pod becomes ready?
  In other words, I assume readiness probe job is complete once the POD
  is ready. After that livenessProbe takes care of health check.</p>
</blockquote>

<p>Our initial understanding is that liveness probe will start to check after readiness probe was succeeded but <strong>it turn out not to be like that</strong>. It has opened an issue for this challenge.Yon can look up to <a href="https://github.com/kubernetes/kubernetes/issues/27114" rel="noreferrer">here</a>. Then It was solved this problem by adding <a href="https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190221-livenessprobe-holdoff.md" rel="noreferrer"><strong>startup probes.</strong></a></p>

<p>To sum up:</p>

<blockquote>
  <ul>
  <li><strong>livenessProbe</strong></li>
  </ul>
</blockquote>

<p><strong>livenessProbe:</strong> Indicates whether the Container is running. If the
   liveness probe fails, the kubelet kills the Container, and the
   Container is subjected to its restart policy. If a Container does not
   provide a liveness probe, <code>the default state is Success.</code></p>

<blockquote>
  <ul>
  <li><strong>readinessProbe</strong></li>
  </ul>
</blockquote>

<p><strong>readinessProbe:</strong> Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, <code>the default state is Success.</code></p>

<blockquote>
  <ul>
  <li><strong>startupProbe</strong></li>
  </ul>
</blockquote>

<p><strong>startupProbe</strong>: Indicates whether the application within the Container is started. <strong>All other probes are disabled if a startup probe is provided, until it succeeds.</strong> If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, <code>the default state is Success</code></p>

<p>look up <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/" rel="noreferrer">here</a>.</p>
