Keeping an application healthy and ensuring the high availability of applications running within your cluster starts from the smallest and simplest configurations within the cluster.
The configurations done inside the Kubernetes cluster go a long way to improve the availability of your application and these configurations are in various forms all geared towards ensuring the stability and high availability of pods or applications running within the Kubernetes cluster.
Probes are one of the features in Kubernetes that ensure the health of your application uniquely. Probes are three different types and all three are relevant to keeping your application up and running at the same time.
Have you ever had situations where your pod or application just freezes and becomes unresponsive for a while and you barely know what is wrong, unless you manually go to re-deploy or “restart” the pod, and it comes back up? A probes can help you to do that automatically without the need to manually do that.
Have you also had an application that starts but seems unreachable and it is hard to detect why it is unreachable? Probes can help fix this issue by providing feedback on the current status of the pod to the control manager, which will attempt to ensure the pod reaches its desired state.
So, what are the different types of probes that exist in Kubernetes, and how do they really work?
Types of Probes in Kubernetes
The three major probes that exist in Kubernetes are:
– Livesness Prove
– Readiness Probe
– Startup Probe
Let us explain each of them with real-life scenarios first, then go deeper into their technical explanations.
Explanation with Daily Activities
Think of Kubernetes probes as “check-ins” that a manager (Kubernetes) does with workers (containers) to ensure they’re working properly.
Liveness Probe (Are you still alive?): Imagine you are running a bakery. You regularly check if the baker is still active (not passed out or left the shop). If the baker has fainted, you call for a replacement. Similarly, Kubernetes uses a liveness probe to check if a container is still running. If it fails, the container is restarted.
Readiness Probe (Are you ready to work?): Before opening the bakery doors to customers, you make sure the baker has all the ingredients ready, ovens are preheated, and the shop is clean. If these aren’t done, the bakery remains closed to customers until everything is ready. Kubernetes does the same with a readiness probe—it checks if the container is fully ready to handle traffic and only sends requests once everything is in place.
Startup Probe (Are you ready to start?): When the baker starts a new recipe, you give extra time for them to prepare the dough and preheat the oven before checking their progress. Kubernetes uses a startup probe for containers that take extra time to initialize, ensuring they’re given enough time before health checks begin.
These probes work together like a manager, ensuring the bakery runs smoothly for customers, keeping things functional and responsive!
Now, let us go technical to see how they are defined in Kubernetes terms
Technical Description of Probes with Examples
What is Liveness Probe
Liveness Probe is a feature in Kubernetes that ensures that a pod is running as expected. As the name implies, it “probes”. It continues to check to see if the application is running as it should. This can be helpful for applications that can get stuck or frozen, the liveness probe can detect this and restart
The user defines what it means for an application to be running by setting that in the Liveness probe configuration.
Liveness Probe can be configured to check if an HTTP request returns 200, check if a service is available to connect to, or check if a TCP socket is open, as its means of validating that an application is running as it should. The most common of these is the HTTP option, which is most used for APIs.
If, for any reason, Kubernetes does not get a positive response, it will term the pod as not running and force it to restart by killing the pod and allowing the control manager to set up a new pod. As long as the probe continues to fail, it will continue in this cycle until it is resolved appropriately.
apiVersion: apps/v1 kind: Deployment metadata: name: liveness-example spec: replicas: 1 selector: matchLabels: app: liveness-app template: metadata: labels: app: liveness-app spec: containers: - name: app-container image: your-app-image livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10
httpGet: Kubernetes will send an HTTP GET request to /health on port 8080.
initialDelaySeconds: Delay before starting probes after the container starts.
periodSeconds: How often to perform the probe.
The next is the Readiness Probe
What is Readiness Probe
Readiness Probe is a feature in Kubernetes that ensures that an a pod is running as expected. As the name implies if “probes”. It does continues checks to see if the application is ready to receive traffic. If the application is not ready to receive traffic, it is removed from the service until it is ready to receive traffic. The user defines what it means for an application to be running by setting that in the readiness probe configuration.
Readiness probe can be configured to check if an HTTP request returns 200, check if a service is available to connect to, or check if a TCP socket is open, as it means of validating that an application is running as it should. The most common of these is the HTTP option, which is most used for APIs.
apiVersion: apps/v1 kind: Deployment metadata: name: readiness-example spec: replicas: 1 selector: matchLabels: app: readiness-app template: metadata: labels: app: readiness-app spec: containers: - name: app-container image: your-app-image readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10
/ready: The endpoint that confirms the app is ready to serve traffic.
Next is the Startup Probe
What is Startup Probe
Startup Probe is a feature in Kubernetes that ensures that a pod is running as expected. As the name implies, it “probes”. It confirms that the application has started. The user defines what it means for an application to be running by setting that in the startup probe configuration.
Startup probe can be configured to check if an HTTP request returns 200, check if a service is available to connect to, or check if a TCP socket is open, as it means of validating that an application is running as it should. The most common of these is the HTTP option, which is most used for APIs.
apiVersion: apps/v1 kind: Deployment metadata: name: startup-example spec: replicas: 1 selector: matchLabels: app: startup-app template: metadata: labels: app: startup-app spec: containers: - name: app-container image: your-app-image startupProbe: httpGet: path: /startup port: 8080 failureThreshold: 30 periodSeconds: 10
failureThreshold: Number of times the probe can fail before Kubernetes gives up and restarts the container.
/startup: Startup probe endpoint that ensures the app has fully started.
Conclusion
Configuring probes in your Kubernetes application should be a compulsory feature and non-negotiable. The application also needs to give the appropriate response to ensure the Kubernetes probes work effectively.
For probes to work, it is a collaborative effort between the DevOps Engineer and the application developer.
For HTTP probes, it is important that the application returns an HTTP 200 status code and the path for the health check is defined and shared with the DevOps Engineer for configuration.
