A Kubernetes cluster is a highly dynamic environment: pods get created, replaced, updated and removed all the time.
Have you ever wondered how, in all the chaos, Kubernetes manages to only send traffic to healthy, running pods? Or do you want to learn how to gain more control over the lifecycle of your pods and containers? Read on to find out.
First thing's first: what is a probe?
A probe is a diagnostic (or healthcheck) that is periodically performed by the kubelet, the primary agent that runs on your Kubernetes node. This is, amongst other things, responsible for ensuring that pods run smoothly and efficiently.
There are several types of probes that can be used, and each type offers specific customization options.
The specific goal of the probe depends on its type, and how it is set up. In general, however, it will be used to monitor the status of the pod and its containers.
The result of the probe can be successful, failed or unknown (if something went wrong with the probe itself).
In the next section, we’ll have a look at the different types of probes, and what they do.
Types of probes you can use in Kubernetes
Kubernetes offers 3 types of probes you can use in your pod specs:
- Liveness probes: these probes tell the kubelet whether the container is still healthy and if it should be restarted.
- Readiness probes: probes that tell the kubelet whether the container is capable and ready to receive traffic and respond to requests.
- Startup probes: this subtype signifies whether the application inside the container has successfully started up.
You can combine these probe types within your pod specification (for example: set up a liveness probe and a readiness probe, or all three types at once).
We’ll go into the details of each of these probes, but first let’s have a look at how these probes perform their diagnostic check.
How the probes are configured and executed
Each of the probes has 4 mechanisms at its disposal to execute the configured diagnostic:
- Exec: executes a shell command inside the container that is being probed. It is considered successful if the returned status code is 0.
- httpGet: performs an HTTP GET on a specified endpoint and port. Response codes between 200 OK (inclusive) and 400 Bad Request (exclusive) are considered a success.
- grpc: performs a procedure call using gRPC. If the status of the response is Serving, the probe is considered successful.
- tcpSocket: does a TCP check on a specified port. It is successful if the port is open during the check.
As we will see in a bit, each type of probe has specific properties that you can set, but there are also some general properties that apply to all types of probes. The Kubernetes documentation has the full list, but we have selected the key wants you should be familiar with when using probes:
- periodSeconds: the interval of the probe, i.e. how often it should be executed.
- initialDelaySeconds: how many seconds the probe should wait after the startup of the container to run its first execution. As we will see later on, this can be useful for containers that are slow to start up.
- failureTreshold: the number of times a probe execution should fail, before the overall probe should be considered as failed. This is great for when you want to filter out jittery results, or don’t want a short transient error to fail your probe.
You now have a general idea of what a Kubernetes probe does, and how it works. Let’s make things more tangible and have a look at the specific probe types.
Liveness probes
The result of a liveness probe indicates whether the container is running correctly. If the probe fails, the kubelet kills the container, and the container is subjected to its restartPolicy (which can be Always (default), Never or OnFailure).
A liveness probe is useful whenever you have an application that might, during its lifetime, transition into a broken/faulty state, which can be solved by restarting the container.
Below is an example of a liveness probe using a httpGet (but keep in mind it can use all 4 mechanisms: exec, httpGet, grpc, tcpSocket):
Readiness probes
A readiness probe indicates whether the container is ready to receive traffic and respond to requests. If the probe fails, no new traffic will be sent to the pod.
Readiness probes are useful if you want to avoid new traffic to the container if it’s not ready. Take note that, if this probe fails, it doesn’t restart the container. This makes this probe ideal if you want to ensure that external dependencies are up and running before accepting traffic to the container.
A readiness probe is nearly identical to a liveness probe in its definition. Below is an example of a readiness probe using an exec:
Startup probes
A startup probe signifies whether the application inside the container has successfully started up. This probe is a bit special, because it disables the execution of other probes, as long as the startup probe has not succeeded.
This probe’s main use is to protect containers that have a slow startup from the liveness and readiness probes: if you had defined a liveness probe that started probing your container before it had time to start up, it would have been killed prematurely by the kubelet.
By combining a startup and liveness probe, you can give your container time to start up and waste no needless extra time. Just in case you were thinking you could just increase the initialDelaySeconds property of your liveness probe 😉.
Again, a startup probe is nearly identical to liveness and readiness probes. Below is an example of a startup probe using the tcpSocket mechanism:
Conclusion
In this blog post, we learned:
- What a Kubernetes probe is, and what mechanisms it can use to perform its diagnostic
- The 3 types of probes Kubernetes offers
- What use case is the best fit for each of the probe types
- Some practical examples of how you can set up the probes
We hope you enjoyed this article, and that it has helped you to gain insights into Kubernetes probes. If you still have any questions, feel free to get in touch with us, and consider subscribing to our RSS feed so you don’t miss out on future articles.
Click on the link below to subscribe 👇
Subscribe to our RSS feed
Talk to the author
Contact Dries
Consultant