|If you need to use a complex command as a readiness or liveness probe, you are better off having a script which is part of the container image and running that, having all knowledge of what to do inside of the script.|
This has the benefit that the details of the probe can be a part of the Git repository used as the source for building the image and it can be kept in sync with what the applications requires for the probe.
The danger of putting a more complex command in the deployment config resource is that you ship an updated image which needs to do it differently and you forget to update the deployment config at the same time. So better to have in the image a script and keep the name the same all the time. Then can readily update the script in new versions of the image and don't have to change the deployment config.
Also, by being in the image you can avoid using 127.0.0.1, which doesn't actually test the external accessibility of the application properly. You should instead use $HOSTNAME instead of 127.0.0.1. That way you are using the pod name and the internal OpenShift DNS will be looked up to get the pod IP and so you connect via it. This ensures it is visible outside, where as using 127.0.0.1 will not catch where application incorrectly listened on only the loopback interface.
One warning about using a command script for a probe which I think still applies, although was a while back I last looked.
Because of a limitation in Docker service, it is not possible to interrupt a command used as a probe. This means that even though a timeout is specified for the probe, it doesn't work properly. If the probe were actually to hang, then it wouldn't be detected properly. The probe also wouldn't be retried properly.
I need to go back and retest to see what the current situation is.
Was from before I learnt about the problems with the timeout I think, but perhaps watch:
I got most of the details correct in it I think.