-
Notifications
You must be signed in to change notification settings - Fork 5
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
fix: [release/v0.14.x] Introduce startup probe to CAREN pod to reduce races #934
Conversation
I think this is the wrong timeout, and is being set for the helm registry? |
with this it will result in following with defaults
Once the container starts it will probe every 1 second with timeout of 1 seconds and upto 3 consecutive failures. so I guess CAREN should be up and ready in 3 seconds. CAREN starts within a second. |
While you're right, the failure of a readiness probe just removes it from the service endpoints so the pod keeps running (as opposed to liveness probe where the pod will be killed). The readiness probe will still run every second and after a single success will be marked as ready. So this isn't a problem even if it fails. |
4f89fe1
to
fa52c80
Compare
I've actually changed the implementation here to use startup probe to have the same effect (fast checking for readiness) but not have the overhead on the kubelet of probing every second once the pod is first set to ready (using default readiness probe period once startup probe has succeeded). |
Introduce a more frequent startup probe polling every second, which once it succeeds will trigger readiness and liveness probes to run at their default intervals. This reduces chances of races in clusterctl checking for readiness while keeping the overhead on the kubelet for checking readiness once the pod is up to a minimum (default probe period).
fa52c80
to
053c629
Compare
@dkoshkin If you could take a look and approve again if you're happy then we can merge. |
🤖 I have created a release *beep* *boop* --- ## 0.14.9 (2024-10-02) <!-- Release notes generated using configuration in .github/release.yaml at release/v0.14.x --> ## What's Changed ### Fixes 🔧 * fix: [release/v0.14.x] Rename webhook container to manager by @jimmidyson in #933 * fix: [release/v0.14.x] Introduce startup probe to CAREN pod to reduce races by @jimmidyson in #934 ### Other Changes * ci(release/v0.14.x): enable creating release-please PR from release branches by @supershal in #911 * test(e2e): [release/v0.14.x] Use released rocky image by @jimmidyson in #935 **Full Changelog**: v0.14.8...v0.14.9 --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Introduce a more frequent startup probe polling every second, which once
it succeeds will trigger readiness and liveness probes to run at their
default intervals. This reduces chances of races in clusterctl checking
for readiness while keeping the overhead on the kubelet for checking
readiness once the pod is up to a minimum (default probe period).