<p>Kubernetes readiness (http) probe is failing, however liveness (http) is working fine without readiness.
Using the following, tested with different initialDelaySeconds. </p>

<pre><code>readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 120
  periodSeconds: 10
</code></pre>

<pre><code>livenessProbe: 
  httpGet: 
    path: /healthz 
    port: 8080
  initialDelaySeconds: 120 
  periodSeconds: 10
</code></pre>

Pthota
<p>The <code>readiness</code> and <code>liveness</code> probes serve slightly different purposes:</p>

<ul>
<li><p>the <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes" rel="nofollow noreferrer"><code>readiness</code></a> probe controls whether the pod IP is included in the
list of endpoints for a service, and so also whether a target for a
route when it is exposed via an external URL;</p></li>
<li><p>the <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command" rel="nofollow noreferrer"><code>liveness</code></a> probe determines whether a pod is still running
normally or whether it should be restarted.</p></li>
</ul>

<p>Theoretically situation like you describe could happened if something wrong with exposing of your service for example. Have a look at the best practices <a href="https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes" rel="nofollow noreferrer">here</a>, also you can find some extra information <a href="https://medium.com/@AADota/kubernetes-liveness-and-readiness-probes-difference-1b659c369e17" rel="nofollow noreferrer">here</a>.</p>
