<p>After deploying your pods, how one can identify that all the pods are up and running? I have listed down few options which I think could be correct but wanted to understand what is the standard way to identify the successful deployment.</p>
<ol>
<li>Connect to application via its interface and use it to identify if all the pods (cluster) are up (maybe good for stateful applications). For stateless applications pod is up should be enough.</li>
<li>Expose a Restful API service which monitors the deployment and responds accordingly.</li>
<li>Use <code>Kubectl</code> to connect to pods and get the status of pods and containers running.</li>
</ol>
<p>I think number 1 is the right way but wanted to understand community view on it.</p>

Manish Khandelwal
<p>All your approaches sounds reasonable and will do the job, but why not just use the tools that Kubernetes is giving us exactly for this purpose ? ;)</p>
<p>There are two main health check used by Kubernetes:</p>
<ul>
<li><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command" rel="nofollow noreferrer">Liveness probe</a>- to know if container is running and working without issues (not hanged, not in deadlock state)</li>
<li><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes" rel="nofollow noreferrer">Readiness probe</a> - to know if container is able to accept more requests</li>
</ul>
<p>Worth to note there is also &quot;<a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes" rel="nofollow noreferrer">Startup probe</a>&quot; which is responsible for protecting slow starting containers with difficult to estimate start time.</p>
<p><strong>Liveness:</strong></p>
<p>As mentioned earlier, main goal of the liveness probe is to ensure that container is not dead. If it is dead, Kubernetes removes the Pod and start a new one.</p>
<p><strong>Readiness:</strong></p>
<p>The main goal of the readiness probe is to check if container is able to handle additional traffic. In some case, the container may be working but it can't accept a traffic. You are defining readiness probes the same as the liveness probes, but the goal of this probe it to check if application is able to answer several queries in a row within a reasonable time. If not, Kubernetes stop sending traffic to the pod until it passes readiness probe.</p>
<p><strong>Implementation:</strong></p>
<p>You have a few ways to implement probes:</p>
<ul>
<li>run a command every specified period of time and check if it was done correctly - the return code is 0 (in <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command" rel="nofollow noreferrer">this example</a>, the command <code>cat /tmp/healthy</code> is running every few seconds).</li>
<li>send a HTTP GET request to the container every specified period of time and check if it returns a success code (in <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request" rel="nofollow noreferrer">this example</a>, Kubernetes is sending a HTTP request to the endpoint <code>/healthz</code> defined in container).</li>
<li>attempt to open a TCP socket in the container every specified period of time and make sure that connection is established (in <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe" rel="nofollow noreferrer">this example</a>,  Kubernetes is connecting to container on port 8080).</li>
</ul>
<p>For both probes you can define few arguments:</p>
<blockquote>
<ul>
<li><code>initialDelaySeconds</code>: Number of seconds after the container has started before liveness or readiness probes are initiated. Defaults to 0 seconds. Minimum value is 0.</li>
<li><code>periodSeconds</code>: How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1.</li>
<li><code>timeoutSeconds</code>: Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1.</li>
<li><code>successThreshold</code>: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup Probes. Minimum value is 1.</li>
<li><code>failureThreshold</code>: When a probe fails, Kubernetes will try  <code>failureThreshold</code>  times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1.</li>
</ul>
</blockquote>
<p>Combining these two health checks will make sure that the application has been deployed and is working correctly - liveness probe for ensuring that pod is restarted when it container in it stopped working and readiness probe for ensuring that traffic does not reach pod with not-ready or overloaded container. The proper functioning of the probes requires an appropriate selection of the implementation method and definition of arguments - most often by trial and error. Check out these documentation:</p>
<ul>
<li><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">Configure Liveness, Readiness and Startup Probes - Kubernetes documentation</a></li>
<li><a href="https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes" rel="nofollow noreferrer">Kubernetes best practices: Setting up health checks with readiness and liveness probes - Google Cloud</a></li>
</ul>
