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.

Join the 80/20 DevOps Newsletter

If you're an engineering leader or developer, you should subscribe to my 80/20 DevOps Newsletter. Give me 1 minute of your day, and I'll teach you essential DevOps skills. I cover topics like Kubernetes, AWS, Infrastructure as Code, and more.

Not sure yet? Check out the archive.

Unsubscribe at any time.