<p>To keep things simple, I think its better to just check the TCP port for liveness and readiness in kubernetes as it doesn't require knowledge of health-check endpoint (HTTP path) but just the port number. Any guide on the disadvantages of just relying on the TCP port for service health-check is greatly appreciated, please assume that the pods are not proxy for some other service and all the business-logic is in the pods itself.</p>
<p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/</a></p>

<p>In my experience HTTP is chosen over TCP when you have a reverse-proxy sidecar in front of your app in the same pod, e.g. nginx. In this case, nginx will always accept TCP even when the app is not ready yet. Thus you'd want HTTP.</p>
<p>Otherwise:</p>
<ul>
<li>if this is an app server listening directly on a port</li>
<li>you know it starts to listen only when fully loaded</li>
<li>you don't want any additional logic inside <code>/health</code> (like check db connection)</li>
</ul>
<p>If all of the above is true - just use TCP.</p>
<p><strong>TIP</strong> You don't even need to know the port number for TCP, you can use named port: <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#use-a-named-port" rel="noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#use-a-named-port</a></p>
