Search for a command to run...
Monitoring Container Health with Kubernetes Liveness Probes: A Guide with Examples
Yusuf Adeyemo is a DevOps Engineer from Nigeria. He loves helping startups deliver better software and provide more control over their environment and software development process with the help of modern tools and automation.
No comments yet. Be the first to comment.
We’ve all been there. You spend hours perfectly tuning your OpenWrt configuration, setting up your captive portals, and hardening your firewall. Then, six months later, the system hangs. Why? Because
This article started from a tweet. Someone on Twitter said they "lowkey want to understand the technology behind Google Authenticator" and I dropped a quick reply - explaining that it's basically TOTP: your device and the server share a secret key, b...
Have you ever sat there waiting for your CodeBuild project to rebuild your entire Docker image... again? Even though you only changed a single line of code? Yeah, me too. And it's frustrating. Today, I'm going to show you how I reduced our Docker bui...
After you complete this article, you will have a solid understanding of: Why deploying Next.js SSR on Cloudflare is different from traditional hosting The real difference between Cloudflare Pages with next-on-pages and OpenNext adapter How the fre...
After you complete this article, you will have a solid understanding of: What L1, L2, and L3 constructs actually are and when to use each Why AWS created three different abstraction levels (and the hidden benefits) How to avoid the most common CDK...
Kubernetes is a highly effective and widely-used platform for container orchestration. One of the key features of Kubernetes is the ability to monitor the health of applications running in containers. Observability in Kubernetes refers to the ability to monitor and diagnose the behavior of a deployed application.
In this article, we will focus on one aspect of observability in Kubernetes – Liveness Probes. Liveness probes are used to check if an application is running correctly. They are an important tool for making sure that applications running in containers are reliable and always available.
Liveness Probes are a type of Kubernetes mechanism that allows you to monitor the health of a container running in a pod. The purpose of Liveness Probes is to detect when a container is no longer running as expected, and if necessary, restart it. This helps to ensure that the containers in a pod are always running and can respond to requests.
Liveness Probes are defined in a pod specification as a JSON or YAML file, and can be specified as either a HTTP request, a TCP socket connection, or a command executed inside the container. The Kubernetes control plane periodically performs the specified Liveness Probe, and if it fails, the control plane will restart the container.
Liveness Probes work by sending requests to a container running in a pod to check its health status. The request can be either an HTTP request, a TCP socket connection, or a command executed inside the container. If the container is healthy, it will return a success status code. If the container is not healthy, it will return a failure status code, and the Kubernetes control plane will restart the container.
There are several types of liveness probes that can be used, including:
HTTP requests
TCP connections
Command execution
Each type of probe has its own use case, and can be defined in the pod definition file.
HTTP requests are the most common type of liveness probe. They can be used to check if an application is responding to requests, and to ensure that the application is accessible.
To define an HTTP liveness probe in a pod definition file, you would add the following code:
livenessProbe:
httpGet:
path: /ping
port: 3000
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
In this example, the liveness probe will send an HTTP GET request to /ping on port 3000. The probe will be initiated after a delay of 5 seconds, and will time out after 1 second. The probe will run every 10 seconds and will be considered successful if it returns a response. If the probe fails 3 times in a row, the container will be restarted.
TCP connections can be used to check if an application is listening on a specific port. They can be used to check if an application is running and to make sure the application can be reached.
To define a TCP liveness probe in a pod definition file, you would add the following code:
livenessProbe:
tcpSocket:
port: 3000
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
In this example, the liveness probe will attempt to establish a TCP connection on port 3000. The probe will be initiated after a delay of 5 seconds, and will time out after 1 second. The probe will run every 10 seconds and will be considered successful if it is able to establish a connection. If the probe fails 3 times in a row, the container will be restarted.
Command execution can be used to check if an application is running properly by executing a command within the container. This is useful for checking the status of an application, and can be used to ensure that the application is running correctly.
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
In this example, the liveness probe executes the command cat /tmp/healthy in the target container. If the command succeeds, it returns 0, and the probes consider the container to be alive and healthy. If the command returns a non-zero value, it kills the container and restarts it.
Liveness probes are a key component of observability in Kubernetes, providing a mechanism to monitor the health of containers and ensure they are running as expected. By using Liveness Probes, you can make your Kubernetes cluster applications more reliable and available. Whether you choose to use HTTP Liveness Probes, TCP Socket Connection Liveness Probes, or Command Execution Liveness Probes, you can rest assured that your containers are being monitored and will be restarted if necessary to ensure they are always running and available to respond to requests.