When developing applications running in a public cloud, containerized environments have different considerations than regular, “bare-metal” monoliths. One of these considerations is optimizing for quick container startup time, which gives the service the ability to scale in response to load quickly, minimizes idle resources, enables faster self-healing, and more. This requirement for quick startup time leads to various questions, such as how to know when a container has completed startup or when it is ready to accept traffic.
Enter Kubernetes probes, of which there are three types: liveness, readiness, and startup. This article focuses on readiness probes, which are tests deployed with your container that will stop forwarding any traffic to the pod on failure. The pod will continue to run and not serve traffic until the readiness probe succeeds.
Before we dive into readiness probes, let’s review the different types of Kubernetes probes for context. Each type of probe has specific use cases, and it’s essential to understand the differences between them to use them effectively.
| Type of Probe | Description | Use Cases |
|---|---|---|
| Liveness | A liveness probe is used to determine if a container is still running. If the probe fails, the container is restarted. |
|
| Readiness | A readiness probe is used to determine if a container is ready to receive traffic. If the probe fails, the container is not sent traffic until it becomes ready again. |
|
| Startup | A startup probe is used to determine if a container has started successfully. If the probe fails, the pod is not created. |
|
Readiness probes are a feature in Kubernetes that allow you to determine if a container is ready to receive traffic. In the event of a failed readiness probe, the kubelet continues running the container that failed the checks and runs more probes; because the check failed, the kubelet sets the Ready condition on the pod to false.
There are two types of readiness probes in Kubernetes:
As mentioned above, you can configure the following options for each probe:
Using these configuration options, you can fine-tune your readiness probes to reflect your containers’ readiness accurately. With the use of readiness probes, you can ensure that traffic is only directed to containers that are fully initialized and ready to handle it.
Watch out for these common issues when using readiness probes:
The following are some typical use cases for Kubernetes readiness probes:
apiVersion: v1
kind: Pod
metadata:
name: web-server-pod
spec:
containers:
- name: web-server
image: nginx:latest
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 3
In this example, the web server is a container running the Nginx web server. The readiness probe periodically sends an HTTP GET request to the “/” endpoint on port 80 and expects a response with a status code in the 200-400 range. The probe waits 5 seconds before starting, runs every 5 seconds, and has a timeout of 1 second. If the probe fails three times in a row, the container is considered not ready.
Comprehensive Kubernetes cost monitoring & optimization
Install in 5 mins or less.
apiVersion: v1
kind: Pod
metadata:
name: database-pod
spec:
containers:
- name: database
image: postgres:latest
readinessProbe:
exec:
command:
- psql
- -U
- postgres
- -c
- 'select 1'
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
In this example, the database is a container running the Postgres database. The readiness probe runs a command using psql to execute a SQL query that selects the value 1. The probe waits 10 seconds before starting, runs every 10 seconds, and has a timeout of 5 seconds. If the probe returns a non-zero exit status three times in a row, the container will be considered not ready.
apiVersion: v1
kind: Pod
metadata:
name: kafka-producer-pod
spec:
containers:
- name: kafka-producer
image: confluentinc/cp-kafka-producer:5.5.0
readinessProbe:
tcpSocket:
port: 9092
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
In this example, the Kafka producer is a container running the Confluent Kafka producer. This readiness probe helps ensure that the Kafka producer only sends messages to the Kafka broker when the broker is available and ready to receive messages.
The readiness probe uses a TCP socket probe to check the availability of the Kafka broker by sending a connection request to port 9092. The probe waits 10 seconds before starting, runs every 10 seconds, and has a timeout of 5 seconds. If the probe fails three times in a row, the container will be considered not ready.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-webserver
spec:
replicas: 3
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: my-webserver-container
image: my-webserver-image:latest
ports:
- containerPort: 80
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 10
periodSeconds: 5
In this example, the web server is made up of three replica pods. The readiness probe periodically sends a TCP check against port 80 of the container every 5 seconds, starting 10 seconds after the container is started. This means that Kubernetes will only direct traffic to the container once it has confirmed that the container is listening on port 80 and ready to handle requests.
FinOps Strategies for Cost Analysis: Understanding and Reducing Your Cloud Bill
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-grpc-service
spec:
replicas: 3
selector:
matchLabels:
app: grpc-service
template:
metadata:
labels:
app: grpc-service
spec:
containers:
- name: my-grpc-container
image: my-grpc-image:latest
ports:
- containerPort: 50051
readinessProbe:
exec:
command:
- /bin/grpc_health_probe
- -addr=:50051
initialDelaySeconds: 10
periodSeconds: 5
In this example, the gRPC readiness probe is configured to perform an exec check using the grpc_health_probe command-line tool, which is commonly used to check the health of gRPC services. The probe is configured to run every 5 seconds, starting 10 seconds after the container is started. This ensures that traffic is only directed to our gRPC microservice when it’s ready to handle it
Prerequisites:
Kubecost Installation 101: Best Practices for a Seamless Setup
This example shows how a readiness probe can fail and how it affects the pod’s availability to receive traffic.
1. Start a local minikube kubernetes cluster:
minikube start
2. Create a basic deployment:
kubectl create deployment my-app --image=nginx
3. Create a readiness probe:
kubectl expose deployment my-app --port=80 --target-port=80
kubectl patch deployment my-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-app","image":"nginx","readinessProbe":{"httpGet":{"path":"/", "port":80}}}]}}}}'`
4. If you prefer to apply from a manifest file, save the following to a file called “readiness-probe.yaml”:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
name: my-app
spec:
containers:
- name: nginx
image: nginx
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 5
5. Then apply it with:
kubectl apply -f readiness-probe.yaml
6. Verify the readiness probe:
kubectl describe pod my-app
It should output the following:
Readiness Probe:
HTTP Get http://10.1.0.43:80/ delay=0s timeout=1s period=10s #success=1 #failure=3
7. Access the app:
minikube service my-app --url
See the output:
http://192.168.39.xx:port
8. See the pod status:
Kubectl get pods
9. Now, let’s edit the readiness probe:
kubectl patch deployment my-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-app","readinessProbe":{"httpGet":{"path":"/", "port":80, "timeoutSeconds":1}}}]}}}}'
10. Let’s also edit the container to make it fail the readiness probe:
kubectl edit deployment my-app
In the YAML file, change the command to sleep for a longer duration than the timeout:
command:
- "sh"
- "-c"
- "sleep 30"
11. Save the changes and close the file.
12. Verify the status of the pod:
kubectl describe pod my-app
The output should show the status of the readiness probe:
Readiness Probe Failed: HTTP probe failed with statuscode: 504
The pod will be in a not-ready state and will not receive traffic until it becomes ready again.
By following these best practices, you can ensure that your readiness probes effectively detect and address issues with your containers.
Use a meaningful endpoint
The endpoint used by the readiness probe should be representative of the overall readiness of the container. For example, more than a simple HTTP GET request to the root endpoint may be needed to determine if the application is fully loaded and ready to handle requests.
Choose appropriate probe parameters
The interval, timeout, and failure threshold should be set appropriately for your use case. You want the interval to be frequent enough to detect failures quickly, the timeout to be long enough for the probe to complete, and the failure threshold to be high enough to tolerate some failures before marking the container as not ready.
Use liveness probes in conjunction with readiness probes
If a container is not responding to a readiness probe, it may indicate that the container is not running or is in a degraded state. In this case, if necessary, you should use a liveness probe to detect and restart the container.
Monitor probe results
Regularly monitor the results of your readiness probes to detect issues early and identify any potential performance bottlenecks.
Avoid overloading containers
Be careful not to overload containers with traffic while they are still initializing. This can cause the readiness probe to fail and may result in the container being marked as not ready.
Test probes in various scenarios
Regularly test your probes in different scenarios and ensure that the readiness probe represents the overall system, not just the individual container.
By now, you should have a clear understanding of the benefits of using readiness probes in Kubernetes. Additionally, you have seen through examples that setting them up is not complicated, even though there are some common gotchas to be aware of. Armed with this knowledge, you can confidently implement readiness probes in your Kubernetes clusters to ensure that your applications are performing optimally and reliably.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。