Ensuring application reliability is paramount to providing a satisfactory user experience, as an unreliable application will frustrate both end-users and the development team. Containerizing applications can simplify troubleshooting applications. However, there can be multiple points of failure that will affect the reliability of an application deployed in a Kubernetes cluster. In this post, we will see how to use Kubernetes probes to improve the reliability of an application.
What Are Probes in Kubernetes?
With clusters having multiple resources, even a small component failure can cause the entire application to crash. Kubernetes uses Health Checks to identify if a pod is healthy. It provides probes to carry out these Health checks. The kubelet carries out these probes to determine the health of a container. These checks are done either by executing a code within a container or making a network request. There are four types of mechanisms to carry out these checks.
- exec – Allow users to run a command inside the container and return a status code of 0 if successful.
- gPRC – Users can perform remote procedure calls by configuring gPRC health checks. They will return a response as “serving” if successful.
- httpGet – Sends a simple GET request to an IP and port of a pod. It is considered healthy if the response is between 200 and 400.
- tcpSocket – Perform TCP check against the IP and port of a pod. If the port is open, it is considered a success.
Types of Probes in Kubernetes
There are three types of probes in Kubernetes.
- startupProbe – Checks if an application within a container has started. If the startupProbe is configured, all the other probes will be disabled until it indicates success. The state is considered a success by default when no probe is configured. If the prob efails, Kubernetes will try to redeploy the pods according to the specified restart policy.
- readinessProbe – The Kubernetes readiness probe identifies if a container is able to respond to requests. If this probe fails, the endpoint controller will automatically remove the IP of the Pod from all service endpoints that match the Pods. As with the liveness probe, the default state is indicted as success when a probe is not configured.
- livenessProbe – This Probe checks if an application running on a container is in a healthy state. When Kubernetes detects this probe as unhealthy, it will try to deploy the container according to the configured restart policy. The default state will be considered a success if the container has no liveness probe configured.
When to use these Probes in Kubernetes
All the probes mentioned above are vital for improving the reliability of an application. However, as these probes are not configured automatically, users must ensure they are configured properly to take advantage of this inbuilt health check functionality.
Startup Probe
Let’s begin with startup probes. These probes are ideal for containers that take a long time to startup. The functionality of the startup probe may be similar to the functionality of the liveliness probe, with a long liveness interval. However, the primary difference is that startup probes can accommodate longer time frames than liveliness probes. In most cases, using startup probes in conjunction with other types of probes is the ideal method to detect the health of an application. It prevents the application from prematurely getting reported as unhealthy due to the longer startup.
Liveness Probe
The liveness probe functions to determine if an application is functioning properly. This probe is unnecessary if the containerized application is configured to automatically crash when a problem occurs. In that case, Kubeclt will automatically take the appropriate action according to the Pod restart policy. Specifying a liveness probe can be used to initiate a restart of the pod in any other container. Even if an application is configured to crash when it faces a concern, there will be instances where the container faces an unexpected issue without resulting in a complete crash. In these instances, an aliveness probe can be helpful to determine the actual state of the underlying container.
Readiness Probe
Meanwhile, a Kubernetes readiness probe determines if the container is ready to respond to requests. It allows users to ensure that the Pod only receives traffic if it is able to successfully cater to requests. Both liveness and readiness probes can be pointed to the same health check mechanism. Yet, the readiness probe will start the pod without receiving any traffic and only start receiving traffic after indicating success.
All these types of probes are designed to cater to different health check needs. For most applications, running a liveliness probe alongside a readiness probe will suffice to quickly determine the state of the application and whether it can receive network traffic. However, a startup probe will ensure that no other health checks are performed until the application is fully up and running when dealing with large configurations files or large data sets, which leads to startup delays.
Conclusion
The inbuilt probes allow Kubernetes users to manage the health of their containerized applications without relying on third-party tools or implementing custom functionality to manage the state of Pods. All these things enable users to configure health checks and ensure that Pods are functioning properly by simply including these probes in their manifest files.
Follow Techdee for more!