Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to master the container probe of SpringBoot-2.3. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Official information on probe characteristics

As shown in the red box below, version 2.3 of the container probe feature has been released as early as the preview version (v2.3.0.M4):

Now that v2.3.0.RELEASE has been released, you can rest assured to learn and use this feature. First of all, list the basic knowledge points to ensure that the preparation work OK

Arrangement of knowledge points

The following is the basic knowledge needed to master the probe technology, which is also the main content of this article:

Survival probe livenessProbe of kubernetes

Ready probe readinessProbe for kubernetes

Actuator of SpringBoot

Then learn one by one, with the accumulation of this knowledge, we can better read the official materials and develop probes suitable for our business scenarios.

Survival probe livenessProbe of kubernetes

The probe of kubernetes involves a lot of content, and only the parts related to SpringBoot are mentioned here.

Kubelet uses the survival probe livenessProbe to know when to restart the container

The following figure is an example of a survival probe on the official website of kubernetes. Several key parameters have been described in detail:

It can be seen that if our SpringBoot application is released to the kubernetes environment, as long as the application is still healthy, the address corresponding to the livenessProbe will be able to respond to the return code of 200400.

Ready probe readinessProbe for kubernetes

Sometimes, applications are temporarily unable to provide communication services. For example, an application may need to load large data or configuration files at startup, or rely on waiting for external services after startup. In this case, you neither want to kill the application nor send a request to it. Kubernetes provides ready probes to discover and mitigate these situations. The Pod where the container is located reports information that is not ready and does not accept traffic passing through the Kubernetes Service.

The configuration of the ready probe is similar to that of the survival probe, except that the readinessProbe field is used instead of the livenessProbe field.

To put it simply, if you have a normal container with a ready probe, K8s is considered to be able to provide services, and the corresponding request will be dispatched to the container.

Actuator of SpringBoot

To put it simply, actuator is used to help users monitor and operate SprinBoot applications. These monitoring and operations can be achieved through http requests. As shown in the figure below, the http://localhost:8080/actuator/health address returns the health status of the application:

The following are common actuator addresses. You can get different information by visiting different addresses:

In the SpringBoot-2.3 version, actuator adds two new addresses: / actuator/health/liveness and / actuator/health/readiness, the former as a survival probe for kubernetes and the latter as a ready probe for kubernetes

Voiceover: is that all the probe technology of SpringBoot?

When you see this article, you may feel boring: the so-called container probe feature is so simple that two new actuator addresses are left for kubernetes's survival and ready probes. As long as the two addresses respond properly, kubernetes determines that the container is normal.

Most of the time, there is nothing wrong with the above conclusion. The recommended configuration officially given by SpringBoot is shown in the following figure. We just need to copy it:

Calm down and think carefully, there are three problems that seem to remain unsolved:

First of all, SpringBoot provides two actuator items for kubernetes, but what about SringBoot applications that are not deployed in kubernetes? Do you have to disclose these two service addresses if you don't need these two items?

Second, when did the ready probe start returning a 200 return code? During the start-up phase of the application, it may take some time for the business service to work properly. If the ready probe returns 200 in advance, then K8s thinks that the container can work properly, and it is impossible to schedule external requests at this time. So it is important to figure out the state change logic of the ready probe.

Finally, and the most important point: in some scenarios, such as external dependent service exceptions or local global exceptions, the business does not want to provide services, and after the problem is solved, the business can provide services again. If we can write our own code to control the return code of the ready probe, then we can control whether kubernetes dispatches external requests to this container, which is a very practical feature.

After reading the above, do you have any further understanding of how to master the container probe of SpringBoot-2.3? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.