<p>I would like to know if there is a possibility to apply liveness and readiness probe check to multiples containers in a pod or just for one container in a pod.
I did try checking with multiple containers but the probe check fails for container A and passes for container B in a pod.</p>

<p>Welcome to the community.</p>
<p><strong>Answer</strong></p>
<p>It's absolutely possible to apply multiple probes for containers within the pod. What happens next depends on a probe.</p>
<p>There are three probes listed in <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes" rel="noreferrer">Containers probes</a> which can be used: <code>liveness</code>, <code>readiness</code> and <code>startup</code>. I'll describe more about <code>liveness</code> and <code>readiness</code>:</p>
<p><strong>Liveness</strong></p>
<blockquote>
<p><code>livenessProbe</code>: Indicates whether the container is running. If the
<code>liveness</code> probe fails, the kubelet kills the container, and the
container is subjected to its restart policy. If a Container does not
provide a <code>liveness</code> probe, the default state is Success</p>
</blockquote>
<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>In case of <code>livenessProbe</code> fails, <code>kubelet</code> will restart the container in POD, the POD will remain the same (its age as well).</p>
<p>Also it can be checked in <code>container events</code>, this quote is from <code>Kubernetes in Action - Marko Lukša</code></p>
<blockquote>
<p>I’ve seen this on many occasions and users were confused why their
container was being restarted. But if they’d used <code>kubectl describe</code>,
they’d have seen that the container terminated with exit code 137 or
143, telling them that the pod was terminated externally</p>
</blockquote>
<p><strong>Readiness</strong></p>
<blockquote>
<p><code>readinessProbe</code>: Indicates whether the container is ready to respond to
requests. If the <code>readiness</code> probe fails, the endpoints controller
removes the Pod's IP address from the endpoints of all Services that
match the Pod. The default state of <code>readiness</code> before the initial delay
is Failure. If a Container does not provide a <code>readiness</code> probe, the
default state is Success</p>
</blockquote>
<blockquote>
<p>The kubelet uses readiness probes to know when a container is ready to
start accepting traffic. A Pod is considered ready when all of its
containers are ready. One use of this signal is to control which Pods
are used as backends for Services. When a Pod is not ready, it is
removed from Service load balancers.</p>
</blockquote>
<p>What happens here is kubernetes checks if webserver in container is serving requests and if not, <code>readinessProbe</code> fails and POD's IP (generally speaking entire POD) will be removed from endpoints and no traffic will be directed to the POD.</p>
<p><strong>Useful links</strong></p>
<ul>
<li><a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes" rel="noreferrer">Container probes</a> - general information and <code>types</code></li>
<li><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="noreferrer">Configure Liveness, Readiness and Startup Probes</a> (practice and examples)</li>
</ul>
