<p>I have configured a readinessProbe on my pod with a binary execution check, which connects to my running server (in the same container) and retrieves some health information (like ready for traffic).</p>

<p>Configured as a readinessProbe, the binary fails to contact my server and get the required info. It connects on a TCP socket.
But it works correctly when I configured it as a livenessProbe.</p>

<p>Configuration. To make it work, I only changed the type from readinessProbe to livenessProbe.</p>

<pre><code>"readinessProbe": {
              "exec": {
                "command": [
                  "/opt/bin/ready_probe",
                  "--check_ready_traffic",
                  "--service=myServer-service"
                ]
              },
              "initialDelaySeconds": 60,
              "timeoutSeconds": 5
            },
</code></pre>

<p>The service is for the server, to register it's host and port. This is OK.</p>

<p>Version used: kubernetes v1.1.0-origin-1107-g4c8e6f4</p>

<p>Thank you.</p>

<p><em>From the information provided, I can't determine conclusively whether the probe passes or fails in your case.  Kubernetes can be kind of opaque if you don't know what to monitor, so it's easy to imagine someone misinterpreting the results of your experiment.</em></p>

<p>There is no difference in the execution of the two types of probes -- only the consequences differ:</p>

<ul>
<li>liveness failure: reboots the container, <a href="https://stackoverflow.com/a/36846812">eventually</a></li>
<li>readiness failure: disables communication</li>
</ul>

<p>Depending on your container, a liveness failure might be relatively harmless -- you might not even notice it.</p>

<p>However, when you use a readiness probe, communication with your container will be disabled until <em>after</em> the probe passes.  This means that the simple act of enabling a readiness proble with <code>initialDelaySeconds: 60</code> will prevent a service from connecting with your pod for the first minute -- regardless of the state of the associated container.  This delay could have cascading consequences if dependent pods/services aren't configured to handle it.</p>

<p>For a liveness probe, it is <a href="https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes" rel="nofollow noreferrer">"very important"</a> to configure <code>initialDelaySeconds</code> (as was done in the question).  For a readiness probe, this may not be so important -- and you might prefer it to be zero (<a href="https://stackoverflow.com/q/48572691">the default</a>) in order to allow for the possibility of a faster startup.</p>

<hr>

<p>Here's the code: <a href="https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/prober" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/prober</a></p>
