When running a native-built Spring Boot application on Kubernetes the liveness and readiness probes are not active (they both return a 404).

How to reproduce: 1. Go to start.spring.io and select Web, Actuator and GraalVM Native 2. Build a native image of your application (mvn spring-boot:build-image -Pnative) 3. Launch the application in Kubernetes (or set the appropriate environment when running locally docker run -it --rm -e KUBERNETES_SERVICE_HOST=localhost -e KUBERNETES_SERVICE_PORT=8080 -p 8080:8080 docker.io/library/demo:0.0.1-SNAPSHOT) 4. Open http://localhost:8080/actuator/health/liveness

Expected result - HTTP 200 with body {"status":"UP"}, actual result HTTP 404.

Comment From: snicoll

The auto-detection of Kubernetes happen via auto-configuration and this needs to be specified at build-time when AOT prepares your application. In a native image, auto-configurations are detected and considered at build time.

Adding management.endpoint.health.probes.enabled in your configuration should fix the above.

Comment From: wilkinsona

I think we could improve the docs a bit here. Perhaps in https://docs.spring.io/spring-boot/docs/3.0.x/reference/htmlsingle/#native-image.introducing-graalvm-native-images.key-differences-with-jvm-deployments or on the wiki. In the former we mention that the classpath is fixed, but we don't talk about (some) properties also being fixed and I think we should.

Comment From: derkoe

@snicoll adding management.endpoint.health.probes.enabled=true works.

Comment From: derkoe

I think we could improve the docs a bit here.

@wilkinsona I think it would be better for Spring users that these kind of features would work with native-image. Another option would to document list of things that do not work or a list of things that are tested to be working. Both is not easy to do.

Comment From: wilkinsona

I think it would be better for Spring users that these kind of features would work with native-image

Unfortunately, that's not easy due to Graal's closed-world assumptions. Furthermore, it would increase native image compile time and memory footprint. There's some more discussion related to this topic in https://github.com/spring-projects/spring-framework/issues/29844. It's talking about profiles but configuration properties are largely the same problem.

Another option would to document list of things that do not work or a list of things that are tested to be working. Both is not easy to do

This issue will take a step in this direction.

Comment From: mhalbritter

We have something in the documentation: https://docs.spring.io/spring-boot/docs/3.0.x/reference/htmlsingle/#native-image.introducing-graalvm-native-images.key-differences-with-jvm-deployments

The beans defined in your application cannot change at runtime, meaning:

  • The Spring @Profile annotation and profile-specific configuration have limitations.
  • Properties that change if a bean is created are not supported (for example, @ConditionalOnProperty and .enable properties).

Is that enough or should we add more?

Comment From: wilkinsona

I think it would be good to duplicate it or move it up into https://docs.spring.io/spring-boot/docs/3.0.x/reference/html/native-image.html#native-image.introducing-graalvm-native-images.key-differences-with-jvm-deployments from its current position in https://docs.spring.io/spring-boot/docs/3.0.x/reference/html/native-image.html#native-image.introducing-graalvm-native-images.understanding-aot-processing.

Comment From: mhalbritter

Ah yeah. I read the part under "Key Differences with JVM Deployments" as a general introduction to Native Image (not related to Spring Boot per se) and the "Understanding Spring Ahead-of-Time Processing" about more limitations when using Spring in a native image.

Comment From: wilkinsona

Yeah, there is that separation at the moment and my original suggestion would blur that. Perhaps the first list should just have a bullet that links or at least point people to the second. I think it's too easy at the moment to read the first list and think that's it in terms of limitations.