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

What this article shares to you is about how to master the container probe of SpringBoot-2.3 in depth. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

When we deploy the application to the kubernetes environment, this knowledge enables us to configure the officially recommended probe scheme, as shown below:

Although the above configuration can cover most scenarios, there are still three issues that remain unresolved:

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.

In order to solve the above problems, only after these problems are solved can we make good use of the probe technology and make it bring more value in the container environment.

Key knowledge points

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

SpringBoot's judgment of Container Environment

SpringBoot defines the state

Get statu

Monitoring statu

Modify statu

Next, learn these knowledge points one by one.

SpringBoot's judgment of Container Environment

The official document is shown in the figure below. The logic for SpringBoot to determine whether it is a kubernetes environment is simple: whether there are two environment variables, _ SERVICE_HOST and _ SERVICE_PORT:

When readers familiar with kubernetes see _ SERVICE_HOST "and _ SERVICE_PORT, they should think of KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT, which are the environment variables configured by K8s to pod. It seems that SpringBoot is also based on the rule of K8s to determine whether it is a container environment (if a future version of K8s does not set this environment variable for pod, isn't it dangerous for pod that could have worked properly?)

Then verify the validity of the above rules through practice.

Create an SpringBoot-2.3.0.RELEASE application with the following parent information in its pom.xml:

Org.springframework.boot spring-boot-starter-parent 2.3.0.RELEASE

Increase actuator dependency:

Org.springframework.boot spring-boot-starter-actuator

Launch the application, visit the browser: http://localhost:8080/actuator/health/liveness, and return 404 error:

The above return is in line with expectations, because it is not in the kubernetes environment at this time, then add the two environment variables "_ SERVICE_HOST and _ SERVICE_PORT" to the application process to see if there are any changes

As shown in the following figure, edit the configuration information of the startup class:

Click the location of the red box in the following figure to enter the window for editing environment variables:

In the new window, two new environment variables have been added as shown in the red box in the following figure:

Run the program again, and this time the status code returned is 200:

So far, we have figured out whether SpringBoot turns on the probe logic, that is, whether the application runs in the container environment, and whether the container environment determines whether the two environment variables, _ SERVICE_HOST and _ SERVICE_PORT, exist.

Non-kubernetes environment turn on probe

/ actuator/health/liveness and / actuator/health/readiness will only be enabled in the kubernetes environment, but in general, SpringBoot applications may run on your own computers during the development phase. There are two ways to check the return values of these two APIs:

The first is to add two environment variables, _ SERVICE_HOST and _ SERVICE_PORT, to make SpringBoot think that the current environment is a kubernetes environment

The second is to add attributes according to official instructions, as shown in the red box below:

SpringBoot defines probe-related state

First of all, we need to find out what states there are, and 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, and BROKEN indicates that the application is running and the internal state is BROKEN (please forgive my English proficiency)

As shown in the figure below, the ready probe has two states: ACCEPTING_TRAFFIC indicates that the application can provide services, and REFUSING_TRAFFIC indicates that the application cannot provide services.

In addition, the since annotation in the figure above shows that these two enumerations have been in effect since version 2.3.0.

For a little gossip, the author of the above two enumerations, Brian Clozel, coordinates Lyon, France, currently ranks eighth in the number of sringboot submissions:

During the startup of SpringBoot, the corresponding relationship among application, survival probe and ready probe is shown below:

During the process of stopping SpringBoot, the corresponding relationship among application, survival probe and ready probe is shown below:

Get statu

If the business application wants to obtain the current survival and readiness status, you can enter the ApplicationAvailability interface autowire. The next "practical article" will have a detailed usage. Here is the key code:

Monitoring statu

Thanks to Spring's complete event publishing and subscription mechanism, business applications can listen for changes in survival and readiness through EventListener annotations, and state monitoring can be achieved by writing necessary business codes in the methods modified by EventListener annotations. The next "practical article" will have a detailed usage. Here are the key codes:

Modify statu

Modify the state, especially the ready state, which should be the function we are most concerned about. In some business scenarios, the application cannot provide services. At this time, we hope that K8S will not dispatch external requests here. If K8S receives a return code other than 200 through the ready probe, it will no longer schedule the request to this pod.

The next "practical article" will have a detailed introduction to the code, here is the key code as a reference:

Attention please

The important thing to emphasize is that our ultimate goal of changing the state is not to get applicationAvailability.getReadinessState () to return a new enumerated object, but to change the return code of the / actuator/health/readiness interface (ready is 200and not ready is 503), which is used by kubernetes's probe rules.

The above is how to deeply grasp the container probe of SpringBoot-2.3, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.