liveness and readiness probe for multiple containers in a pod

Welcome to the community.

Answer

It's absolutely possible to apply multiple probes for containers within the pod. What happens next depends on a probe.

There are three probes listed in Containers probes which can be used: liveness, readiness and startup. I'll describe more about liveness and readiness:

Liveness

livenessProbe: Indicates whether the container is running. If theliveness probe fails, the kubelet kills the container, and thecontainer is subjected to its restart policy. If a Container does notprovide a liveness probe, the default state is Success

The kubelet uses liveness probes to know when to restart a container.For example, liveness probes could catch a deadlock, where anapplication is running, but unable to make progress. Restarting acontainer in such a state can help to make the application moreavailable despite bugs.

In case of livenessProbe fails, kubelet will restart the container in POD, the POD will remain the same (its age as well).

Also it can be checked in container events, this quote is from Kubernetes in Action - Marko Lukša

I’ve seen this on many occasions and users were confused why theircontainer was being restarted. But if they’d used kubectl describe,they’d have seen that the container terminated with exit code 137 or143, telling them that the pod was terminated externally

Readiness

readinessProbe: Indicates whether the container is ready to respond torequests. If the readiness probe fails, the endpoints controllerremoves the Pod's IP address from the endpoints of all Services thatmatch the Pod. The default state of readiness before the initial delayis Failure. If a Container does not provide a readiness probe, thedefault state is Success

The kubelet uses readiness probes to know when a container is ready tostart accepting traffic. A Pod is considered ready when all of itscontainers are ready. One use of this signal is to control which Podsare used as backends for Services. When a Pod is not ready, it isremoved from Service load balancers.

What happens here is kubernetes checks if webserver in container is serving requests and if not, readinessProbe fails and POD's IP (generally speaking entire POD) will be removed from endpoints and no traffic will be directed to the POD.

Useful links

• Container probes - general information and types
• Configure Liveness, Readiness and Startup Probes (practice and examples)

As per K8S spec, liveness and readiness check can be executed for every container and carries its own template, which is nested into the specific container. See for example : https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/probe/exec-liveness.yaml .

So I think it really depends on what are you checking for in the probe and how container A could answer in a different fashion than container B.

If you have a need for templating, you should look into kustomize