New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Actuator document is misleading about k8s startup probe #28432
Comments
If I understand correctly, the startupProbe is a way to have a "special case livenessProbe only at startup". What we're trying to say here is that Spring Boot generally handles what's strictly necessary to get the application live and delays many initialization tasks (like In many cases, long running startup tasks are executed after the application is marked as live, so a startupProbe is not strictly necessary.
I think this bit means that if your application has a successful readinessProbe and a failed livenessProbe, your application is considered as broken and will be wiped. Spring Boot is perfectly in line with that and I don't think that this section of the documentation states otherwise. We don't completely rule out startupProbes, we're merely saying that you might not need it. Of course, some applications are handling heavy startup tasks as part of bean lifecycle (not a best practice from my point of view). Doing so ties those tasks to the context refresh phase and thus the time to get the livenessProbe UP. In this case, a startupProbe is probably required if you don't want to extend the period check too much. I'd be happy to improve the documentation - I'd rather not explain k8s internals in our reference documentation, but give general guidance to developers. |
Understand. What you're trying to say is that spring usually starts very quickly, those slow tasks will be delayed. But there's a use case: I have some micro services (maybe 5 or more), I deploy them at once, then the server may be temporarily overloaded. In this case, the start will be slower than expected. And then, k8s will kill them.
I think you got it wrong. Now, I have copied this warning entirly. He clarified one thing: Maybe many people have misunderstood So k8s wrote this warning. But Actuator's document deepened my misunderstanding. Now I understand what he really means, but we'd better improve the description. @bclozel |
Looking at this table describing the application startup sequence and the probe states during the different phases or the ApplicationAvailability section, I not sure how we could improve our documentation. Any idea? |
Personally, I think your explanation just now is very good. For example, we can write like this:
In this way, we express two views:
And prevented the possibility of the misunderstanding likes mine. |
I would like to mention that a common reason for slow startup (besides heavy load) might be database migration (like flyway), since it happens before the actuator endpoints are available at all. Please correct me if I am wrong. |
Actuator reference says:
But the fact is "Liveness probes do not wait for readiness probes to succeed". That means if your application take a long time to start, k8s may kill it before its readinessProbe success — It will never be able to start successfully.
So startupProbe is really necessary.
The text was updated successfully, but these errors were encountered: