Suggestions: adding support for a startup probe

[tdeekens]

This is partially a suggestion and a question.

Kubernetes defines the ability next to liveness and readiness probes to define a startup probe.

startupProbe: Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success.

In examples the startup probe is often pointed to the /ready endpoint. I am wondering if it would make sense to add another endpoint to register a startup probe with. This probe would for instance be used to manage long taking processes when starting up or validating credentials before polling for ready. Lightship could maybe help here with providing an API for it.

Generally, I am also curious what thoughts are towards this.

[gajus]

Just use /live endpoint.

What would be a use case for a new endpoint that is not met by /live?

[tdeekens]

Thanks for responding. That's also the conconlusion I came to. To either use /live or /ready. The only difference would be that I might want those checks to only run on start up and not subsequently in the probe interval.

[gajus]

The only difference would be that I might want those checks to only run on start up and not subsequently in the probe interval.

I couldn't think of a scenario where this would be true. Though, if a use case appears, I will happily add an additional endpoint.

[gajus]

:tada: This issue has been resolved in version 6.0.2 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: