liveness and readiness probe for multiple containers in a pod

Question

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.

"

Answer 1

Welcome to the community.

What happens next depends on a probe.

I'll describe more about liveness<\/code> and readiness<\/code> :

If the 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 liveness<\/code> probe, the default state is Success

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.

But if they'd used 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

If the 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 readiness<\/code> before the initial delay is Failure. If a Container does not provide a readiness<\/code> probe, the default state is Success

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.

• <\/li>
• <\/li><\/ul>"

Answer 2

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

Answer 3

Yes it is possible, I have tried this. Here's what I tried.

• One deployment with 2 replica.
• Each replica pod with 4 containers.
• Each container with it's own liveness probe.
• Liveness probe used http-get to check container application health.

Few things to take care:

• Since <PODIP>:<CONTAINERPORT>/<ENDPOINT> is used by liveness probe to make http request, one must make sure <CONTAINERPORT> is different for each container. Else the pod will go to CrashLoopBack .

Example:

containers:
       - name: container1
...
        args:
        - --leader-election=true
        - --http-endpoint=:8080
...
        ports:
        - containerPort: 8080
          name: http-endpoint
          protocol: TCP
...
        livenessProbe:
          failureThreshold: 1
          httpGet:
            path: /healthz/leader-election
            port: http-endpoint
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 10
...
       - name: container2
...
        args:
        - --leader-election=true
        - --http-endpoint=:8081
...
        ports:
        - containerPort: 8081
          name: http-endpoint
          protocol: TCP
...
        livenessProbe:
          failureThreshold: 1
          httpGet:
            path: /healthz/leader-election
            port: http-endpoint
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 10
...

Suggestion:

If each container is a separate application and do no depend on each other and is important enough that you need a liveness probe for it then, it should be better to deploy them in separate pods.