“This is the seventh day of my participation in the First Challenge 2022.
【 K8S series 】 K8S learn twenty, ready probe
Speaking of probes, do you remember? We shared the survival probe, how to ensure that the abnormal container automatically restarts to keep the application running properly. If you are interested, you can check the article k8S series K8S learning 17, survival probe copy mechanism 2
Today we are going to share the ready probe alone
Ready probe
There are also three types of ready probes
- The Exec probe
Where the process is executed, the state of the container is determined by the process exit status code
- HTTP GET probe
Send a GET request to the container and determine whether the container is ready by the HTTP status code of the response
- TCP sockets probe
Open a TCP connection to the specified port of the container, and if the connection can be established, the container is considered ready
Looking at the above three types, does it feel similar to the survival probe
So let’s move on to the details of the ready probe, the difference between the viable probe and the ready probe
K8s can be configured with a wait time for both the live probe and the ready probe when the container is started. When the wait time is up, the check operation can be performed
Live probe | Ready probe |
---|---|
When the survival probe examines the container,If the check fails, the POD is restarted immediately | Periodically check the container, If the inspection fails, proveIf the POD is not ready, it will be removed from the service When the checkWhen the POD is ready again, it is added back to the service |
- The survival probe ensures that the POD works by killing abnormal containers and replacing them with new normal containers
- Ready probes confirm that only those PODS that are ready to handle the request will be added to the service
Draw a picture to illustrate the effect:
For a pod that is not ready, the ready probe is still a periodic probe. If the POD is not ready, it will not be killed or restarted. When the POD is detected to be ready, it can still be added to the service
The IP addresses and ports in the endPoints list of the service are deleted and added to the service
How do I add a ready probe to a POD
Remember in what resource did we demonstrate the survival probe example earlier? We demonstrate in RC and RS, because RC/RS can dynamically expand and shrink the number of POD, which is convenient to demonstrate
View rs resource information for our experimental environment
Edit the LIST of RS resources to include in the ready probe
readinessProbe:
exec:
command:
- ls
- /var/xmtready
Copy the code
Delete the current POD
After learning RS and RC, we know that when we modify RS or RC resources, there is no impact on the existing POD, only when a new POD is created, we will use our latest container template to create a POD
Therefore, we can delete the pod first
kubectl delete po --all
When we see the results, each generated POD is not ready. We can view any pod and describe to see the details
Readiness: Exec [ls /var/ XMtready] delay=0s timeout=1s period=10s #success=1 #failure=3. The parameters are consistent with the meanings of the previous survival probe and will not be described here
Pay attention to the error message:
kubelet, minikube Readiness probe failed: ls: cannot access /var/xmtready: No such file or directory
Copy the code
You can see that it failed because the probe was ready and failed to access the /var/xmtready file or directory in pod
This is where the simulated POD needs to process the request properly. The POD is not ready until the preconditions are ready
Manually prepare the readiness conditions
“/var/xmtready” “/var/xmtready” “/var/xmtready” “/var/xmtready” “/var/xmtready
kubectl exec kubia-rs-4kvg2 -- touch /var/xmtready
Copy the code
When kubectl get Po, pod kubiA-RS-4KVg2 is READY to handle external requests. Kubectl get Po: READY is 1/1
How do we use the ready probe in practice?
It should be noted here that, for demonstration purposes, we add or remove pods to the service using the preconditions of adding probes directly
The previous article also shared that we should add or remove pods from the service by using tags
At work, we can add a ready probe to a POD, but it is up to the business implementer to define when it is ready and what state the application has reached to be ready to handle requests from external clients
These are the ready probes shared today, along with a review of the survival probes, hopefully helpful to you
Today is here, learning, if there is a deviation, please correct
Welcome to like, follow and favorites
Friends, your support and encouragement, I insist on sharing, improve the quality of the power
All right, that’s it for this time
Technology is open, our mentality, should be more open. Embrace change, live in the sun, and strive to move forward.
I am Nezha, welcome to like, see you next time ~