Initial check for container being ready in a pod

[alitoufighi]

What would you like to be added:
I had the issue mentioned here: #37450

My applications take some time to be ready for serving traffic after creation, and I thought readinessProbe must be the solution to keep them NotReady until they're actually ready. But I only need this in the beginning of the lifecycle of my container. Using readinessProbe caused me experiencing a heavy CPU load which is not proper at all.

If there was something like initialReadinessDelay that I could say Wait for 2 minutes before bringing down old pods and replacing new ones, or using a initialReadinessProbe to check for availability of my containers, or adding some features to existing readinessProbe to set for this purpose, I would be happy experiencing a real zero downtime update.

Why is this needed:
Aside readinessProbe and livenessProbe that monitor healthiness of Pods, sometimes your containers are not such complicated. They only at their startup, need some time before they're really up and ready, and then they do their job. Then if something wrong happened, they simply crash and get restarted by their Deployment. Limiting running a readinessProbe only once prevents excess usage of resources.

Note: The readinessProbe I was using was this simple one:

readinessProbe:
  exec:
    command:
    - echo
    - '0'
  failureThreshold: 3
  initialDelaySeconds: 60
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 1

Because I only needed 60 seconds before Kubelet checks my container as Ready.

[alitoufighi]

Actually I don't know if it is really related to these SIGs but @kubernetes/sig-scheduling-feature-requests @kubernetes/sig-autoscaling-feature-requests

[k8s-ci-robot]

@alitoufighi: Reiterating the mentions to trigger a notification:
@kubernetes/sig-scheduling-feature-requests, @kubernetes/sig-autoscaling-feature-requests

In response to this:

Actually I don't know if it is really related to these SIGs but @kubernetes/sig-scheduling-feature-requests @kubernetes/sig-autoscaling-feature-requests

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.

[ahg-g]

This is not really related to sig scheduling.

/sig node

[k82cn]

/sig scheduling remove

[k8s-ci-robot]

@k82cn: The label(s) sig/remove cannot be appled. These labels are supported: api-review, community/discussion, community/maintenance, community/question, cuj/build-train-deploy, cuj/multi-user, platform/aws, platform/azure, platform/gcp, platform/minikube, platform/other

In response to this:

/sig scheduling remove

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.

[k82cn]

/remove-sig scheduling

[ashish-oyo]

I am also looking for something like this. Any solution yet?

[alitoufighi]

@ashish-oyo
Hi. I think this is the startupProbe that is implemented in 1.16.
Take a look at documentation.

As it seems to be implemented, I close this issue.

[alitoufighi]

I'm reopening again as it seems that startupProbe is an initial probe for liveness, but in this issue we're talking about readiness, as our containers take time to be ready and we don't want to kill our previous containers during a rolling update.

[matthyx]

@alinbalutoiu actually both ReadinessProbe and LivenessProbe are disabled until StartupProbe succeeds.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.