“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 ~