See gh-19593
This commit is contained in:
Brian Clozel 2020-03-19 20:07:35 +01:00
parent b546415d32
commit b30e5a60c5
3 changed files with 5 additions and 8 deletions

View File

@ -893,6 +893,10 @@ In case your application needs to rely on a specific subset of health checks for
management.endpoint.health.group.readiness.include=readinessProbe,customCheck
----
WARNING: In general, "Liveness" and "Readiness" probes should avoid being based on external checks, such as <<production-ready-features.adoc#production-ready-health, external Health checks>>.
If an external system fails (e.g. a database, a Web API, an external cache), Kubernetes would react by restarting application instances or spinning up many new instances.
You should carefully consider external checks and how the platform should handle such failures.
WARNING: If your Actuator endpoints are deployed on a separate management context, be aware that endpoints are then not using the same web infrastructure (port, connection pools, framework components) as the main application.
In this case, a Probe check could be successful even if the main application does not work properly (for example, it cannot accept new connections).

View File

@ -6039,7 +6039,7 @@ The "Readiness" state of an application tells whether the application is ready t
A failing "Readiness" state tells Kubernetes that it should not route traffic to the application for now.
This typically happens during startup, while `CommandLineRunner` and `ApplicationRunner` components are being processed, or at any time if the application decides that it's too busy for additional traffic.
An application is considered live as soon as the `ApplicationReadyEvent` has been published, see <<boot-features-application-events-and-listeners, Spring Boot application lifecycle and related Application Events>>.
An application is considered ready as soon as the `ApplicationReadyEvent` has been published, see <<boot-features-application-events-and-listeners, Spring Boot application lifecycle and related Application Events>>.
TIP: Tasks expected to run during startup should be executed by `CommandLineRunner` and `ApplicationRunner` components instead of using Spring component lifecycle callbacks such as `@PostConstruct`.

View File

@ -16,9 +16,6 @@
package org.springframework.boot.kubernetes;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.ApplicationListener;
@ -35,8 +32,6 @@ import org.springframework.context.ApplicationListener;
*/
public class ApplicationStateProvider implements ApplicationListener<ApplicationEvent> {
private static final Log logger = LogFactory.getLog(ApplicationStateProvider.class);
private LivenessState livenessState;
private ReadinessState readinessState;
@ -63,12 +58,10 @@ public class ApplicationStateProvider implements ApplicationListener<Application
if (event instanceof LivenessStateChangedEvent) {
LivenessStateChangedEvent livenessEvent = (LivenessStateChangedEvent) event;
this.livenessState = livenessEvent.getLivenessState();
logger.info("Application State is now " + this.livenessState.toString());
}
else if (event instanceof ReadinessStateChangedEvent) {
ReadinessStateChangedEvent readinessEvent = (ReadinessStateChangedEvent) event;
this.readinessState = readinessEvent.getReadinessState();
logger.info("Application State is now " + this.readinessState.toString());
}
}