How To Use Liveness Probes In Kubernetes

Somebody asked me:

We’re spinning up a service that is going to be using an external system as a data source. If that data source is not available, the service can’t do it’s job. Does it make sense to use a livenessProbe/readinessProbe to ensure that there’s basic connectivity to the external service before taking traffic?

For some additional context, the external system is an API, not a database.

Readiness probes determine if your pod is ready to accept traffic.

Liveness probes determine whether your pod is still alive. If it’s not alive, Kubernetes will kill the pod and restart it according to its restartPolicy.

Using a livenessProbe that checks the availability of the external data source might not always be appropriate. If the external service is temporarily unavailable, you probably don’t want to restart your service; instead, you might want it to wait and retry until the external service becomes available again.

As a general rule of thumb, if restarting the container won’t resolve the issue, then your livenessProbe shouldn’t consider the data source.

However, if your service enters a failed state (such as a crash loop or deadlock) when it cannot access the external data source, or if losing connection to the external service causes your application to freeze or crash, a livenessProbe could be beneficial. It can detect such states and restart your service automatically.


Master GitHub Actions with a Senior Infrastructure Engineer

As a senior staff infrastructure engineer, I share exclusive, behind-the-scenes insights that you won't find anywhere else. Get the strategies and techniques I've used to save companies $500k in CI costs and transform teams with GitOps best practices—delivered straight to your inbox.

Not sure yet? Check out the archive.

Unsubscribe at any time.