1

TL;DR is the last paragraph, but the rest is here for context if that's not clear enough.

I have a K8s pod running a PHP application. It's split up into an FPM container, and an Nginx container. The liveness and readiness checks are set up to check the container process. So for Nginx, this simply means "is port 443 answering", and for FPM this means "is TCP 9000 answering?".

We already have more intelligent probes ready at /readiness and /liveness endpoints in the PHP application, but where would these fit in?

When the pod was running both Nginx and FPM in a single container it was obvious, because restarting the single container due to a liveness probe failure made sense. For the FPM container, I thought perhaps changing it's probe type from httpGet to command might be the right thing, since you can then run a command that checks the status of the application. Something feels off about that though (mainly that you're no longer checking the main process anymore).

I can probably figure something out where you're checking the service via FPM, but what I want to ask is:

When you have a pod with an FPM container, what is the proper usage of readiness and liveness probes? Should I be asking the application itself whether it feels okay, or should I get all the information to make a decision from FPM?

Afraz
  • 795
  • 1
  • 6
  • 20

1 Answers1

0

You need to ask both FPM and the application. Those probes are not for a pod, they are independently configured for each container. (Although a single container's readiness probe failure will take the whole pod out of traffic, the readiness probe anyway is still for each container)

Daniel
  • 333
  • 1
  • 8