<p>I'm following this task <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes" rel="nofollow noreferrer">Configure Liveness, Readiness and Startup Probes</a> 
and it's unclear to me whether a container where the check is made is a container only used to check the availability of a pod? Because it makes sense if pod check container fails therefore api won't let any traffic in to the pod.</p>

<p>So a health check signal must be coming from container where some image or app runs? (<em>sorry, another question</em>)</p>

<p>Livenes and readiness probes as described by <a href="https://stackoverflow.com/a/58225618/11207414">Ko2r</a> are additional checks inside your containers and verified by <strong>kubelet</strong> according to the settings fro particular probe:</p>

<blockquote>
  <p>If the command (defined by health-check)  succeeds, it returns 0, and the kubelet considers the Container to be alive and healthy. If the command returns a non-zero value, the kubelet kills the Container and restarts it.</p>
</blockquote>

<p>In addition:</p>

<blockquote>
  <p>The kubelet uses liveness probes to know when to restart a Container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a Container in such a state can help to make the application more available despite bugs.</p>
</blockquote>

<p>Fro another point of view:</p>

<p><strong>Pod is a top-level resource in the Kubernetes REST API.</strong> </p>

<p>As per docs:
Pods are ephemeral. They are not designed to run forever, and when a Pod is terminated it cannot be brought back. In general, Pods do not disappear until they are deleted by a user or by a controller.
Information about controllers can find <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pods-and-controllers" rel="nofollow noreferrer">here</a>: </p>

<blockquote>
  <p>So the best practise is to use controllers like describe above. You’ll rarely create individual Pods directly in Kubernetes–even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is evicted for lack of resources, or the Node fails.</p>
</blockquote>

<p>Note:</p>

<blockquote>
  <p>Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted</p>
  
  <p>Because Pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a Pod, the system records the intended grace period before the Pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the Pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.</p>
</blockquote>

<p>The Kubernetes API server validates and configures data for the api objects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact.</p>

<p>For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes–thus making the cluster’s actual state match the desired state.</p>

<p>Here you can find information about <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods" rel="nofollow noreferrer">processing pod termination</a>.</p>

<p>There are different probes:
For example for HTTP probe:</p>

<ul>
<li>even if your app isn’t an HTTP server, you can create a lightweight HTTP server inside your app to respond to the liveness probe. </li>
<li>Command</li>
<li>For command probes, Kubernetes runs a command inside your container. If the command returns with exit code 0 then the container is marked as healthy.</li>
</ul>

<p>More about <a href="https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes" rel="nofollow noreferrer">probes and best practices</a>.</p>

<p>Hope this help.</p>
