CODEWITHSUNDEEP
kubernetesprobe
Clau St
Clau St

Reputation: 1048

Kubernetes readiness Probe exec KO, liveness Probe same exec OK

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.

Upvotes: 1

Views: 4168

Answers (1)

Brent Bradburn
Brent Bradburn

Reputation: 54979

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

Upvotes: 1

Related Questions