Unexpected startupProbe behavior.

[heckad]

If I have startupProbe probe and readinessProbe then all good. Previous version of the pod is terminated after startup probe success, but if readinessProbe wasn't specified the pod becomes ready immediately. It would be nice to add new state (for example starting) which would have pods until a startupProbe is successful. Also, it would mean that container not ready for connection.

Thank you for attention!

[heckad]

/sig cluster-lifecycle

[heckad]

@neolit123?

[neolit123]

/remove-sig cluster-lifecycle
/sig apps

try asking in #kubernetes-users on k8s slack.

[heckad]

@neolit123, they are silent in the chat. Who is involved in the development of startup probe?

[neolit123]

i think this topic better fits SIG Node.

try asking in their channel on slack #sig-node, but be patient ;)
/sig node
/remove-sig apps

[k8s-ci-robot]

@neolit123: Those labels are not set on the issue: sig/apps

In response to this:

i think this topic better fits SIG Node.

try asking in their channel on slack #sig-node, but be patient ;)
/sig node
/remove-sig apps

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[thockin]

I think this is a feature request, not support, so I changed labels. On its face it SEEMS reasonable, but I am not close enough to the details to say. This is definitely sig-node.

[riking]

Adding a new pod lifecycle state has been determined to be intractable in the past.

Is the proposed change keeping the pod in !Ready until the first success from startupProbe?

[heckad]

Adding a new pod lifecycle state has been determined to be intractable in the past.

Where do you usually discuss this? Just wondering.

Is the proposed change keeping the pod in !Ready until the first success from startupProbe?

Yes, I want that pod considered not ready until startupProbe will not be successful. If readiness probe doesn't present then a pod can become ready. How can a pod be ready if it is not running?

[heckad]

@riking?

[heckad]

@riking how long wait?

[thockin]

Looking at this issue, I can confirm it, at least superficially - a pod with a perma-failing startupProbe is "ready" if there is no readinessGate defined and "not ready" if it is defined.

The question I have is whether we think that is "correct" or not? Initially I thought it was correct, but the more I think about it the less convinced I am.

If I have defined a startupProbe and it is not passing, my app should not be ready.

Does anyone disagree?

[heckad]

Also, the app should not be ready in terminating status. It's funny, but without a readiness probe, pods in the final state have the status ready and accept requests. This is unexpected.

[thockin]

Whether a pod is ready while terminating is an entirely different question, IMO. Apps that server network traffic probably need to "drain" and to do that they need to stay "ready" for a while as upstream LBs de-program.

Let's not conflate issues, please.

[thockin]

#92196

The fix seems simple - lets see what CI says.

[matthyx]

@neolit123, they are silent in the chat. Who is involved in the development of startup probe?

Sorry, I don't spend much time on slack... you could have checked the release notes in 1.18 ;-)
Tim's fix seems good, thanks!

[matthyx]

/reopen
Until we merge all related PRs...

[k8s-ci-robot]

@matthyx: Reopened this issue.

In response to this:

/reopen
Until we merge all related PRs...

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[matthyx]

All merged.
/close

[k8s-ci-robot]

@matthyx: Closing this issue.

In response to this:

All merged.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.