Health and Liveness Actuator Connections Refused/Fail Under Heavy Load
See original GitHub issueSpring Boot 2.4.1
I’ve set up new Readiness and Liveness probes, which work nicely under normal conditions.
However, under heavy load, they return Liveness probe failed: Get http://<ip>:<port>/health/liveness: dial tcp <ip>:<port>: connect: connection refused
to Kubernetes. Obviously, this is bad as it will then restart strained-but-generally-working containers.
Would really like a way to configure priority to management endpoints above normal traffic to make sure life/readiness checks don’t fail above all.
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (5 by maintainers)
Top Results From Across the Web
k8s spring boot pod failing readiness and liveness probe
If I disable the liveness and readiness probe in the replica-set manifest and I exec into the pod, I am getting a valid...
Read more >Liveness and Readiness Probes with Spring Boot
If Liveness is broken, this means that the application itself is in a failed state and cannot recover from it. In this case,...
Read more >Liveness and Readiness Probes in Spring Boot - Baeldung
When we deploy our application to Kubernetes, Spring Boot will automatically register these health indicators. As a result, we can use /actuator ......
Read more >How to enable Liveness and Readiness Probes in a Spring ...
We'll try to set up a simple Spring boot application, enable the actuators for liveness and readiness health checks and we are going...
Read more >RHSA-2022:5069 - Security Advisory - Red Hat Customer Portal
from the CVE link(s) in the References section. Description. Red Hat OpenShift Container Platform is Red Hat's cloud computing. Kubernetes ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks. From what you’ve described thus far, I am skeptical that this is a Spring Boot problem. With the management server running on a separate port, its ability to accept connections will be unaffected by the load on the application endpoints as it uses a separate embedded server with a separate thread pool, etc. It may be possible for it to become unresponsive if the CPU is saturated to the extent that a thread in the management server doesn’t get scheduled to accept the connection. However, in that case, I think the behaviour you’re seeing is desirable as it would be just as likely to happen with a request to an application endpoint so the instance really isn’t alive and ready to handle requests.
I’m not sure that it would be possible for us to implement this, but even if it were, I think it would be a mistake to do so. If traffic to the management endpoints was prioritised you may get into a situation where an instance reports that it is alive and ready when it is, in fact, unable to handle any application traffic. It’s for this reason that we caution against configuring a separate management port as doing so can cause the same problem.
Are you running Actuator on the same port as your application or have you configured
management.server.port
to make the Actuator available on a separate port?