Master the container probes of SpringBoot-2.3: in-depth articles

About the "SpringBoot-2.3 Containerization Technology" series

The "SpringBoot-2.3 Containerization Technology" series aims to learn and practice the latest containerization technology brought by version 2.3 together with everyone, so that our Java applications can be more adapted to the containerized environment, keeping up with the mainstream in the cloud computing era, and maintaining competitiveness ；
The whole series of articles is divided into two parts, the topic and the auxiliary part, the topic part is as follows:

The auxiliary part is a summary of some reference materials and memos, as follows:

Previous review

This article is the second in the series of "Mastering the Container Probes for SpringBoot-2.3" . The previous article "Mastering the Container Probes for SpringBoot-2.3: Basics" knows the survival and ready probes of kubernetes and the addition of SpringBoot-2.3's actuator When we deploy the application to the kubernetes environment, this knowledge allows us to configure the officially recommended probe scheme, as shown below:
Although the above configuration can cover most scenarios, there are still three unresolved problems:

First of all, SpringBoot provides two actuator items for kubernetes, but what about SringBoot applications that are not deployed in kubernetes? Should I expose these two service addresses if I don’t need them?
Second, when did the ready probe start to return a 200 return code? During the application startup phase, the business service may take a while to work normally. If the ready probe returns 200 in advance, then k8s thinks that the container can work normally. At this time, dispatching external requests will not respond normally, so find out that it is ready The state change logic of the probe is very important;
Finally, and the most important point: In some scenarios, such as external dependency service exceptions, local global exceptions, etc., the business does not want to provide services to the outside world. After the problem is solved, the business can provide services to the outside world. If we can do it ourselves Write the return code of the code control ready probe to control whether kubernetes dispatches external requests to this container. This is a very practical function!

This article is written to solve the above problems. Only after these problems are solved can the probe technology be used well, so that it can bring greater value in the container environment;

Key knowledge points

The key to solving the above problems is focused on the following knowledge points:

SpringBoot's judgment on the container environment;
SpringBoot defines the state;
Get status
Monitoring status
Modify status;

Next, learn these knowledge points one by one;

SpringBoot's judgment on the container environment

The official document is shown in the following figure. The logic of SpringBoot to determine whether it is a kubernetes environment is very simple: whether there are two environment variables _SERVICE_HOST and _SERVICE_PORT :
Readers familiar with kubernetes see _SERVICE_HOST" and _SERVICE_PORT , they should think of KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT , which are environment variables configured in pod by k8s . It seems that SpringBoot is also based on this rule of k8s to determine whether it is a container environment (if k8s in the future A certain version does not set this environment variable for the pod. Isn't it dangerous for the pod that could run normally?);
Next, verify the effectiveness of the above rules through practice;
Create a SpringBoot-2.3.0.RELEASE application, the parent information in pom.xml is as follows:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.3.0.RELEASE</version>
  <relativePath/>
</parent>

Increase actuator dependency:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Start the application, visit the browser: http://localhost:8080/actuator/health/liveness , return a 404 error:
The above return is in line with expectations, because it is not in the kubernetes environment at this time. Next, add the two environment variables " _SERVICE_HOST and _SERVICE_PORT " to the application process to see if there are changes;
Edit the configuration information of the startup class as shown below:
Click the position of the red box in the figure below to enter the window for editing environment variables:
In the new window, the operation is shown in the red box in the figure below, and two new environment variables are added:
Run the program again, this time the status code returned is 200:
So far, we have figured out the logic of whether SpringBoot opens the probe, that is, whether the application is running in a container environment, and the judgment logic of whether it is a container environment is whether the two environment variables _SERVICE_HOST and _SERVICE_PORT exist;

Enable probes in non-kubernetes environment

/actuator/health/liveness and /actuator/health/readiness will be turned on in the kubernetes environment, but in general, the SpringBoot application may be running on your own computer during the development phase. At this time, if you want to view the return value of these two interfaces There are two ways:

The first is to add the two environment variables _SERVICE_HOST and _SERVICE_PORT mentioned earlier , so that SpringBoot thinks that the current environment is the kubernetes environment;

The second is to add attributes according to the official guidance, as shown in the red box in the following figure:
Insert picture description here

SpringBoot's definition of probe related state

First of all, we must figure out what status is there, the source code is the most accurate;
As shown in the figure below, the survival probe has two states: CORRECT indicates that the application is running and the internal state is normal, BROKEN indicates that the application is running and the internal state is BROKEN (please forgive my English level)
As shown in the figure below, the ready probe has two states: ACCEPTING_TRAFFIC indicates that the application can provide external services, and REFUSING_TRAFFIC indicates that the application cannot provide external services;
In addition, the since annotation in the above figure shows that these two enumerations are effective from version 2.3.0 ;
A little gossip, Brian Clozel , the author of the above two enumerations , is located in Lyon, France, and is currently ranked 8th in the number of sringboot submissions:
During the startup of SpringBoot, the corresponding relationship among the three states of application, survival probe, and ready probe is as follows:
In the process of stopping SpringBoot, the corresponding relationship between application, survival probe, and ready probe is as follows:

Get status

If the business application wants to obtain the current survival and ready status, just enter the ApplicationAvailability interface autowire. The next "Practice" will have a detailed usage method. Here is the key code:
Insert picture description here

Monitoring status

Thanks to Spring's complete event publishing and subscription mechanism, business applications can monitor the changes in survival and ready status through EventListener annotations, and write necessary business code in the EventListener annotation modification method to achieve status monitoring, next "Practice" will have detailed usage, here is the key code:
Insert picture description here

Modify status

Modify the state, especially the ready state. This should be our most concerned function. In some business scenarios, the application cannot provide external services. At this time, we hope that K8S will not dispatch external requests here. If K8S passes the ready probe When the return code is not 200, the request will not be dispatched to this pod;
The next article "Practice" will have a detailed code introduction, here is the key code as a reference:

caution

The important thing must be emphasized: Our ultimate goal of modifying the state is not to get applicationAvailability.getReadinessState() to return a new enumeration object, but to change the return code of the /actuator/health/readiness interface (ready is 200, not ready It is 503) , which is used by kubernetes probe rules;

Why put it in the next article

You may be in a rage after seeing this article: The key codes are posted, why not give the complete source code in this chapter? To cheat traffic? Make up the word count? Make up the number of articles?
Survival and readiness probes are tools in the kubernetes environment. In order to provide you with as accurate and complete reference as possible, all codes and operations must be debugged in the kubernetes environment before they can be released, and these operations should be treated as separate chapters with the current Separation of theoretical knowledge;
Welcome to the "Practical Combat" , with SpringBoot-2.3.0.RELEASE, enjoy the world of kubernetes;

Welcome to my GitHub

Address: https://github.com/zq2599/blog_demos
Content: Classification and summary of original articles, and supporting source code, involving Java, Docker, K8S, DevOPS, etc.

Welcome to follow my public account: programmer Xin Chen

Insert picture description here