Kubernetes readiness Probe exec KO, liveness Probe same exec OK

Question

I have configured a readinessProbe on my pod with a binary execution check, which connects to my running server (in the same container) and retrieves some health information (like ready for traffic).

Configured as a readinessProbe, the binary fails to contact my server and get the required info. It connects on a TCP socket. But it works correctly when I configured it as a livenessProbe.

Configuration. To make it work, I only changed the type from readinessProbe to livenessProbe.

"readinessProbe": {
              "exec": {
                "command": [
                  "/opt/bin/ready_probe",
                  "--check_ready_traffic",
                  "--service=myServer-service"
                ]
              },
              "initialDelaySeconds": 60,
              "timeoutSeconds": 5
            },

The service is for the server, to register it's host and port. This is OK.

Version used: kubernetes v1.1.0-origin-1107-g4c8e6f4

Thank you.

Kubernetes doesn't differentiate between the two kinds of probes. It runs the same exec logic for both of them. What events do you see when the readiness probe fails? — Vishnu Kannan, Mar 02 '16 at 20:13
I thought as well that the exec logic is the same, but how the exec is ran apparently is different from the 2. When the readiness probe fails , I get the expected signal different then 0 - which for me means a loss of communication (which I can see in my logs). There are no other events written by kube — Clau St, Mar 07 '16 at 08:20

score 1 · Answer 1 · answered Feb 01 '19 at 15:08

From the information provided, I can't determine conclusively whether the probe passes or fails in your case. Kubernetes can be kind of opaque if you don't know what to monitor, so it's easy to imagine someone misinterpreting the results of your experiment.

There is no difference in the execution of the two types of probes -- only the consequences differ:

liveness failure: reboots the container, eventually
readiness failure: disables communication

Depending on your container, a liveness failure might be relatively harmless -- you might not even notice it.

However, when you use a readiness probe, communication with your container will be disabled until after the probe passes. This means that the simple act of enabling a readiness proble with initialDelaySeconds: 60 will prevent a service from connecting with your pod for the first minute -- regardless of the state of the associated container. This delay could have cascading consequences if dependent pods/services aren't configured to handle it.

For a liveness probe, it is "very important" to configure initialDelaySeconds (as was done in the question). For a readiness probe, this may not be so important -- and you might prefer it to be zero (the default) in order to allow for the possibility of a faster startup.

Here's the code: https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/prober

Kubernetes readiness Probe exec KO, liveness Probe same exec OK

1 Answers1